Daily Scrum is arguably the most maligned part of Scrum, often because it is one of the few Scrum practices that are adopted in the hopes they will be this silver bullet for everything that ails the team.
This, however, is a subject for another story.
Today, we will be looking at the different ways in which even the most serious Scrum Teams can negate the whole point of the Daily Scrum and turn it into a waste of time, or even a hindrance.
The Scrum Master leads the meetings
This is just plain wrong. A lot of Scrum Masters feel as though their responsibility is to lead the Daily Scrum and hold the Development Team’s hand.
Daily Scrum should always be led by the Development Team and them alone. The Scrum Master is there to support them, ensure the meeting doesn’t go over the time limit (15 minutes max) and that everyone is heard.
It is not the time for Scrum Master grandstanding and micromanagement.
Daily Scrum for status reporting
This is another anti-pattern that should be avoided at all costs. Daily Scrum isn't meant to be a status report event for the stakeholders.
That's what Sprint Review is for. Again, Daily Scrum is designed so that the development team can prepare for the day ahead and review their daily activities.
Daily Scrum is a waste of time
You'd be surprised as to how many development teams think this way so they eliminate Daily Scrum altogether.
The teams that don't see value in Daily Scrum either aren't doing it right or someone didn't explain to them the purpose of this activity.
Avoiding Daily Scrum isn't good and it's an anti-pattern that needs to be resolved quickly. The teams simply must see value in inspecting and adapting their plan on a daily basis.
Lack of respect
Someone came in late for the Daily Scrum and someone didn't show up at all. This creates distrust within the team. Lack of respect for such meetings and fellow team members is a foundation for any number of things that can and will go wrong eventually.
If there's no teamwork, collaboration, trust and cooperation within the development team, it will fall apart and the project will suffer for it. This anti-pattern is the bane of a well-functioning team that development teams should strive to be.
Stakeholders and managers taking over the meetings
This is worse than the Scrum Master running the meetings. Stakeholders and managers can be present if the Development Team agrees with it and, even then, they have to understand that they cannot participate in the meeting.
Even if this is very clear, their presence may make the Development Team feel observed and evaluated and if this happens, they should make this clear to the Scrum Master who will then put a stop to the practice.
You must ask the questions!
What did we do? What are we going to do? What is blocking us? Is the pizza here already? Let's be honest here, questions are, indeed, important in Daily Scrum but they're under no circumstances mandatory.
Many development teams were taught to ask questions at all costs but that's just an anti-pattern. A Daily Scrum should go the way the development team wants it to go.
In other words, whatever works best for them. Oftentimes, the teams need to be coached to embrace this mentality and run their daily meeting as they see fit.
Forget about the quality
One of the greatest anti-patterns that is usually imposed on the development teams is to not focus on the quality of the increment. CEOs want speed to market. They want things done yesterday and in most cases, the teams have to deliver.
The first thing that goes out the window here is quality. What managers and executives fail to understand is that it's a lot more expensive to fix bugs and defects after the product release than it's to fix them upon discovery.
If you want an Agile environment and Scrum framework, quality comes first. Therefore, the teams should be encouraged to talk about issues at Daily Scrum and fix bugs, defects and whatnot as soon as they discover the problem even if it means the stats will be jeopardized (it should never be about velocity).
Not defining the done
The definition of done should be clearly stated at the beginning of the project. The development team decides what done is and the rest of the organization agrees with it.
Therefore, there's no "almost done", "close to done", "technically done" and so on and so forth. It's either done or it's not. If you don't define this from the very start it becomes difficult to manage tasks and expectations. Your Daily Scrum turns into an endless debate about "is it done yet?".
Daily Scrum anti-patterns can be found everywhere. The problem occurs when these anti-patterns become a habit. Anything that can hold the teams back is considered an impediment and it should, therefore, be avoided. That said, you can always adapt as you go. After all, the Scrum framework is about continuous improvement as part of the Agile methodology.