A central element of every Scrum team is the Daily Scrum, where the developers meet at the same time every day for 15 minutes to discuss progress in relation to the sprint goal. If necessary, especially if the achievement of the sprint goal appears to be at risk, they take measures such as adjusting the sprint backlog.
Although dailies were used long before Scrum, they only became truly widespread with the triumph of Scrum. Jeff Sutherland, one of the founders of Scrum, emphasizes the importance of the Daily MeetingIt promotes team spirit, supports the rapid removal of obstacles and increases both the productivity and commitment of the team.
I have also experienced this myself in Scrum projects in which I have been involved. However, there are also less inspiring examples: boring dailies in which the developers listlessly report their progress to the Product Owner and/or Scrum Master, while the other team members are bored and presumably often simply continue working on their user stories in the remote setup. It may seem easy to simply dispense with dailies in such projects.
I chose a different approach. First of all, together with colleagues at doubleSlash, I reflected on whether they have had similar experiences and what the underlying causes might be. We realized that the situation described merely reflects symptoms of a deeper problem that is largely based on two factors: Accountability and decision-making authority.
Different collaboration models
Some of us will still have (more or less fond) memories of them - waterfall projects. These projects were also characterized by a specific collaboration model. This model was characterized by the fact that each team member was only responsible for their own topics - today we would speak of user stories and tasks. A project manager, supported by sub-project managers, bore overall responsibility for the project. The team members reported to the project manager.
With the introduction of Scrum, the allocation of responsibilities and decision-making authority also changed. In Scrum, the achievement of the sprint goal is the responsibility of the development team - which also gives rise to the idea that a project manager is no longer necessary in agile projects. This means that everyone in the team must take an interest in the progress of the other team members, as everyone is jointly responsible for the overall result. If a team member encounters problems, the team can decide to work together on a solution until the problem has been solved. In such a constellation of responsibility and decision-making authority, a daily makes much more sense. It gives the entire team the opportunity to discuss the next steps together.
When theory meets practice
Unfortunately, I have only found this collaboration model implemented in very few Scrum teams. Often Scrum was only introduced as a process template, with adoption of the terminology, but those involved stuck to the old model of responsibilities and decision-making powers. In practice, this can be seen by the project manager being renamed the product owner and the sub-project managers being renamed sub-product owners. All team members report to the product owner (or sub-product owner), as they used to do to the project manager (or sub-project manager). And the dailies run as described above.
Why does the classic collaboration model persist so tenaciously? There are certainly many reasons. I would like to pick out a few here and then suggest possible solutions. Basically, the hierarchical model is deeply rooted in people - it has served mankind for thousands of years and should not be seen as negative across the board. What is the situation in many Scrum projects?
It is often not apparent to developers, product owners, Scrum Masters and management that the responsibility and decision-making model in Scrum differs from the classic model, despite the clear explanations in the Scrum Guide. Some developers prefer not to take on this kind of responsibility and prefer to focus on coding or designing, while leaving the responsibility for the scope and quality of their stories to others. In terms of time and budget, responsibility is often seen to lie with the product owner or occasionally the scrum master. One reason for this can also be the occasionally observed behavior of POs, Scrum Masters or management: the developers are supposed to bear responsibility if something goes wrong, but are only granted limited decision-making authority: Estimates of stories are pushed and stories are included in sprints under pressure.
Some Product Owners and Scrum Masters are not willing to give up power. They prefer to exercise control and receive direct reporting at a micromanagement level. This may be due to a desire for power, a lack of trust or simply a personal preference.
Solution approaches
In such situations, I proceeded as described below. As a first step, I talked to the team and, very importantly, much more explicitly about responsibilities and decision-making authority in agile projects and described what this means for each role. It also helped to explicitly explain the differences between the classic collaboration model and the model in agile projects. The second step was to address this topic again and again, particularly in the retrospectives, and to discuss with the team whether certain problems could have been avoided if responsibilities and decision-making powers had been distributed differently. These measures gradually took effect and resulted in more satisfied teams and customers.
As is so often the case, there is no generally applicable right or wrong approach. Once it is understood how the Scrum Guide envisages the procedure, the methodology can be adapted to the situation. However, this should be done deliberately and not by chance in order to avoid suboptimal results. It is crucial that responsibilities and decision-making authority always match; otherwise there is a risk of frustration. Not every developer can or wants to take on the same level of responsibility. The developers in the team can coordinate this among themselves. For example, team members with more experience could also take on more responsibility and gradually develop their less experienced colleagues so that they too can (and therefore often want to) take on more responsibility. It is also important to actively live, promote and, not least, demand this.
The role of the Scrum Master
Promoting all of this is a key responsibility of the Scrum Master, which goes beyond the role of a team secretary - a role that Scrum Masters are often pushed into. The success of a Scrum Master also depends on the willingness of other team members to change and the support of management. Change does not have to happen overnight; in the spirit of the Kaizen principle, the aim is to continuously improve. The retrospective offers the team the opportunity to reflect on the current status of responsibility and decision-making authority. If the team successfully follows this path, the dailies will once again become an exciting and productive exchange in a motivated team.
Our assessment
Dailies in Scrum practice often reveal a deeper problem: a lack of clarity regarding the distribution of responsibility and decision-making authority or a lack of assumption of responsibility or handover of decision-making authority. This manifests itself in listless participation in scrum dailies. The transformation to a truly agile way of working requires clear communication and adjustment of responsibilities and decision-making authority. Through targeted adjustments and the active role of the Scrum Master, the Daily Scrum can become a dynamic and effective element of teamwork that promotes genuine commitment and continuous improvement.
