Scrum implementation notes - which will necessarily lead to iteration failure if nothing is done
Below are a few, in many ways obvious, theses that can help newcomers to Scrum
The described project is the first on which we decided to apply Scrum in full.
Before that, we worked on iterations, but without Stand-up meetings, Retrospective and Demo.
Work on the project are two teams.
')
Team 1 creates a workflow system in which data will be prepared for a certain application developed by Team 2.
Because of this, in certain iterations we intersect and are strongly dependent on each other.
So.
From practice:
When planning the first iteration of the project, I didn’t invite two developers (Vasya and Petya) because Vasya had previously agreed on their scope 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 job evaluation and delay in data transfer to subcontractors. Just at this iteration, the adjacent team depended on us greatly.
From practice:
Development is being done 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 ready for everything.
Result:
Scheduled history is not executed on time. The second developer either stands idle or is forced to do a task with a lower priority.
What to do:
At each Stand-up rally, developers within the team must “check the clock.” Everyone should voice the expected time for the transfer of data "baton."
If it turns out that someone does not have time, it is necessary to take measures - either to add another developer to help, or to unload from other tasks, or ... there is always a solution for any team and any situation.
It is also necessary to place all the identified dependencies on the board for visualization and control.
We have a separate area on the blackboard with stickers like “Vasya owes Pete”, “Peter must be Masha”, etc.
Key dependencies should be detected and fixed during planning.
In addition, during the iteration, each of the team members should determine their dependencies and fix them on the board, if this was not taken into account when planning.
And this happens often, because the detailed planning of the sprint in our realities is a myth.
From practice:
Development is being done at the junction of two technologies. The same requirement can be fulfilled with the help of one technology or another. A small problem (part large) is discussed - for example, field validation.
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 diverge without deciding who specifically does the task.
In general, chatted and dispersed.
It may not look serious, but it happened at one of our iterations.
Result:
The task was not completed. When the deadline for the delivery of a large task came up - the field format did not suit the adjacent team and had to be redone more than if they had done it right away.
What to do:
All verbal agreements should be immediately transformed into tasks for specific performers.
This should be followed by all team members.
From practice:
Team 1 implemented the data return for Team 2 and proceeded to its other tasks. After 3 days, Team 2 turned to Team 1 — the data is not filled / the data is not valid, etc.
Result:
Team 2 is idle waiting for data that Team 1 has already given.
This simple then still auknul all.
What to do:
1. In Team 2, a developer is defined who “accepts” the data
2. After completing the task, the developer of Team 1 notifies the developer of Team 2 - “ready, check”
3. After the Stand-up rally, at which the task with dependencies went into testing, the Scrum-master of Team 1 notifies the Scrum-master of Team 2 about this.
4. After Team 2 has confirmed that the data has been received, the task is transferred to Ready on the board.
From practice:
A few days on the "in progress" board hangs a task estimated at several hours.
The reason - the developer came across a bug and can not quickly figure it out.
Opinion: if such tasks often hang "in progress", the board will lose the effect of "flow"
What to do:
From practice:
For several Stand-up rallies, the Scrum-master pledged to provide the necessary data to 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 upon. This is bad, because the teams depend on each other.
While the team does not assume the responsibilities, it does not feel responsible for the work not done.
We failed the first iteration.
After dismantled the situation in retrospect - the main thing here is not to distribute responsibilities to the developers, but to bring them to the fact that they themselves take on the responsibilities.
We performed the next iteration on time with a confident margin.
And what are the obvious and not so situations in your team that led to the failure of the iteration?
A little about the project and the teams.
The described project is the first on which we decided to apply Scrum in full.
Before that, we worked on iterations, but without Stand-up meetings, Retrospective and Demo.
Work on the project are two teams.
')
Team 1 creates a workflow system in which data will be prepared for a certain application developed by Team 2.
Because of this, in certain iterations we intersect and are strongly dependent on each other.
So.
1. The entire team should be involved in planning.
From practice:
When planning the first iteration of the project, I didn’t invite two developers (Vasya and Petya) because Vasya had previously agreed on their scope 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 job evaluation and delay in data transfer to subcontractors. Just at this iteration, the adjacent team depended on us greatly.
2. Control dependencies between tasks within a single command.
From practice:
Development is being done 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 ready for everything.
Result:
Scheduled history is not executed on time. The second developer either stands idle or is forced to do a task with a lower priority.
What to do:
At each Stand-up rally, developers within the team must “check the clock.” Everyone should voice the expected time for the transfer of data "baton."
If it turns out that someone does not have time, it is necessary to take measures - either to add another developer to help, or to unload from other tasks, or ... there is always a solution for any team and any situation.
It is also necessary to place all the identified dependencies on the board for visualization and control.
We have a separate area on the blackboard with stickers like “Vasya owes Pete”, “Peter must be Masha”, etc.
Key dependencies should be detected and fixed during planning.
In addition, during the iteration, each of the team members should determine their dependencies and fix them on the board, if this was not taken into account when planning.
And this happens often, because the detailed planning of the sprint in our realities is a myth.
3. Fixing arrangements within the team
From practice:
Development is being done at the junction of two technologies. The same requirement can be fulfilled with the help of one technology or another. A small problem (part large) is discussed - for example, field validation.
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 diverge without deciding who specifically does the task.
In general, chatted and dispersed.
It may not look serious, but it happened at one of our iterations.
Result:
The task was not completed. When the deadline for the delivery of a large task came up - the field format did not suit the adjacent team and had to be redone more than if they had done it right away.
What to do:
All verbal agreements should be immediately transformed into tasks for specific performers.
This should be followed by all team members.
4. Interaction with related teams for tasks with dependencies
From practice:
Team 1 implemented the data return for Team 2 and proceeded to its other tasks. After 3 days, Team 2 turned to Team 1 — the data is not filled / the data is not valid, etc.
Result:
Team 2 is idle waiting for data that Team 1 has already given.
This simple then still auknul all.
What to do:
1. In Team 2, a developer is defined who “accepts” the data
2. After completing the task, the developer of Team 1 notifies the developer of Team 2 - “ready, check”
3. After the Stand-up rally, at which the task with dependencies went into testing, the Scrum-master of Team 1 notifies the Scrum-master of Team 2 about this.
4. After Team 2 has confirmed that the data has been received, the task is transferred to Ready on the board.
5. Proper assessment of the task or do not be afraid to overestimate them during the sprint.
From practice:
A few days on the "in progress" board hangs a task estimated at several hours.
The reason - the developer came across a bug and can not quickly figure it out.
Opinion: if such tasks often hang "in progress", the board will lose the effect of "flow"
What to do:
- need to highlight such tasks
- cross out the old assessment and set a new one.
- if the task is related to others and pulls tail, you need to redistribute the related tasks (assign to another developer)
- re-assess the value of the task - maybe it should be postponed at this stage
6. Responsibilities should be undertaken by the team, not just the Scrum Master.
From practice:
For several Stand-up rallies, the Scrum-master pledged to provide the necessary data to 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 upon. This is bad, because the teams depend on each other.
While the team does not assume the responsibilities, it does not feel responsible for the work not done.
Instead of output
We failed the first iteration.
After dismantled the situation in retrospect - the main thing here is not to distribute responsibilities to the developers, but to bring them to the fact that they themselves take on the responsibilities.
We performed the next iteration on time with a confident margin.
And what are the obvious and not so situations in your team that led to the failure of the iteration?
Source: https://habr.com/ru/post/178085/
All Articles