Meeting Design: Agile Style Daily Scrum
Kevin Hoffman is the master of meetings. In his new book Meeting Design from Rosenfeld Media, Kevin lays out exactly how to take on meetings as a design problem, but you don’t have to be a designer to appreciate this advice. He deftly illustrates how the designer’s toolkit—a collection of questions, activities, and conversations—can be applied to create the best outcomes for these age-old activities. We’re excited to provide the excerpt from Meeting Design below.
The daily scrum is the heart of an agile process—it’s the meeting you’ll have the most often. The name “scrum” is based on the “scrummage:” the part of a rugby game when play restarts after a foul occurs or the ball goes out of bounds. Everyone from each team grabs for the ball huddled together in a circle and then puts their heads together in interlocking fashion. Afterward, play continues from that point. In an agile scrum style meeting, everyone is grabbing for work to undertake.
Goal of an Agile Style Daily Scrum
Hopefully, daily scrum meetings are not as dangerous as a scrummage on the rugby field. But the intention is similar: getting the project back into play from where work last stopped. It usually happens in the morning, and its goal is broadcasting information. A scrum meeting establishes a shared awareness of what everyone on the project completed yesterday, what they are working on today, and what barriers they are encountering in their tasks.
It’s not uncommon for people outside a project team, such as senior leadership, to sit in on a daily scrum as a way of checking on progress. But it’s not a good idea for those people to contribute to the discussion. Extended analysis is against a scrum’s purpose, which is to get a detailed picture of project progress that has happened in the past 24 hours. Further discussions or problem resolution should happen immediately following a scrum, but outside of it, so as to protect the working time of the team.
Measuring the Outcomes of a Daily Scrum
Kanban is a flavor of agile methodology, which uses a “kanban board.” The board is a visual tool for capturing the activities reported within a scrum meeting. It’s a series of columns in which cards (work activities) can be placed. A basic kanban has three columns (from left to right): items to do, items being done, and items completed. These correspond to the three components of the daily scrum discussion: work identified that hasn’t been done yet (column 1); work that is in process (column 2); and work that has been completed (column 3). A productive daily scrum meeting can be measured by the quantity of items that exist on a kanban board, and the overall progress those items are making from the left to the right.
When there are a lot of items added in the first column (to do), you know the scrum is working because work is being identified. When items are moved to the second or third column, the kanban board conveys the active health of the project. Time-lapsed photography of a kanban provides insight into the increases and decreases in work quantity. Tasks that are problematic will get stuck in the middle column, so it’s a good idea to include a limit for the center column. This can be based on the number of items assigned to a single person at any given time. For example, “There should never be more than three items assigned to anyone in the center column.” These limits are referred to as work-in-progress limits, or WIP limits.
Kanbans can be much more complex than three columns. If you’re new to the concept, these three columns are a good place to start. More advanced variations on the kanban board might include fully articulated steps in software development. Here’s a five-column one that includes steps for backlog and quality assurance testing.
Sample Agenda for Agile Style Daily Scrum
(Roughly 10 minutes, not to exceed 8 people)
The person who facilitates a daily scrum is called a scrum master. That person is tasked with facilitating the movement from scrum to scrum and column to column. There are plenty of articles, books, courses, and certifications out there promising to make you a good scrum master, if that is your role. At a basic level, keep in mind that the scrum master is a manager of tasks, not people.
If you’re the scrum master, start the meeting on time, regardless of who is in attendance. One by one, each team member reports the work that they completed yesterday. The scrum master then moves each item to the appropriate column in the kanban board.
Any new assignments that result from completed work are noted by the scrum master for later addition to the kanban board. The scrum master and the team are careful to note any WIP (work-in-progress) limits for the “doing” column.
Each team member reports the work that they intend to undertake today. The scrum master moves the corresponding tasks from “to-do” into “getting done.”
Finally, team members share if they feel unable to begin or continue a task due to an unmet dependency. The scrum master notes those dependencies and identifies which team members will need to have further discussion, outside of but immediately following the scrum meeting.
That’s it—it may sound simple but it’s highly effective at identifying workflow dependencies inside (and outside) of a team. An effective scrum master will keep the meeting duration to a minimum, as well as remove a few task barriers if possible.
