As a Scrum Master, I have noticed that Scrum is becoming more and more democratic, which, in my opinion, is a good thing. Companies are realizing that what worked 40 years ago is no longer applicable in today’s world and that a change is necessary.
These new implementations of Scrum are sometimes based on the experience of colleagues or on articles read on the Internet. I notice that few people take the time to go back to the source and read the Scrum Guide, a 13-page booklet that, as the name suggests, contains the rules of the Scrum framework. As a result, Scrum is applied without necessarily understanding the purpose behind certain events or certain accountabilities of the Scrum team (such as the Scrum Master’s accountability to ensure that Scrum is understood and respected).
In this context I wanted to write this series of articles on Scrum events. I would like to re-explain the fundamentals of events, to present the improvements linked to the new version of the Scrum Guide released in November 2020 and to debunk some myths about Scrum.
This is the second article of this series on the Daily Scrum.
To inspect progress toward the Sprint Goal and produce an actionable plan for the next day of work.
This meeting is for the Developers by the Developers.
If the Product Owner and/or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
Each day, 15 minutes maximum. To reduce complexity, it is held at the same time and place every working day of the Sprint.
– Implementing self-management
– Developers are responsible of producing a usable increment
– Inspect progress toward the Sprint Goal and adapt the Sprint Backlog
– Maximize transparency
– Improve collaboration and communication
– Remove impediments
– Developers own the Plan of the Sprint
The Scrum Guide 2020
In November 2020, a new Scrum Guide was released with several improvements.
In the case of the Daily Scrum, we can see that the description of this event has been reduced from about 30 lines to 15 lines, which is half as much text. How is this possible? Simply by being less prescriptive. Overall, the Scrum Guide 2020 is less prescriptive. It was found that when examples were given, these examples were taken as rules to be applied, so they were removed.
For the Daily Scrum, there is no longer any mention of the 3 questions to ask (what did you do yesterday, what are you going to do today, are there any impediments), which were present in the 2017 version as examples.
There are also two other more subtle changes.
Accountabilities vs Roles
The Scrum Guide 2020 now talks about three specific accountabilities within the Scrum Team, instead of three roles. The three accountabilities are the Developers, the Product Owner and the Scrum Master. We also notice the change in vocabulary between the Development Team and the Developers.
All these changes have been made to add more cohesion and mutual support within the Scrum Team. The Scrum team is a single entity, there is no longer the Development Team versus the Product Owner for example, as has been felt in some Scrum teams.
Moreover, speaking of accountabilities, this implies that the same person could have several accountabilities within the team if it is appropriate. Let’s be careful with this notion to avoid ending up with the all-rounder who may not have the time or the skills to do everything well.
In the context of the Daily Scrum, this implies that all the people in the Scrum Team who have a Developers accountability on the Sprint participate in this event. For example, Christine is a Product Owner in a Scrum Team, she has also agreed during the Sprint to write functional documentation needed for the Sprint Goal. She therefore participates in the Daily as a Developer (person who participates in the creation of the product) and not as a Product Owner.
In this example, this does not of course prevent exchanges with Christine that are related to her accountabilities as a Product Owner, and this can even be very useful.
This brings us to the term self-management. Previously, the term self-organisation was used, meaning that the development team could choose who did the work and how to do it. This is still the case with self-management, but in addition, the Scrum team (the whole team this time) must be able to choose who, how and what to work on.
Again, we increase collaboration within the team, the boundaries are less clear cut and the Scrum team as a whole should be self-managed, they can organize themselves as they wish, they are a cell that should be autonomous to manage themselves and their work.
Even if this was already the case previously, there is therefore an emphasis on this self-management. During the Daily Scrum, the Developers do not undergo what was planned during the Sprint Planning but continuously adapt their plan to reach the Sprint Goal by working closely with the Product Owner.
This is not a status meeting
This is not a product owner meeting.
It is not a standup meeting
It is not written in the Scrum Guide that it is mandatory to stand up during the meeting.
However, it is a good way to keep the meeting within the 15 minute timebox.
By the way, the 15 minute time limit is mandatory… it.
There is no predefined format
As mentioned above, the three questions format is no longer present in the Scrum Guide
Now it is written that you can use any format as long as it allows you to achieve the purpose of this meeting: to focus on progress toward the Sprint Goal and to produce an actionable plan for the next day of work.
For example, with a team, we go through all the items in the Sprint Backlog, column by column, starting with the column that is closest to Done. In this way, we focus our energy on what can be finished as quickly as possible and we are more likely to think as a team and help each other, rather than talking in turn without listening to each other.
I hope that this contextualization of Daily Scrum will help you to better understand what comes from Scrum and what is an adaptation related to your context or perhaps to a misunderstanding of the Scrum Guide.
However, I would like to stress here that adaptations are not necessarily bad. The important thing is to make these changes with full awareness and to understand what it would bring to do it “according to the theory”.
I’ll see you soon for the continuation of this series with an article on the Sprint Review. In the meantime, you can read the first article in the series on Sprint Planning.