Have you ever seen heated blogs, posts and forum discussions around how evil/great Scrum daily stand-ups are?
Under the skin of these discussions I’ve witnessed some recurring viewpoints. Some angles demonstrate a god-complex or a big-brother conspiracy fear, more sane angles appear to lose the fundamental purpose with comments like “It’s a waste of time, the team can check the source control check-ins to see what I’ve been up to”. These angles miss the point – It’s all about the team. Not everyone is as amazing as the Most Valuable Player, not everyone is a great communicator, not everyone chats over a coffee in the kitchen to make sure everything is ok, not everyone checks with the testers before they check in risky code. The team is unlikely to reach it’s full potential if they don’t grasp what the daily stand up achieves.
Now, just saying “It’s all about the team” doesn’t provide enough of an answer for me, so I want to get to the bottom of the purpose of the stand-up and a good place to start is our Holy Bible, the Scrum Guide (2011). Praise the scrum god.
…[The Daily Stand-up is] for the Development Team to synchronize activities and create a plan for the next 24 hours.
This to me, is the most important point. Obviously we don’t create a formal plan, but through a quick discussion with the group we can identify quickly:
- Impediments/Risks to completion.
- What meetings are needed.
- Who needs to be left alone, as they’ll be ‘in the zone’ today.
- Who needs some pairing-up with complex code.
- What needs testing today, or even tomorrow, so preparations can be made
Now, some may argue that these things can all be achieved without a Daily Stand-up. That assumes that everyone is capable or feels they have the authority to make those decisions, and that they’ve talked to the right person. Recently, some of the most crucial observations made in our Stand-ups have been made by the non-domain experts.
Daily Scrums improve communications, eliminate other meetings, identify and remove
impediments to development, highlight and promote quick decision-making, and improve the
Development Team’s level of project knowledge. This is a key inspect and adapt meeting.
Other than the elimination of other meetings statement – Bravo scrum gods! I strongly believe that the continual communication allows early detection of failure, and quick peer review of decisions. We possibly have more meetings than before, but they are of a higher quality, plus everyone is on the same page every day.
The Development Team uses the Daily Scrum to assess progress toward the Sprint Goal …
The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.
I’m less enthusiastic about this one, merely because a clear goal that aids focus has always eluded me. If the goal is “implementing the highest priority stories” (which are usually unrelated), rather than “improving aspect X”, then it introduces inefficiency in development and testing. If the goal is narrower and the team resists work that doesn’t aid the sprint goal, the focus and determination this affords could result in the high quality iteration Scrum promises. So, in summary, checking the progress towards the Sprint Goal is only as good as the goal itself.
… and to assess how progress is trending toward completing the work in the Sprint Backlog.
Monitoring the burn-down can be done at any time, so the assessment doesn’t have to happen in the meeting. The more important purpose is to raise the issue, and have the team come up with actions to get it back on track.
Development Team often meets immediately after the Daily Scrum to re-plan the rest of the
Sprint’s work. Every day, the Development Team should be able to explain to the Product Owner
and Scrum Master how it intends to work together as a self-organizing team to accomplish the
goal and create the anticipated Increment in the remainder of the Sprint.
Toward the end of the sprint, the testing effort might need re-planning, but on a day to day basis we rarely re-plan the remainder of the sprint. Most of the time the Daily Stand-up is over, and everyone dashes back to their seats like drivers at Le Mans. Also, we don’t tend to pre-allocate the work. However, the Daily Stand-ups do allow the product owner to ask any team member how the goal will be progressed in the next 24 hours. Then, collaborative working tools will complete the picture, warts and all.
The Daily Scrum is not a status meeting, and is for the people transforming the
Product Backlog items into an Increment.
To me, this was the most contradictory statement when taken in isolation. In context it actually means that it’s not a status meeting for the Product Owner/Stakeholders. Obviously telling the team what you accomplished yesterday, discussing the burn down and what can be tested – is status. The main thing to note that this meeting is for the team, and no one else. Hence the pigs and chickens analogy comes into play.
So, in summary, the purpose is:
- Quick synchronization of activities for the next 24hrs
- Quick decision making,
- Identifying impediments
- keeping ‘on goal’
Please share your thoughts if you agree/disagree, as long as you leave the nerd-rage at the door!