Break me completely ... is it about Scrum?

    In my opinion, the creators made the most insidious mistake when they said that scrum is a framework that needs to be adapted for itself. Many times I heard people referring to this statement justifying the absence or modification of the fundamental elements of scrum, such as the role of Product Owner, burndown diagram, sprint goal, demonstration, finished product at the end of the sprint, etc. For such many “adaptations”, The special term is ScrumBut.

    In this article, I will share my vision of the meaning and benefits of some of the elements of scrum. I will do this in the format of the question “why is this element important?”. These are the reasons that I managed to identify, through trial and error, as well as careful monitoring of the scrum processes in the companies where I worked.

    1. WHY do I 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 with the best” by Henrik Kniberg it is written that it is very important to choose it. Due to the emphasized importance of this element of scrum, 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 by setting an unwritten rule, to take as a goal the release of the next release or the implementation of some regular bold sprint feature. From this intensified the sense of futility of the target, and even its harm.

    Understanding the goal came when I started participating in a scrum team whose members do technical tasks, not user stories. Tasks are cut so 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 fix this situation? After all, we are talking about 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. Then 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 a team-building element of scrum and a well-chosen goal is what each member of the team strives for during the sprint and this is what is important for the whole team.

    2. WHY do I need to send a sprint start announcement letter to all interested individuals and team members?


    On planning, the team is committed to completing sprint tasks by the end of the sprint. The sent letter is a documentary confirmation of these obligations, it is an unspoken contract between contractors and customers, it is an honest word given by the team, and also a point of no return, after which all sprint tasks are fixed rigidly and there is nothing left to do but to fulfill their promise.

    The letter has another, more well-known purpose. All interested parties are introduced into the course of tasks and team timelines. Such an awareness of ZL increases team loyalty and reduces the flow of unplanned tasks.

    3. WHY do you need to consider team performance and keep a schedule?


    Considering the team’s productivity (velocity) and keeping a graph of historical performance values, you can understand how rhythmic and stable the team’s work is. A novice team that has not yet entered the rhythm will have a broken schedule. If the 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 schedule may be affected by a constant change in the volume of unplanned tasks, from sprint to sprint. This problem, in turn, can cause a sprint deadline.

    The team’s performance graph is also useful in determining the amount of sprint tasks based on yesterday’s weather method.

    4. WHY is constant rhythm important?


    Firstly, such a rhythm gives a more stable value of velocity, and therefore more reliable planning. Secondly, the rhythm forms stable habits of team members, the implementation of which requires less intellectual and psychological costs than performing the same actions, but without habits. Thirdly, the interested parties get used to the rhythm of the team and they always know what to expect from the team.

    We tried to work without observing a constant rhythm, periodically changed the composition of the team and the length of the sprint, changed the days of planning and demonstrations. When we began to work in a constant rhythm, we noticed an increase in team speed.

    5. WHY do DSM need to be done and why draw burndown?


    Everyone knows that DSM (daily scrum meeting) is needed to synchronize the team. DSM also helps you troubleshoot development issues in a timely manner. If any of the team has a problem that threatens to disrupt the sprint deadline, then it is immediately opened and solved by joint efforts. Thus, the core value of DSM is to ensure that you follow the plan. This value can be enhanced by marking completed tasks on the burndown chart at the end of each DSM. If burndown signals the completion of tasks too slow, this is immediately opened and solved.

    6. WHY should the finished product be at the end of the sprint?


    The main reason for this is the need for frequent releases from the business. But this does not always happen. Sometimes a business needs quarterly or even semi-annual releases. Do we need finished products at the end of each sprint in these cases? Are needed!

    First, by making the finished product at the end of the sprint, the team gets rid of the tails. A new sprint begins with a clean slate, with new user stories. This makes the work consistent. In the new sprint, you don’t have to remember the details of the task, half of which the team did in the past / the year before the sprint.

    Secondly, the finished product can be demonstrated to interested parties and get useful feedback from them. The demonstration of the finished product is 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, you don’t have to cut out pieces of code for a user story that was half implemented one or several sprints back and fell heavily in priority or completely lost relevance.

    Literature:

    scrum_xp-from-the-trenches-rus-final.pdf
    www.smartagilee.com/2012/06/v-behaviorurldefaultvmlo.html
    www.scrum.org/ScrumBut


    Also popular now: