What Can Possibly Go Wrong With… The Daily Scrum?

During some 1 on 1 coaching sessions today the topic of dysfunctional Daily Scrums came up from 3 different people. Before I go into what I think and experienced, let’s revisit what the Daily Scrum is for.

• It is a 15-minute (maximum) time-boxed event for the Team.
• Held every day of the Sprint.
• At it, the Development Team plans work for the next 24 hours.
• The Daily Scrum is held at the same time and place each day to reduce complexity.
• Optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work.

The Daily Scrum is not like a “classical” status meeting, because:

• Improves communication! Dysfunction alert: assuming people pay attention to what is being said.
• Eliminates other meetings. Dysfunction alert: from time to time I hear complaints that Scrum is death by meeting. That is the case when you add the Scrum ones and do not get rid of the other ones!
• Identifies impediments for removal. Dysfunction alert: people should not wait until the next Daily Scrum to report impediments, and often they do ?
• Highlights and promote quick decision-making. Dysfunction alert: only when they act like a team.
• Improves the development team’s level of knowledge. Dysfunction alert: assuming people pay attention to what is being said. Oops, did I just repeat myself? ??

Speaking of dysfunctions

Another sign of dysfunction is when you have zombies in your Daily Scrum.

You know, those types that are just standing there unless it is their turn to talk and then they talk and immediately after that they shut down again.

Another sign of zombieship (yes, I made that word up just now) is the reciting of the 3 questions in a very mechanical way without connecting it to the Sprint and team’s goal or anybody else’s work in the team. Basically, this is my status and that is all I care about. Yes, I could call it dysfunction but zombieship sounded better.

In case I did not mention it enough times, it is not a status meeting!

This is not just about you as an individual but it is about how can you be part of contributing to team so it can meet the Sprint goal.

Dysfunction alert: the team must have a Sprint goal!

Dysfunction alert: the team must act and perform as a team!

An old analogy that I always use is that the hole in the ship is not on their side of the ship, it is rather in the ship that you are in with them!

In military jargon, it is about unit cohesion! If you are not paying attention to what others are saying during the daily Scrum, you are a silo and we all know how “good” silos are for flow, don’t we?

A planning meeting for the day should have people talking about what each one is doing and how they can help each other or, even more important, ask for help when needed. Individuals and interactions!

Personally, I don’t like zombies, I think vampires are way cooler, zombies just stink! Zombies in your Daily Scrum are a major dysfunction. Unfortunately, I see lots of zombies and often.

Just yesterday a Scrum Master complained that his team appears to be doing multiple things during the Daily Scrum. He thinks it is because everyone is remote. I attended it today and I found that everybody had their cameras off, and you could tell that people were doing other things just by the delay in coming “live” after the previous person. I guess the pod where the Borg drone was waiting for his turn to talk was in power saving mode ??

I suggested that the Scrum Master revisits their team agreements with them to make sure cameras are on and people are there and participating, you know, for instance, paying attention to that others are saying. I found out that they did not have a team agreement. This was not a new team! Warning, multiple dysfunctions, Will Robinson!

Speaking of dysfunctions, look at these:

Scrum Master:

• Managing instead of leading.
• Scrum is consistently over the time limit. I had a team that 3 months ago was taking 45 minutes for the daily Scrum, now they are consistently between 4-6 minutes.
• Tasks are not flowing thru the system. You know, those cards that don’t move and nobody makes them move. This is not only a Scrum Master thing; it is a whole team thing.
• Obstacles not identified or removed.
• Assigning tasks to team members.
• Team shows dysfunctional behaviors such participation, commitments, performance and the ones I mention above.

Speaking of dysfunctions, a few years ago I was doing my Gemba walk and stopped to observe a team during their daily Scrum. I heard the following:

Team member: “I am still waiting on the artwork and I can’t proceed.”

Scrum Master: “Leave it to me. I will send a couple flaming emails!”

Incidentally the person needed for the artwork was on the next building. You can guess what my suggestion was ??

Product Owner:

• Unavailable to review completed items.
• Unavailable to answer questions, discuss assumptions and thoughts.
• Telling teams members how to execute a task.
• Assigning tasks to team members.
• Misrepresenting the users and/or stakeholders.
• The sole creator of backlog items.
• Detached from the team.

Yes, I am aware that true Product Owners, not the puppets, sorry proxies, that cannot decide without going to ask someone and taking 2 days to come back with the answer, cannot be in the daily Scrum every day. The key here is being able to answer questions from the team in a timely manner even when not present at the daily Scrum.

The cost of delay is always very high and, Product Owners need to understand that.

I hope this article starts some conversations… Feel free to add to the list of dysfunctions. It is always good to have “war stories” to use as examples.