Daily Standups go a great length in synchronizing and building teams on a day-to-day basis. Often, they make the difference between a loosely coupled group of developers working on related topics and actually working towards common goals.
Yet, there are numerous problems habitually associated with them.
The nature of the Daily Standup
Following textbook definition, we would have all team members huddle in front of the Scrum Board, then each team member shares "What have I done yesterday, what will I do today, what impedits me?". The main purpose is to synchronize one another, but also to build mutual accountability.
Any stakeholder who is interested may participate in Daily Standups as a silent bystander to get a feeling of what is going on: "Status Meetings" and "Status Reports" are a thing of the past.
Of course, this is also part of their value. However, their biggest value is barely hinted: Finding opportunities for improving the collaboration.
What happens when you don't have Daily Standups
Without daily standups, there is a huge risk that team members run into different directions, providing code that does not turn into a maximum value solution at the end of the sprint. One worst-case scenario: people work in parallel on incompatible solutions to the same problem - and find out when the customer complains.
You can't be a team unless you share troubles, solutions, failures and success.
You can't be a team unless you share troubles, solutions, failures and success.
Dealing with Problems
It's natural to face challenges in the implementation of software. This-or-that framework doesn't behave as expected, here or there a configuration item is causing trouble, an infrastructure component is required - and whatever. Technical experts are keen on solving their own problems, because after all, that's what makes them experts.
Oftentimes, there is someone else on the team who has experienced the same type of problem before. Becoming aware of someone else's problem, they would gladly extend a helping hand. But how do they become aware unless someone is sharing their troubles?
Tangents
The Sprint defines a clear scope and time box. Sometimes, it is very interesting - or academically challenging - to not only work on the task at hand, but to derive a related task. For example - we need to do a site index. Because it's both related and my personal favourite, I also implement a fuzzy search. Cool, but it will cost me 5 days of the Sprint - and nobody asked for that.
The shared accountability in the Daily Standup encourages the team to focus on the common objectives and provides an opportunity for team members to say "That's good, but we need you to do something else."
Status Reports
Transparency makes agile implementations strong. Lack of transparency causes problems. Managament's first reaction when they don't know what is going on: Forced status reporting. The first stage is boring, hour-long status meetings that become a mixture of sleeping pill and justification rally. In the second stage, they become written, formal and tracked - merely to satisfy the internal need of being informed. Usually, both methods are implemented simultaneously, in cumulation burning a good 20 hours of productivity per week.
Not many developers like writing formal status reports, so daily standups actually increase morale.
Why having Daily Standups is bad
After the previously mentioned topics, who could argue that Daily standups are actually bad?
Let's look in detail what Daily Standups actually are. They are a predefined standard process executed in a rhythm. As such, they induce waste.
No meaningful update
"Yesterday, I was working on the search engine. Today, I will continue working on the search engine. Nothing impedits me." - great. Now, how much did that help my team? The good news: Like this, the standup only takes 5 minutes. The bad news: We're actually wasting 5 minutes of each team member each day.
Numerous approaches, such as "Improving the 3 questions", have been implemented in different organizations. None of these solve the fundamental problem, they merely try to expose the symptom.
If it's something that takes more than 1 day, why has it not been sliced further - why is nobody else involved, what has actually changed since yesterday - and is there a way for other team members to join me so that we can deliver faster, a better solution etc.?
I might bring up even more questions: If I've been working on it for a full day already and plan to work more - who has done the testing? Is anyone doing code reviews? I should be rallying support for my topic rather than just informing what I do. Or is my task not important enough for the team to contribute?
Hiding the Elephant in the Room
Have you ever seen how everyone focuses on their stories, their responsibilities in a Daily? Yes, everyone can align that on the Sprint Goal. But is that sufficient? There is probably a prioritization issue when 3 or more stories are Work in Progress, because nobody seems to ask the intrinsic question "Which one is really the most important of these?" - probably the team is more focused on delivering quantity than getting the top priority done!
Many teams justify this behaviour by stating: "But Tim is the only Database expert, so he's the only one who can do that story!". A measly excuse, really - because they have a bottleneck and aren't even working to resolve that. In fact, the team subconsciously knows they have a sustainability and quality issue: If Tim gets sick or goes on vacation, the team may be completely blocked. All the stress is on one shoulder!
So, the real question we should be asking is not: "Which is the next story for Tim?", but "How can we collaborate on this one, so that the next Database story doesn't rely solely on Tim?"Value Delay
Why should I wait for the Daily Standup to rally collaborators? I should do it immediately. If I need to get some exploratory testing done - why should I wait until the next stand-up to find a team member who has some time?
Again, this may come down to priorities. If I am doing is the most valuable thing the team can do at this time - why am I the only one? If I am not doing that - why am I not working on the most valuable thing? Why should I wait until the next Daily to deliver most value?
Restating the obvious
The worst stand-up I have ever participated in was actually in the most efficient team. We did something called "Mob Programming". The team was great, we were flying through the backlog at a rapid pace. Everyone was constantly and intensely involved. But our daily standups were terrible: "Yesterday, we completed the stories A,B,C. Today, we will work on the top priorities in the following order..." Only one person spoke, because - everyone already knew what we were doing, why we were doing it and how they would contribute! Everyone was highly focused. Nobody was doing anything outside the agenda.
The stand-up wasn't adding any value because everyone knew everything before we huddled!
The stand-up wasn't adding any value because everyone knew everything before we huddled!
Is this inherent to the Stand-Up?
All of the above can be solved by actually improving the nature of the stand-up. But many times, standups are not like that. Why? Because people are not looking for collaboration, they are merely fulfilling their responsibility. Let's be frank: If you aren't looking to collaborate, your Daily Standup is a farce!
Summary
Daily Standups are great. If people are working on different tasks, the Standup provides an opportunity to resynchronize, harness synergy and refocus.
You should improve your Daily Standup to the point where they become a magnet for collaboration and a catalyst for value creation. Once they fit that purpose, you should look for different places to improve.
Daily Standups are an artifact in themselves and provide no bottom line value. They assist in obtaining value - no more, no less. As the level of collaboration among teams improves, the amount of actually new and relevant information would decrease. In an ideal team, collaboration would be an ongoing, permanent condition and the Daily Standup would only interrupt the ongoing collaboration to fulfil a non-value adding ceremony.
At that time, Daily Standups turn into waste. Few teams ever reach this state.
Improve your standup to be valuable, but remember that the vision is great collaboration, not great Standups!
You should improve your Daily Standup to the point where they become a magnet for collaboration and a catalyst for value creation. Once they fit that purpose, you should look for different places to improve.
Daily Standups are an artifact in themselves and provide no bottom line value. They assist in obtaining value - no more, no less. As the level of collaboration among teams improves, the amount of actually new and relevant information would decrease. In an ideal team, collaboration would be an ongoing, permanent condition and the Daily Standup would only interrupt the ongoing collaboration to fulfil a non-value adding ceremony.
At that time, Daily Standups turn into waste. Few teams ever reach this state.
Improve your standup to be valuable, but remember that the vision is great collaboration, not great Standups!
As with many practices of the agile routine, the daily stand-up helps surfacing problems that exist within the team. If, as a Scrum Master, you use this information to help the team improve you're doing a great job.
ReplyDeleteIn order to skip the daily stand-up altogether you would need to reach the Ri level of agile mastership first: http://alistair.cockburn.us/Shu+Ha+Ri It is desirable, it is achievable, it will take you years.
I fully agree with you Rainer. Exactly like the Agile Manifesto, this is a value pair with the limitation that unless you have the item on the left, you should be using the item on the right. Hence, this is a part of the "Post-Scrum Manifesto".
DeleteThis is just one of many topics in the question "What happens after Scrum, or is Scrum the end of the road?" - few teams and/or organizations get to this level. And I would never advise beginners to take this line.
Rainer, I also need to add in that you are touching 2 additional values of the Postscrum Manifesto:
Deletea) Continuous Improvement over Retrospectives
http://failfastmoveon.blogspot.de/2015/03/continuous-improvement-over.html
b) Taking Initiative over Dedicated Scrum Masters
http://failfastmoveon.blogspot.de/2015/03/taking-initiative-over-dedicated-scrum.html
If the team is just staring at the elephant in the room, then there is a big issue which may require the Scrum Master to act. Once the team understands that problems (impediments) are there for being resolved and that it's their job, not someone else's job, that's also a big step.
Again, I agree with you: It takes years - *and* the right people!