I argued in my first article about stand-up meetings that the right participants were the key to a successful meeting rather than whether the participants were standing up or sitting down. Despite my dislike for forcing people to stand up, I mentioned in that article my positive regard for other elements of the standard stand-up meeting.
What elements do I like? Why do I like them? How can we innovate?
Three elements of a SCRUM stand-up meeting stand out for me:
- Knowing the agenda
- Limiting duration
- Minimizing participants
Knowing the Agenda
A daily SCRUM stand-up has each team member answer the following three questions:
- What did I accomplish yesterday?
- What will I do today? and
- What obstacles are impeding my progress?
All the participants know what is expected. I like this a lot. If the participants know what’s expected of them, they are more likely to prepare.
I think there are opportunities to innovate on this solid agenda. Rather than verbally report status information, ask each participant to write their status on sticky 3×5 cards. Ask for a separate card for each element of their answer to the three questions. For instance, 1) Completed refactoring of module Gamma, 2) Created automated test cases for module Delta, 3) Will begin coding module Delta (expect 3 days to develop), 4) Intermittent failures on server Toledo are slowing my efforts.
As you do the round robin, ask each person to read their cards and post them on a community white board. Using cards will cause the participants to prepare something before they arrive at the meeting. That will increase the pace of the statusing. It will provide information for publication to people who are interested in the project but could not attend. It can be compared with 3×5 cards from the day before to detect problems.
I also think there is an opportunity to add a fourth agenda item—What do I propose? For instance, I propose we divert our efforts on accomplishing X and use them to accomplish Y. The answer to this question notifies the team that a member wants the team to make a decision. As with the answers to the other questions, the team is notified but it doesn’t discuss or decide during the daily stand-up. That’s done at a separate meeting.
Limiting Duration
The objective for the duration of a daily stand-up meeting is 15 minutes or less.
I like short meetings. As a participant, I also like to have enough time to share my answers.
I suggest you divide 15 minutes or whatever you plan for the duration of your meeting by the number of participants. Is that enough time for a person to effectively status their work? For instance, if you have 10 participants, there is an average of 1.5 minutes available for each participant. Is that enough time? That’s 0.5 minutes to answer each question. That’s enough time for me to status, but is it enough for your participants?
I recommend that someone perform the role of time keeper. Alert each person, I like to use a chime, when they are 30 seconds from their time limit. And again when 10 seconds remain. Stop them and move to the next person when their time limit expires.
Please, don’t stop someone in the middle of their report in the first few status meetings. At a point where the participants have had sufficient time to practice delivering status, it may be time to stop them. Without being at the meeting, I can’t know whether stopping them is appropriate. But you can.
Time in a meeting is like money in the economy. It’s capital. Use it wisely and you will increase your return.
Minimizing Participants
A principle of a daily SCRUM stand-up is the separation of participants from observers. The less the number of meeting participants, the more time is available to each participant to share status information. This is a smart action and I like it a lot.
I interpret there is more to this element than merely minimizing the number of participants. It’s about gathering the right people together and demonstrating to them that they have the authority, power, and responsibility to produce the product.
If your hiring process isn’t putting the right people in the meeting, minimizing participants will be less effective than it could be.
Gathering Feedback
There isn’t a feedback component that I am aware of in the standard stand-up meeting format. I believe a status meeting becomes more effective when it adapts to its environment through the use of participant feedback. Without feedback to improve a meeting, it becomes a picture of a sprinting cheetah rather than a real sprinting cheetah. Pictures of cheetahs don’t turn when its prey makes a turn, but a real cheetah does.
Find out what turns your team needs to make by gathering feedback about the meeting. See my blog post Measure ROTI (Return On Time Investment) to learn how to gather the feedback. Note, I don’t recommend gathering feedback every meeting: I suggest instead gathering it every third or fourth meeting. When you do gather feedback, respond to it; otherwise, a picture of a snoozing cheetah is apt visualization of the state of your meeting.
Final Thoughts
Too many people believe that stand-up meeting are more effective than traditional status meeting because the participants are forced to stand up. That’s a fallacy. Increased effectiveness results from the other elements of a stand-up meeting—knowing the agenda, limiting duration, and minimizing participants. The elements are classic elements of any effective meeting. The actual application of these elements is the root cause for a stand-up meeting being more successful than a traditional status meeting.
A possible benefit for forcing people to stand up is notification. Participants who have continually experienced ineffective status meetings—those with poor agendas, poor participant preparation, poor adherence to the meeting schedule, and poor choices about who will participate—may benefit from physical notification that the meeting has changed. Once the notification is complete though, standing up loses its value.
I know people from an earlier era who believe wearing a tie makes developers more alike and more disciplined. I don’t buy it. And I don’t buy the idea that participants should keep standing up once they understand the rules for participation. Forcing a developer to continue standing up is like forcing them to wear a tie. Both actions will make them uncomfortable and neither will improve their productivity.
Use the standard stand-up meeting format as a starting point. It’s a solid foundation. Don’t worship the format. Encourage innovation so that your status meeting better responds to the unique needs of your team.
For More Information
Jason Yip, It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings. It’s an excellent article.
You will find an abundance of information about this topic on the web. Search for “stand-up meetings” using your favorite search engine.
Jason Yip says
Hi Steven,
Would be interested in how this goes.
I’d love to hear about how this works out and I’ll see if I can find volunteers to try this in their daily meetings.
Steven M. Smith says
Hi Jason,
I like feedback
I look forward to hearing the results.
-Steve
heidi says
I really like the idea of the 4th “What do I propose?” Sometimes the team knows or ‘feels’ that its waiting for someone to propose something to make a decision. I’ve seen it almost bubble to the surface – and its often good to get it out in the open.
Steven M. Smith says
Hi Heidi, I agree. Bringing those proposals to the surface is the action of an effective leader. Any member of the team is capable of this type of leadership.