Does your Daily Scrum feel a bit like the movie Groundhog Day?

The idea for this post was sparked by a text this morning from one of my former students who I have anonymized below as Development Team Member (DTM):

Despite the subtext of humor, DTM is clearly frustrated. She has just endured an hour’s long ordeal of (mostly) gibberish. That much is clear. What is not so clear is whether the team has a plan for working together over the next 24 hours. Nor is it clear as to how the team is progressing in relation to their Sprint Goal and their forecasted increment.

Where was their Scrum Master? How did this happen?

Words lose their meaning

Agile, Scrum, Lean, Daily Scrum… these are just words. Good ideas lose their positive impact when the words we use to describe them and their underlying practices are not understood in the same way by all stakeholders. For example, while we may understand what we mean by “Daily Scrum”, it is unreasonable to expect someone unpracticed in the correct enactment of the Scrum framework to share this same understanding. Jargon is not a substitute for an effective conversation!

Unfortunately, there are probably more examples like the one above of “bad” Daily Scrums than there are of good ones. Attempts to become agile through “magic” meetings with “magic” incantations such as “What did you do yesterday…?” are ineffective without a keen understanding of the why behind the question and the expected outcome of the meeting. If we can’t get a Daily Scrum right, what hope do we have to change the way we engage with our customers?

On a positive note

In the text exchange above, DTM has an idea as to how to improve the meeting. The “ball” she suggests bringing next time will serve as a talking stick to support her team’s agreed upon “one speaker” team norm at the Daily Scrum. Another idea DTM’s team might consider is a visible timer to serve as a reminder that the Daily Scrum is only part of the day’s “work”. (Scrum reinforces this idea through its rule limiting the Daily Scrum to a 15 minute time-box).

Most important, DTM’s insight for a way to improve the team’s way of working together is in the spirit of Agile. The authors of the “Manifesto for Agile Software Development” had in mind a sense of adaptability grounded in learning. DTM’s frustrating experience in today’s Daily Scrum is learning that will lead to the type of adaptation that the authors intended — and that is an outcome that transcends magic words, jargon, and gibberish.