You’re Doing Your Daily Scrum Wrong!
Who hasn’t heard that phrase? I wager everyone ever to work with Scrum has been told by someone, they’re doing it wrong.
In my line of work I see processes for many different products, implemented by many different people, employing many different styles. And it’s been eye-opening.
I’d like to share some observations with you. Some concerning best practices, some concerning commonly seen mistakes. And I don’t want to just preach to you, I’d like to make you think about why something is a good or bad practice, understand the consequences of your choices in the matter, and be ready to adapt your workflow to your unique context.
As a fourth installment of this series, let’s talk about…
How To Do Daily Scrum Meetings
Lately I’ve heard people discuss whether having daily stand-up meetings wasn’t just a waste of time. I heard various reasons for this stance, and they all did point to some fundamental misunderstandings about what that meeting actually is for, and how it’s supposed to be conducted.
The daily scrum meeting’s purpose is to allow the development team, that’s all the designers, engineers, QA — everyone who actually works on making the product — to coordinate their work for the day, raise any impediments they may have, and risks to the successful fulfillment of the sprint goal they can see, and prompt focused follow-up meetings to deal with any such issues that may require longer deliberation.
Yet, what we often encounter are meetings that absolutely do not fulfill this purpose and instead are conducted in a manner that runs contrary to the very notion of scrum.
Common Mistake “Status Update”
No, the scrum meeting is not a status update, and especially it’s not a meeting where the development team reports to their managers and/or stakeholders on their progress! Sprint progress can be seen on the sprint backlog or board, being in a daily scrum to learn about the team’s progress is wasted time for anyone not directly involved in the implementation of the sprint scope (e.g. PO, stakeholders).
Common Mistake “Discussing Issues”
No, the scrum meeting is not the time or place to discuss your issues. It’s the time and place where you mention that you have such issues and may ask that whoever might be able to help come see them after the meeting to discuss the matter, and for people who realize they can help, to say that they can and will do so after the meeting. Keep it simple, only elaborate as much on the issues as is absolutely necessary to identify who might be able to help with them, nothing more. Why? Because time is money, and more time is more money. We want to respect people’s time and get the meeting over with so less, but the right people, can tackle the individual issues brought up, no need to bother everyone with issues they cannot help with.
Common Mistake “Everyone Gets To Speak”
No, not everyone attending a daily scrum meeting gets to speak. Only the development team gets to speak, everyone else attending may only speak when asked to, or in response to a raised impediment they can do something about. Nobody cares the PO talked to the stakeholders yesterday, wrote five new stories,and will talk to the stakeholders some more today — only activities related to the implementation of the sprint’s scope are the subject of this meeting. If the team is very large, a ‘core team’ may be designated to speak instead of every individual contributor, but that’s a scaling issue best left for a separate article.
Common Mistake “It Doesn’t Matter When”
Yes, it does matter. This meeting is meant to help organize the day’s work and should thus be the first thing the team does on that day. Alternatively, move the meeting to a natural break time like lunch-time. Remember that we expect there to be follow-up meetings and we don’t want them to be hours from now but ASAP in order to quickly remove impediments — that’s not possible when there’s no time after the meeting, i.e. at the end of day. Also consider that meetings are always a disruption, people, especially developers, need some time to get ‘in the zone’ and meetings always pull them out of that state. This is why this meeting is supposed to happen before work begins, in order to minimize the disruptive impact it may have otherwise.
Deeper Issue “Tasks Are Not Vertical”
Sometimes I hear the complaint that people’s tasks and their impediments and progress does not matter to most of the remaining team. When I hear this, I shake my head, because it reveals that the team is not actually owning tasks jointly, which is most often a consequence of layered/horizontal task structures. Indeed, a daily scrum may loose a lot of its appeal when each person has their own independent queue of work to complete. The backend people work on the backend story, the frontend people on the frontend story, and the designers delivered the designs for this week last week anyway, the architect is tinkering on how to solve next sprint’s problems, and QA is only waiting for developers to submit their code anyway, right? No! This is not how a scrum team is expected to work!
In a proper scrum setup a given backlog item will typically need multiple skillsets to successfully implement it. A new value may require a screen design, graphical assets, frontend code, and backend code, and maybe some infrastructure work, and test cases — and maybe all these things need to happen in multiple smaller in-sprint iterations where the team takes it as far as they feel they need to in order to fulfil the business requirements as they understand them.
Frankly, if you find yourself having this problem, maybe having a scrum meeting is not useful to your team, because you’re not using scrum to begin with. Scrum’s rituals are designed to work with scrum, they’re not a magic catch-all wonder-process that will turn what you do agile and efficient.
Deeper Issue “Making Ad-Hoc Decisions”
While the PO may be useful to have in a daily scrum in order to quickly clarify things on the spot, they are not here to hand down product decisions that may affect the sprint scope, nor are they there to discuss the strategic implications of certain things. Similarly, the daily scrum is not the time nor place to cast votes on how to proceed with some task, or make design decisions, etc. It is exclusively a meeting to allow everyone to be in the know, and prompt follow-up discussions so as to address any issues in a timely manner and control risk.
If any decisions are prompted by this meeting, they ought to be documented for all to see — some teams use decision logs, the PO maintains a Product Backlog, etc. The daily scrum is not the place to announce such things, if anything, it is the place to mention that such and such decision has been made, or will be made, so everyone can be aware of it, especially if it has some impact on their work.
Say a stakeholder is attending the meeting and they are a domain expert from the organization and know that the technology guideline for something is about to be changed, they may want to announce such a thing to the team if they feel it may have an immediate impact on their work.
But not every issue needs an immediate ad-hoc decision, it’s okay to just take the input and get back to the people who care with a well thought-out decision, or discuss the matter with them after the daily scrum.
Summary
The daily scrum meeting is a tool made for a very specific purpose. You can adapt it to your needs, but the moment you change its purpose, or apply it to something it was not meant to be, you’ll lose many, if not all, of its benefits.
Scrum was designed to work with every part of scrum, not some parts, and not others, not with some parts done wrong. It may sound like a broken record by now, but ‘if scrum isn’t working for you, you’re not doing it right’. So, if daily scrum meetings are not working for you, it’s probably because you’re not using them right, or you have some deeper underlying issue in your process.
As always, I encourage the reader to give their thoughts on the subject, let me know what I might have forgotten to mention, or what you feel I got wrong, or what you’d like me to write about next — thank you.
