Daily Scrum
About a month ago I talked about why we got rid of the daily stand-up. There seems to be a lot of discussion about this Scrum Event lately. With that in mind I decided to spend a little more time on what this meeting is supposed to be.
Pro-tip: If you are interviewing someone for an Agile Coach position and they suggest that Daily Stand-Ups are a core part of Agile feel free to politely end the interview. Even if the position is for a Scrum Master I would take it as a red flag. They have potentially bought into the idea that Agile is equal to Scrum. (Hint, it isn’t.) They are also likely to have trouble modifying Agile Methods and Processes to fit your environment. Especially ones other than Scrum. Of course, they should know that the Daily Scrum is a required event in Scrum and what most people mean by Daily Stand-Up.
According to the Scrum Guide the Daily Scrum is a meeting. It is no longer than 15 minutes. It is held at the same time and place each day. The meeting is for the development team. The goal by the end is that the development team has synchronized their activities and created a plan for the next 24 hours.
The meeting is short to promote quick decision-making. The short length also encourages good communication. Complexity is reduced by having it at the same time and place every day. While not required by the Scrum Guide many teams will gather in a shared space without sitting down. (Hence the term Daily Stand-Up.) Often the shared space is he home of a physical representation of the Sprint Backlog, or at the very least the Sprint Goal.
The team members feed into the meeting by sharing what they did over the previous day to help the team reach their Sprint Goal. They also share their plans for the day after the meeting. Finally anything they see as blockers for themselves or the team is pointed out. There are two key points to notice here. The Development Team Members are the ones sharing. They frame their information in respect to the team reaching the sprint goals.
This meeting is for the development team alone. Regardless of who else attends only the development team participates. The Scrum Guide is silent on Product Owners attending. I would posit that only mature teams should allow this, and if the Product Owner also plays Project Manager they should not attend. (Project Manager is not a recognized role in Scrum but can exist for teams doing Scrum.) The Scrum Master ensures that the meeting takes place but does not need to attend. The Scrum Master instead teaches the team how to derive the value they need from the meeting. (If the meeting exposes problems with the processes or environment the Scrum Master may be responsible for addressing them.) This value is largely derived from inspecting the work done, adapting as necessary, and planning the next pieces of work that will be done.
The base Daily Scrum is simple, small, and fast. “Scrum-but” can easily distort this meeting, subverting it for other purposes. “Scrum-and” can derive extra value from this meeting, but needs to be careful not to distort the meeting.
What challenges have you had in keeping the “but” out of your Daily Scrum? Conversely how have you successfully brought in the “and?”
