Break me completely ... is it about Scrum?
In my opinion, the most insidious mistake was made by the creators when they said that scram is a framework that needs to be adapted for themselves. Many times I heard people referring to this statement, justifying the absence or modification of the fundamental elements of the scram, such as the role of the Product Owner, the burndown chart, the sprint goal, the demonstration, the finished product at the end of the sprint, etc. For such numerous "adaptations" even appeared the special term “ScrumBut”.
In this article I will share my vision of the meaning and benefits of some elements of scrum. I will do this in the format of the question "why is this element important?". These are the reasons why I was able to identify through trial and error, as well as careful observation of the scram processes in the companies where I worked.
For a long time I did not understand why the goal of the sprint is needed. And why in the book “Scrum and XP - notes from the front line” by Henrik Kniberg it is written that it is very important to choose it. Because of the emphasized importance of this element of the scram, we have always used it. But due to the fact that we did not understand the meaning, we came up with terrible goals. Usually, we simply simplified the process of choosing a goal, setting an unspoken rule to take the goal of releasing another release or implementing some kind of regular fat sprint feature. This intensified the sense of futility of the goal, and even its harm.
Understanding the goal came when I began to participate in the scrum team, whose members are doing technical tasks, not user stories. The tasks are cut in such a way that the result of the work of one team member is used by another team member in another sprint. My arrival added another link in this chain. Such a process is fundamentally a cascade-waterfall with all the ensuing consequences.
')
How can I correct the situation? After all, this is a difficult and painful change in the process at its root. A well-chosen sprint goal is the powerful tool that makes a team a team. If the team has a common goal. That goal to which each of its members aspires. Such a team will transform its processes in a natural way in order to achieve the goal set at the beginning of the sprint.
Thus, the goal of the sprint is the team building element of the scram and the well-chosen goal is what each member of the team seeks during the sprint and this is what is important for the team as a whole.
On planning, the team undertakes to perform sprint tasks by the end of the sprint. The sent letter is a documentary confirmation of these obligations, it is an unwritten contract between the performers and customers, this is an honest word given by the team, as well as a point of no return, after which all the sprint tasks are fixed and nothing else is left but to do them and thus fulfill their promise.
The letter has another, more famous purpose. All interested persons are introduced into the course of the tasks and deadlines of the team. This awareness of the PL is increasing loyalty to the team and reduces the flow of unplanned tasks.
Considering the performance of a command (velocity) and plotting historical performance values, one can understand how rhythmic and stable the work of a command is. A beginner team that is not yet in rhythm will have a broken schedule. If a broken schedule has a mature team, then this signals a problem that needs to be solved (with the exception of vacations and sick leave). For example, a constant change in the volume of unplanned tasks, from sprint to sprint, can affect the schedule. This problem in turn may be the reason for the failure of the sprint deadlines.
Also, the team performance schedule is useful in determining the amount of tasks per sprint based on yesterday’s weather method.
First, this rhythm gives a more stable value of velocity, and therefore more reliable planning. Secondly, the rhythm forms stable habits of the team members, the implementation of which requires less intellectual and psychological costs than the same actions, but without habits. Thirdly, interested people get used to the rhythm of the team and they always know what to expect from the team.
We tried to work without a constant rhythm, periodically changing the composition of the team and the length of the sprint, changing the days of planning and demonstrations. When we started to work in a constant rhythm, we noticed an increase in the speed of the team.
Everyone knows that the DSM (daily scrum meeting) is needed to synchronize the team. DSM also allows you to timely resolve design issues. If someone from the team has a problem that threatens to disrupt the timing of the sprint, then it is immediately opened and solved by joint efforts. Thus, the main value of DSM is to ensure that the plan is followed. This value can be enhanced by marking completed tasks in the burndown chart at the end of each DSM. If the burndown signals too slow completion of tasks, it is immediately opened and solved.
The main reason for this is the need for frequent releases from the business side. But this is not always the case. Sometimes businesses need quarterly or even semi-annual releases. Do we need ready-made products at the end of each sprint in these cases? Needed!
First, by making the finished product at the end of the sprint, the team disposes of the tails. A new sprint starts with a clean slate, with new user stories. This makes the work consistent. The new sprint does not have to remember the details of the implementation of the task, half of which the team did in the past / before last sprint.
Secondly, the finished product can be demonstrated to interested parties and receive useful feedback from them. Demonstration of the finished product better than any report shows the results of work and provokes new ideas. Also, the demonstration motivates the team during the sprint. Knowing that there will be a demonstration, the team is preparing for it.
Thirdly, it is not necessary to cut pieces of code for a user story, which was half realized one or several sprints back and fell heavily in priority or completely lost its relevance.
scrum_xp-from-the-trenches-eng-final.pdf
In this article I will share my vision of the meaning and benefits of some elements of scrum. I will do this in the format of the question "why is this element important?". These are the reasons why I was able to identify through trial and error, as well as careful observation of the scram processes in the companies where I worked.
1. WHY need a sprint goal?
For a long time I did not understand why the goal of the sprint is needed. And why in the book “Scrum and XP - notes from the front line” by Henrik Kniberg it is written that it is very important to choose it. Because of the emphasized importance of this element of the scram, we have always used it. But due to the fact that we did not understand the meaning, we came up with terrible goals. Usually, we simply simplified the process of choosing a goal, setting an unspoken rule to take the goal of releasing another release or implementing some kind of regular fat sprint feature. This intensified the sense of futility of the goal, and even its harm.
Understanding the goal came when I began to participate in the scrum team, whose members are doing technical tasks, not user stories. The tasks are cut in such a way that the result of the work of one team member is used by another team member in another sprint. My arrival added another link in this chain. Such a process is fundamentally a cascade-waterfall with all the ensuing consequences.
')
How can I correct the situation? After all, this is a difficult and painful change in the process at its root. A well-chosen sprint goal is the powerful tool that makes a team a team. If the team has a common goal. That goal to which each of its members aspires. Such a team will transform its processes in a natural way in order to achieve the goal set at the beginning of the sprint.
Thus, the goal of the sprint is the team building element of the scram and the well-chosen goal is what each member of the team seeks during the sprint and this is what is important for the team as a whole.
2. WHY need to send a letter announcing the start of the sprint to all interested parties and team members?
On planning, the team undertakes to perform sprint tasks by the end of the sprint. The sent letter is a documentary confirmation of these obligations, it is an unwritten contract between the performers and customers, this is an honest word given by the team, as well as a point of no return, after which all the sprint tasks are fixed and nothing else is left but to do them and thus fulfill their promise.
The letter has another, more famous purpose. All interested persons are introduced into the course of the tasks and deadlines of the team. This awareness of the PL is increasing loyalty to the team and reduces the flow of unplanned tasks.
3. WHY need to consider team performance and keep a schedule?
Considering the performance of a command (velocity) and plotting historical performance values, one can understand how rhythmic and stable the work of a command is. A beginner team that is not yet in rhythm will have a broken schedule. If a broken schedule has a mature team, then this signals a problem that needs to be solved (with the exception of vacations and sick leave). For example, a constant change in the volume of unplanned tasks, from sprint to sprint, can affect the schedule. This problem in turn may be the reason for the failure of the sprint deadlines.
Also, the team performance schedule is useful in determining the amount of tasks per sprint based on yesterday’s weather method.
4. WHY is a constant rhythm important?
First, this rhythm gives a more stable value of velocity, and therefore more reliable planning. Secondly, the rhythm forms stable habits of the team members, the implementation of which requires less intellectual and psychological costs than the same actions, but without habits. Thirdly, interested people get used to the rhythm of the team and they always know what to expect from the team.
We tried to work without a constant rhythm, periodically changing the composition of the team and the length of the sprint, changing the days of planning and demonstrations. When we started to work in a constant rhythm, we noticed an increase in the speed of the team.
5. WHY do DSM do and why draw a burndown?
Everyone knows that the DSM (daily scrum meeting) is needed to synchronize the team. DSM also allows you to timely resolve design issues. If someone from the team has a problem that threatens to disrupt the timing of the sprint, then it is immediately opened and solved by joint efforts. Thus, the main value of DSM is to ensure that the plan is followed. This value can be enhanced by marking completed tasks in the burndown chart at the end of each DSM. If the burndown signals too slow completion of tasks, it is immediately opened and solved.
6. WHY at the end of the sprint should there be a finished product?
The main reason for this is the need for frequent releases from the business side. But this is not always the case. Sometimes businesses need quarterly or even semi-annual releases. Do we need ready-made products at the end of each sprint in these cases? Needed!
First, by making the finished product at the end of the sprint, the team disposes of the tails. A new sprint starts with a clean slate, with new user stories. This makes the work consistent. The new sprint does not have to remember the details of the implementation of the task, half of which the team did in the past / before last sprint.
Secondly, the finished product can be demonstrated to interested parties and receive useful feedback from them. Demonstration of the finished product better than any report shows the results of work and provokes new ideas. Also, the demonstration motivates the team during the sprint. Knowing that there will be a demonstration, the team is preparing for it.
Thirdly, it is not necessary to cut pieces of code for a user story, which was half realized one or several sprints back and fell heavily in priority or completely lost its relevance.
Literature:
scrum_xp-from-the-trenches-eng-final.pdf
www.smartagilee.com/2012/06/v-behaviorurldefaultvmlo.html
www.scrum.org/ScrumBut
Source: https://habr.com/ru/post/281657/
All Articles