We started a new sprint last Tuesday. And we had our first stand-up of the sprint the following day. It didn’t go as well as I would have liked (we have three developers and one doc/testing person on the team; we then have 2-3 managers, a scrum master, a product owner and a agile coach all in the room). The meeting, and the going around the room with all of the people, was taking a long time, and non-developers were causing us to lose focus from the sprint goals. People were focused on what they were doing, rather than the team goals. The meeting had become one of “tell us what you’re doing” and not necessarily making progress. It had taken on aspects of what I call the “tell us what you did on your summer vacation” sharing at meetings.
I realized the problem when we had our stand-up two days before the close of the sprint. Everyone in the room did their three sprint questions, and we were about to adjourn. I innocently asked “What is your confidence that we’ll make the sprint commitment next week, and that there isn’t anything blocking the completion of those stories?” That sparked five minutes of fervent discussion, with people taking responsibility for the various bits needed to get to completion. But it does show that the daily scrum was not as focused as it could have been. I’d read posts like Mike Cohn’s “A weighty matter for the daily scrum,” but don’t think we’re ready for that yet.
There was also a thread that the stand-up was for reporting progress to the project manager. We made clear that this is for team facilitation, not for management. The three of us on the process decided to make a few changes, which will be refined over time. [The only management thing that we need is for everyone to update their remaining time on their tasks before the stand-up.]
- The three sprint questions and the sprint goal will be visible in the room. And these will be the “new” questions (see below). Hopefully on 11×17 paper in large print.
- People are on time, and we expect people to be present electronically if not physically.
- The scrum master opens the meeting with the burndown chart and any general observations.
- The only people who are in the round-the-room are the developers.
- The first developer is a person who is working on the current top incomplete story, as the focus is to finish the prioritized stories. Anyone in the room can join the discussion around that developer’s topics, as needed. But the general rule for non-developers is to only speak if you have a significant contribution to the topic. Keep the focus on the sprint goal. After the top priority, we go around the room to developers in whichever clockwise view works for the day.
- If a developer has been distracted or is working on other projects, they bring this up to the team. At a minimum, the team should determine if that person’s effort is needed to complete the sprint goals, and possibly have the scrum master go out to people outside the team to get that person’s attention back on the sprint goals instead of what they have been directed to.
- After all the developers have gone, the product owner, if present, may bring up anything.
- The scrum master then adjourns the scrum.
- If any stories were thought to be closed, the product owner might close them then, or schedule a future meeting with the right folks to review the story.
For reference, the “old” three questions for a daily scrum:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
The three questions, as stated in the new Scrum Guide:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
What’s different? I didn’t appreciate this when I heard Jeff Sutherland a few months ago. But I am appreciating it more now. First, it puts the focus on the team and not the person. That’s subtle, since the team is comprised of individuals. But the larger shift is that it focused the team on meeting the sprint goal. It’s not just that work has been done, but that progress is being made towards the overall goal. We started this focus in this sprint and, after a few days, it seems to be working. Our daily scrum should be more focused, shorter and more productive in the future.
I’m liking the shorter, focused stand-ups. Any meeting that accomplishes its tasks and ends early is good in my book.
P.S. In our first daily scrum with these rules, we noticed that we had two stories with all of the tasks complete. What was odd was that a card marked as done (in the done lane) was also marked as blocked: the code needed to be rolled onto the production server, and that was an acceptance criteria. The story wasn’t done. There should have been another task, or the task moved back to an earlier stage before done. We elected to push it back a lane, but it was my first experience of the difference between done and done-done. That’s a topic for a future post.