A "How To" for the Daily Scrum
The "daily scrum" is a popular practice; it's that daily "morning meeting" where a team goes through where everybody is on their tasks so far and what they're working on next. In spite of being commonplace, I've rarely seen great consistency in how it is conducted. Although the recommended guidelines for the daily scrum are easy to find, I've found in practice organizations tend to put their own spin on it to meet their perceived needs.
While purists might argue this should be avoided, I think this is a symptom of something worth considering, which is to say the "how" of the daily scrum benefits from an adaptive approach. Consider that the originators of scrum based the daily scrum on what worked well for their environments and the type of projects they worked on. Could it be that different situations merit a few tweaks?
There is however, a good reason for not straying too far from the recommended advice of Jeff Sutherland, Ken Schwaber, Mike Cohn, and others who have contributed to the practice of the daily scrum. That is because it is easy to misunderstand or neglect some important principles if we simply think of it as a "meeting format" which can be adjusted arbitrarily.
Let's review the classic "rules" of the daily scrum that people tend to get, that people tend to break, and that people tend to overlook. Most people are aware of the "three questions" that each team member is supposed to answer during the daily scrum:
What did I do yesterday?
What will I do today?
Do I have any impediments that are slowing my progress?
There are other recommended practices that are more subtle:
The daily scrum should be a standing meeting (as in everybody stands instead of sits).
The daily scrum should last no more than 15 minutes.
The daily scrum should occur around a task board/burn-down chart which makes progress visible and measurable.
Side or follow-up conversations should be tabled for after scrum.
Stakeholders can observe the meeting, but as silent witnesses.
My advice is to limit any tweaks to this until you have given your best shot at achieving each of the above. The truth is, many organizations break one or more of these practices without realizing its detrimental effect, thereby reducing the effectiveness of their daily scrum. Here are some classic errors I've observed:
Confusing "Impediments" with "Blockers"
I often hear the term "blocker" used more than "impediment", and I understand why. It sounds more serious and urgent; if I say I have a "blocker" it wakes people up, which is exactly what we want to do. There's a good reason for embracing the term "impediment", however, because it addresses more scenarios. A "blocker" means something has stopped you completely. An "impediment" however, applies to either being stopped or slowed down. This is an important distinction, because our foremost goal should be not only to remove obstacles, but also to reduce inefficiency. To do this, we want to communicate and make visible everything that is dragging down productivity, not just stopping it altogether. This important aspect may be lost from the daily scrum if the question is "Do you have any blockers?" vs. "Are you experiencing any impediments?"
Sitting Around a Table
Many scrums are held in conventional meeting rooms, with a table and chairs. This encourages people sitting down for the meeting (I have been guilty of this myself). The problem with getting comfortable is that it tends to draw out the meeting longer then necessarily. Sitting down makes it feel like a "regular meeting". The problem with regular meetings is that we bring all our bad habits with us that we're accustomed to. We spend time "settling down" for the meeting, we engage in small talk with our neighbors, we speak more than necessary, we entertain tangents to the agenda, and so on. Forcing everyone to stand during the meeting is a simple discipline that breaks the team out of the normal meeting "pattern" and encourages them to be brief, to the point, and on agenda. It flows better because everyone is focused on efficiency so they can sit back down again. A byproduct is that a quick, productive meeting tends to energize whereas a long, meandering one tends to drain. Thus, a morning scrum, when properly conducted, can set up a good momentum for the rest of the day.
Going on Tangents
Side discussions to the scrum agenda can sabotage the intended benefits of the daily scrum. They can drag out the meeting, resulting in the meeting fatigue we are trying to avoid in the first place. Furthermore, those team members who are not involved in a side discussion may get bored and their minds will wander, setting up poor engagement for the rest of the day. It is normal, in the course of the daily scrum, to identify that there are certain conversations that need to happen between team members to work through various issues. Table these conversations for after the scrum, not during it.
Not Using or Maintaining a Task Board
Though not always mentioned as a daily scrum principle, I've found scrum to be remarkably more efficient when it's conducted around a scrum task board. It doesn't matter what kind of board it is; it could be a physical board composed of post-it notes, or a projected or shared software screen. The important thing is that it identify all the tasks team members are working on, and their state of progress. This is more efficient than doing scrum without because it helps people remember what they just worked on and see what they have to work on next. With everything that goes on in the typical workday, these things quickly get lost in the "haze" and it's easy to miss or forget something. More importantly, it serves as an early warning system. It gives visibility to tasks that are impeded or have been stuck in the same status for several days; and we can, if we're re-estimating during the scrum and maintaining a burndown chart, forecast if we're on track to complete things on time. By making sure everything we need to do gets put on the task board, we greatly reduce the chances of things "slipping through the cracks". With the entire team looking at it daily, it also drives energy towards progress. To keep a good momentum, I recommend breaking down tasks such that they can be completed within a day, or a few days at most. This allows team members to frequently put tasks in the "Done" status. That feeling of getting tasks "Done" on a frequent basis is exactly what we're going for.
Not Leaving Judgements at the Door
Here's a revelation: the daily scrum is NOT really a status or reporting meeting. A status or reporting meeting implies judgement by a central authority to determine if progress is "satisfactory" or to grade individual performance. That's not what the daily scrum is about. A better term I've heard used is that the daily scum is a "coordination" meeting. It's so the team members can coordinate with each other--to sync up their efforts, offer assists to anyone running into difficulty, manage team expectations, identify needs for collaborative trouble-shooting and brainstorming, and so on. As such, no one should ever show up to the daily scrum afraid to participate. If for some reason the team is concerned about a certain team member, this should be addressed outside of the daily scrum. During or after a team member communicates in the daily scrum, there should not be any judgmental reactions from anyone else on the team--managers and stakeholders included. Neither accusatory nor defensive behavior belongs in the daily scrum—period. The daily scrum should be considered a "safe space" where we focus on solving problems and getting things done, not on judging people.
The points above are important principles that contribute to the daily scrum being an effective practice. As I mentioned at the beginning of this article, however, sometimes you have to adapt to different circumstances. Before you do so, it's important to understand the "why" behind the traditional daily scrum advice. This way, if you make adjustments to how you conduct the daily scrum, you can compensate accordingly. I'll give you some examples from my own experience.
For the past 10 years, my situation for practicing the daily scrum has been within the context of a digital agency (three different digital agencies, to be exact). Within this context I've often faced the following circumstances:
Team members working remotely
Managing multiple projects simultaneously with the same team
Working with multiple clients who add or change task requirements at moment's notice
Acting as a consolidated "product owner" for the aforementioned clients as well as scrum master
This deviates from the assumptions that a team is co-located, fully dedicated to the same project, works for a single product owner, etc., all of which scrum normally assumes. Nevertheless, I have found the daily scrum to be an essential and valuable part of managing under these circumstances--with a few tweaks. Here's how I do it:
The Daily Scrum Via Screen-Sharing
When your team is remotely distributed, this is pretty much a necessity. To make this work you need a software task board, a screen-sharing application, and a conference call line. To make this efficient I have a few rules:
The board is prepped before the call
Everyone announces themselves when they join the call
If someone knows in advance they will not be able to attend, they send an email summary
Scrum starts no later than 3 minutes in
Team members engage in the same order every time
This is part of extending the "get-in and get-out" philosophy of scrum when you are doing it by conference. When people join the screen-share I have the board up and ready to go; no time is wasted getting "set up". I want roll call to be quick; since I am unable to glance around the room to check who is in attendance, I ask for each person to identify themselves when they join the call. This is far more efficient then hearing a bunch of beeps and then asking "who is on the call?"
I also cannot afford for people to make a habit out of dialing in late. That's why it is important to start promptly and make it clear to everyone that waiting time will be minimal. Anyone who dials in late is kicked to last place in line if their turn came up and they were not present. That should not become a habit of course (if it does you should coach the team member outside of scrum).
Most software task boards allow you to sort tasks "by assignee". I find this to be a useful way to determine the team order. Consequently I often end up calling people in alphabetical order according to their name. The exact system doesn't matter; you just need something other than going "clockwise" around the room since you are not in one, and you don't want to waste any time figuring out who is going next.
Finally, if people are not able to attend the scrum for any reason I ask them to at send an email summary to the team in their absence, preferable before the usual scrum time. This should include commentary on the "main three" questions as well as any additional questions or comments they want to communicate. Remember that this email, just like scrum itself, is a summary for the benefit of the entire team, note a "note" to the manager.
Multiple Prioritized Projects on a Single Task Board
Because I manage teams that are often working on multiple projects for multiple stakeholders (such is agency life), I look for a task board where I can either group or label tasks by the project to which they belong. For small teams and relatively small projects, I find this much more efficient than having different scrums for each project. It's very important to make sure team members don't try to do two or more things at the same, or to work on things in the wrong order. To make this clear, I put all the tasks across all the projects on the same task board. Why? So I can prioritize them against each other and have visibility across everything the team is working on.
Sometimes the priority of a particular project can change overnight due to a client request; other times projects get put on hold altogether. Therefore it is very important for me, as the "consolidated product owner", to organize the projects and tasks on the task board in the proper order. This is a somewhat unique distinction for how I handle the task board, as the normal assumption is that the team can do tasks in the order they deem best, as long as it all gets done by the end of the sprint. That is not always necessarily true in the agency business. It is sometimes the case that whatever we're working on in the current sprint is not committed to be delivered until the end of the sprint; when this is the case, then yes, the order is not critical as long as it all gets done. However, our workload in the sprint may include "maintenance" items that are expected to be completed before the end of the sprint, such as a page update, or a bug fix, or a research project. I take all maintenance tasks, size them, and put them in the sprint and on the task board because they subtract from available capacity to get other work done. The key is to always balance the priority, size, and scheduling of maintenance tasks with other project work in a sprint so the team doesn't get overloaded or behind. This means very closely following the status of every task, and re-prioritizing them should things change.
Active, Not Passive
As a consequence of the above, I sometimes need to communicate new changes or priorities regarding tasks team members are working on. I'll frequently communicate these outside of scrum, but may give a brief reminder or update during scrum as well. I'll wait until after a team member is done taking their turn (avoid interrupting anyone's flow); if they bring up the new information themselves, then everything is fine and there's no need for me to interject. If it's not brought up then I'll make a quick note of it: "As an FYI, client A gave us some feedback that we need to make such-and-such adjustment, so please see the additional notes I added to the JIRA ticket"...or something similar. What's the point of this? The point is that nothing beats good, frequent team communication for making sure balls don't get dropped and everyone is synced up.
The daily scrum is one of those opportunities--a brief one, but an opportunity nonetheless when the entire team is assembled and listening to each other. Furthermore, I'll sometimes ask questions about particular tasks if I need information for planning purposes, for getting back to the client, or just to make sure we have everything we need to work on it. In other words, the scrum is not simply a "passive listening" exercise for me; I'll follow up as needed to make sure the team is aligned and running smoothly. In fact, I allow (brief) comments or questions across the entire team after each team member completes their turn at scrum. Especially with remote teams, the daily scrum is often the only time everyone gets together as a group and becomes aware of what others are doing. Often others on the team will have questions or insights to share with each other that aremore beneficial than anything I have to say. Allowing the team to interact productively during the scrum is a help, not a hindrance. A good team will recognize quickly when a follow-up conversation after scrum is called for and will arrange it. I have found that these extra conversations that happen "around the edges" of scrum are among its most valuable outcomes.
Creating and Assigning Tasks to Myself
Even though I typically fall into the project manager/product owner/scrum master category, I still consider myself part of the team. Although I don't take on development work, that doesn't mean I don't have tasks I need to perform for the team. To keep track of those, I add them to the task board along with everyone else. This keeps them highly visible to me, especially since the board is something we review on at least a daily basis.
First, if a task a developer is working on requires action on my part to un-impede it, get more requirements, or provide feedback, I have them re-assign the task to me, and add comments about what it is I need to do. This way I can review my list of tasks and make sure I follow up on them. And why not? If it works for the rest of the team, it works for me as well. As part of the daily scrum, I'll check the progress of my own tasks to make sure I'm doing everything I can to help the team. I'll re-assign the task back to the developer only after my part is done.
Second, if a project management-related task is identified that I need to perform, sometimes I'll create a new task for it and assign it to myself. It might be "Request file repository credentials for a new developer", "Show demo of prototype to client", "Research license for development software upgrade", or any other task which makes sense for me to take on so that the rest of the team can stay focused on development. Putting it on the task board and reviewing it at the daily scrum helps to make sure it gets done.
Conclusion
Even with all this, I'm still able to keep scrum quick. Sometimes it goes to 20 minutes or, on rare occasion a full half-hour, but other times it wraps up in 10 minutes. The important thing is that I strive to keep every minute valuable and beneficial to the team. Although I "tweak" the way I perform the daily scrum, I am doing so in a way that makes it a more effective management tool for my situation. Most importantly, my team is on board and engaged with the approach. Always remember this: the daily scrum is not for your benefit, it is for the team's benefit. Keep this as an organizing principle, and you will be able to execute--and adapt--the daily scrum to its highest potential.