Notes on Scrum implementation - which will surely lead to failure of the iteration if nothing is done
Below are a few, in many ways obvious, points that may help newcomers to Scrum
The described project is the first one on which we decided to apply Scrum in full.
Prior to that, they worked on iterations, but without Stand-up rallies, Retrospectives and Demos.
Two teams are working on the project.
Team 1 creates a workflow system in which data will be prepared for a certain application that Team 2 is developing.
Because of this, in certain iterations we intersect and are very dependent on each other
. So.
From practice:
When planning the first iteration of the project, I did not invite two developers (Vasya and Petya), since they had previously agreed with Vasya on their amount of work orally.
As a result, in the middle of the first week of the iteration, it became obvious that part of the work was not taken into account and was not fixed on the board.
Result:
inaccurate assessment of work and delay in transmitting data to subcontractors Just at this iteration, an adjacent team depended heavily on us.
From practice:
Development is carried out at the junction of two technologies. At the beginning of the iteration, the developers agree that they will “converge” towards the end of the iteration, and when the time comes, one is not yet ready.
Result:
The planned story is not completed on time. The second developer is either idle or forced to do the task with lower priority.
What to do:
At each Stand-up meeting, developers within the team must “check the clock”. Everyone should voice the expected dates for the transfer of baton data.
If it turns out that someone does not have time, you need to take measures - either add another developer to help, or unload from other tasks, or ... there is always a solution for any team and any situation.
It is also necessary to place all identified dependencies on the board for visualization and control.
We have a separate area on the board with stickers like “Vasya must Pete”, “Petya must Masha”, etc.
The main dependencies should be identified and recorded during planning.
In addition, during the iteration, each of the team members should determine the dependencies for their tasks and fix them on the board if this was not taken into account during the planning.
And this happens often, because detailed sprint planning in our realities is a myth.
From practice:
Development is carried out at the junction of two technologies. One and the same requirement can be fulfilled using one technology as well as another. A small task (part large) is discussed - for example, field validation.
The team members verbally agree that the task will be done on technology N or actively argue that this task is easy to do on technology N on the one hand and also easy to do on technology J on the other hand, but eventually disagree without deciding who specifically does the task.
In general, we chatted and dispersed.
It may not look serious, but in our case it happened at one of the iterations.
Result:
The task was not completed. When the deadline for the completion of the big task came, the format of the field did not suit the adjacent team and had to be redone more than if it were done right away.
What to do:
All verbal agreements should be immediately transformed into tasks for specific performers.
This should be monitored by all team members.
From practice:
Team 1 implemented the return of data for Team 2 and set about its other tasks. After 3 days, Team 2 turned to Team 1 - data is not poured / data is not valid, etc.
Result:
Team 2 is idle waiting for data that, in the opinion of Team 1, has already been submitted.
This simple one still came back to everyone.
What to do:
1. In Team 2, the developer who “receives” the data is determined
2. After the work on the task is completed, the Team 1 developer notifies the Team 2 developer - “done, check”
3. After the Stand-up rally, at which the dependency task is gone in testing, the Scrum-master of Team 1 notifies the Scrum-master of Team 2
4. After Team 2 has confirmed that the data has been received, the task is transferred to Ready on the board.
From practice:
A task estimated at several hours hangs on the board “in the process” for several days.
The reason is that the developer came across some kind of bug and can’t quickly figure it out
Opinion: if such tasks often hang “in the process”, the board will lose the effect of the “flow”
What to do:
From practice:
During several Stand-up rallies, the Scrum-master was obliged to provide the necessary data to the subcontractors, but in the end, for various reasons, this did not happen.
Result:
adjacent teams form an opinion that one or another team cannot be relied on. This is bad, because the teams depend on each other.
As long as the team takes no responsibilities, it does not feel responsible for the work that has not been completed.
We failed that first iteration.
Then we examined the situation in retrospect - the main thing here is not to hand out responsibilities to developers, but to lead them to ensure that they themselves take over the responsibilities.
We completed the next iteration on time with a confident margin.
And what obvious and not so situations in your team led to the failure of the iteration?
A bit about the project and the teams.
The described project is the first one on which we decided to apply Scrum in full.
Prior to that, they worked on iterations, but without Stand-up rallies, Retrospectives and Demos.
Two teams are working on the project.
Team 1 creates a workflow system in which data will be prepared for a certain application that Team 2 is developing.
Because of this, in certain iterations we intersect and are very dependent on each other
. So.
1. The entire team must participate in the planning
From practice:
When planning the first iteration of the project, I did not invite two developers (Vasya and Petya), since they had previously agreed with Vasya on their amount of work orally.
As a result, in the middle of the first week of the iteration, it became obvious that part of the work was not taken into account and was not fixed on the board.
Result:
inaccurate assessment of work and delay in transmitting data to subcontractors Just at this iteration, an adjacent team depended heavily on us.
2. Control of dependencies between tasks within one team
From practice:
Development is carried out at the junction of two technologies. At the beginning of the iteration, the developers agree that they will “converge” towards the end of the iteration, and when the time comes, one is not yet ready.
Result:
The planned story is not completed on time. The second developer is either idle or forced to do the task with lower priority.
What to do:
At each Stand-up meeting, developers within the team must “check the clock”. Everyone should voice the expected dates for the transfer of baton data.
If it turns out that someone does not have time, you need to take measures - either add another developer to help, or unload from other tasks, or ... there is always a solution for any team and any situation.
It is also necessary to place all identified dependencies on the board for visualization and control.
We have a separate area on the board with stickers like “Vasya must Pete”, “Petya must Masha”, etc.
The main dependencies should be identified and recorded during planning.
In addition, during the iteration, each of the team members should determine the dependencies for their tasks and fix them on the board if this was not taken into account during the planning.
And this happens often, because detailed sprint planning in our realities is a myth.
3. Fixing arrangements within the team
From practice:
Development is carried out at the junction of two technologies. One and the same requirement can be fulfilled using one technology as well as another. A small task (part large) is discussed - for example, field validation.
The team members verbally agree that the task will be done on technology N or actively argue that this task is easy to do on technology N on the one hand and also easy to do on technology J on the other hand, but eventually disagree without deciding who specifically does the task.
In general, we chatted and dispersed.
It may not look serious, but in our case it happened at one of the iterations.
Result:
The task was not completed. When the deadline for the completion of the big task came, the format of the field did not suit the adjacent team and had to be redone more than if it were done right away.
What to do:
All verbal agreements should be immediately transformed into tasks for specific performers.
This should be monitored by all team members.
4. Interaction with related teams on tasks with dependencies
From practice:
Team 1 implemented the return of data for Team 2 and set about its other tasks. After 3 days, Team 2 turned to Team 1 - data is not poured / data is not valid, etc.
Result:
Team 2 is idle waiting for data that, in the opinion of Team 1, has already been submitted.
This simple one still came back to everyone.
What to do:
1. In Team 2, the developer who “receives” the data is determined
2. After the work on the task is completed, the Team 1 developer notifies the Team 2 developer - “done, check”
3. After the Stand-up rally, at which the dependency task is gone in testing, the Scrum-master of Team 1 notifies the Scrum-master of Team 2
4. After Team 2 has confirmed that the data has been received, the task is transferred to Ready on the board.
5. Correct assessment of the task or do not be afraid to overestimate them during the sprint.
From practice:
A task estimated at several hours hangs on the board “in the process” for several days.
The reason is that the developer came across some kind of bug and can’t quickly figure it out
Opinion: if such tasks often hang “in the process”, the board will lose the effect of the “flow”
What to do:
- you need to highlight such tasks
- cross out the old rating and put a new one.
- if the task is connected with others and pulls the tail, it is necessary to redistribute related tasks if possible (assign to another developer)
- re-evaluate the value of the task - perhaps it should be postponed at this stage
6. Responsibilities should be taken by the team, not just the Scrum master
From practice:
During several Stand-up rallies, the Scrum-master was obliged to provide the necessary data to the subcontractors, but in the end, for various reasons, this did not happen.
Result:
adjacent teams form an opinion that one or another team cannot be relied on. This is bad, because the teams depend on each other.
As long as the team takes no responsibilities, it does not feel responsible for the work that has not been completed.
Instead of output
We failed that first iteration.
Then we examined the situation in retrospect - the main thing here is not to hand out responsibilities to developers, but to lead them to ensure that they themselves take over the responsibilities.
We completed the next iteration on time with a confident margin.
And what obvious and not so situations in your team led to the failure of the iteration?