How did we fix our process and become less distracted
Last year, our team went through a hard scrapping of the development process, but was able to restore it and make it even better: clearer, more pleasant and more productive.
I'll tell you about some of the practices and approaches that we have implemented and use to ensure a stable process. The key idea around which all this is built is that the developer should have a focus on development, from which he should be distracted as little as possible.
Each developer of the team is personally responsible for the quality of the product, so we interact with the support service directly - this is how acute the pain of users is.
')
Every day, one of us comes on duty. The priority and exclusive task of the developer on duty is to work with customer support requests. Normally, if due to the influx of applications, the duty officer did not write a single line of code, but not comme il faut, if he left new applications the next day (they will go to his colleague).
For simplicity, the attributes of the authority on duty (see picture) are transmitted every day in a clockwise direction to the next developer (no duty rotations).
The duty gives the support service the fastest possible response from the team, and the team allows less distraction.
The team is open from the outside only for product-owner and customer support. The product-owner proxy all requests for the feasibility of features and the like, the support service solves complex questions from users through the team.
This simple, even the captain's rule protects the team from hyperactive client managers, who want to cut corners and solve their problem “quickly,” and at the same time pumps over the product and support service.
Any discussions in which the team participates are held strictly on the allotted days of the week (Tuesday and Thursday in our case). Regular discussions / evaluation (grooming) of new features with a product-owner, as well as planning for the next sprint are scheduled for the same days.
With this approach, the selected days in the limit can be fully occupied with discussions and switching between them (and again not a single line of code), but in return we get a guarantee that we can focus on the development at other times.
Some people from the side of the development seem to distract the team for an hour-long meeting - this is just an hour of team work. Several of these meetings in the sprint and it is not clear where the two weeks have gone.
To emphasize the cost of meetings and conduct them more efficiently, we plan and evaluate each discussion like any other task. By the beginning of the iteration, it is precisely known for which meetings the team will spend time and what result is expected from them.
We use Scrum with two weekly iterations. This means that from the beginning of the sprint, the task list in it is fixed and should not change in the normal case.
But in two weeks the world can change, and for a new small task to wait another two weeks is sometimes not an option. In order to be able to respond to the changes, during the planning of the next sprint we include a reserve in it.
The reserve looks like a task without a description, but with a rating in story points. The amount of reserve is determined by the product-ouner taking into account potential needs. It may not exist at all if there is no space left in the sprint. The maximum amount of reserve is limited, in our case these are three tasks with different estimates:
The unused product of the reserve is a day before the demonstrationturns into a pumpkin burned. This ensures that the demanded reserve can be managed to be realized and included in the release. The team uses the burnt reserve for a technical task at its own discretion, or removes it from the sprint (in the latter case, no story points are awarded).
Previously, we had difficulties with determining the completeness of a task (Definition of Done), especially with the item “The whole team agrees that the task is completed”.
Now, when the author-developer considers the task ready, he gathers other team members at the Done-Consilium and holds a mini-demonstration. The team collectively assesses whether the original problem has been solved, whether something else has been forgotten, which has not been thought of before, and may suggest improvements.
Done-consultation guarantees that the whole team is satisfied with the final solution of the problem.
Since the event requires the distraction of the whole team, a special time is allotted for him between the tasks: immediately after the daily stand-up and immediately after lunch.
When the Done-consultation is over, and the author has made the necessary edits, the task is transferred to another developer. It conducts code review and self- corrects found comments or refactor.
This practice achieves overall code ownership and immersion in the tasks of colleagues, reduces the time to correct comments on code review. In addition, the effect of a fresh look and a second head works here, which often helps to identify non-obvious problems.
I'll tell you about some of the practices and approaches that we have implemented and use to ensure a stable process. The key idea around which all this is built is that the developer should have a focus on development, from which he should be distracted as little as possible.
1. Duty Developer
Each developer of the team is personally responsible for the quality of the product, so we interact with the support service directly - this is how acute the pain of users is.
')
Every day, one of us comes on duty. The priority and exclusive task of the developer on duty is to work with customer support requests. Normally, if due to the influx of applications, the duty officer did not write a single line of code, but not comme il faut, if he left new applications the next day (they will go to his colleague).
For simplicity, the attributes of the authority on duty (see picture) are transmitted every day in a clockwise direction to the next developer (no duty rotations).
The duty gives the support service the fastest possible response from the team, and the team allows less distraction.
2. Single Entry Point
The team is open from the outside only for product-owner and customer support. The product-owner proxy all requests for the feasibility of features and the like, the support service solves complex questions from users through the team.
This simple, even the captain's rule protects the team from hyperactive client managers, who want to cut corners and solve their problem “quickly,” and at the same time pumps over the product and support service.
3. Fixed days for discussions
Any discussions in which the team participates are held strictly on the allotted days of the week (Tuesday and Thursday in our case). Regular discussions / evaluation (grooming) of new features with a product-owner, as well as planning for the next sprint are scheduled for the same days.
With this approach, the selected days in the limit can be fully occupied with discussions and switching between them (and again not a single line of code), but in return we get a guarantee that we can focus on the development at other times.
4. Discussion - a task with an assessment
Some people from the side of the development seem to distract the team for an hour-long meeting - this is just an hour of team work. Several of these meetings in the sprint and it is not clear where the two weeks have gone.
To emphasize the cost of meetings and conduct them more efficiently, we plan and evaluate each discussion like any other task. By the beginning of the iteration, it is precisely known for which meetings the team will spend time and what result is expected from them.
5. Provisions for product
We use Scrum with two weekly iterations. This means that from the beginning of the sprint, the task list in it is fixed and should not change in the normal case.
But in two weeks the world can change, and for a new small task to wait another two weeks is sometimes not an option. In order to be able to respond to the changes, during the planning of the next sprint we include a reserve in it.
The reserve looks like a task without a description, but with a rating in story points. The amount of reserve is determined by the product-ouner taking into account potential needs. It may not exist at all if there is no space left in the sprint. The maximum amount of reserve is limited, in our case these are three tasks with different estimates:
- XS (~ 3 perfect man-hours) - 2 tasks
- S (~ 6 perfect man hours) - 1 challenge
The unused product of the reserve is a day before the demonstration
6. Done-consultation
Previously, we had difficulties with determining the completeness of a task (Definition of Done), especially with the item “The whole team agrees that the task is completed”.
Now, when the author-developer considers the task ready, he gathers other team members at the Done-Consilium and holds a mini-demonstration. The team collectively assesses whether the original problem has been solved, whether something else has been forgotten, which has not been thought of before, and may suggest improvements.
Done-consultation guarantees that the whole team is satisfied with the final solution of the problem.
Since the event requires the distraction of the whole team, a special time is allotted for him between the tasks: immediately after the daily stand-up and immediately after lunch.
7. Transfer code
When the Done-consultation is over, and the author has made the necessary edits, the task is transferred to another developer. It conducts code review and self- corrects found comments or refactor.
This practice achieves overall code ownership and immersion in the tasks of colleagues, reduces the time to correct comments on code review. In addition, the effect of a fresh look and a second head works here, which often helps to identify non-obvious problems.
Source: https://habr.com/ru/post/334936/
All Articles