“Our team is agile because we stand up for meetings!” It’s the perennial joke of the agile community. We’ve all heard of teams that feel that they are doing agile development because they stand up for their meetings. (I sincerely hope that it is more urban legend than truth.) The reality is that there is more to agile than stand up meetings and there is more to stand up meetings than simply standing. Let’s look at some of the key aspects of the stand up meeting and how you can make yours more effective.
At the heart of the stand up meeting is each team member answering three questions:
The focus of these questions is progress. Each team member should be asking himself or herself, “How is my work progressing and is anything preventing me from being successful?” It shouldn’t be about excuses or recriminations. The stand up meeting is meant to be an honest appraisal by the team members of the current status of the project.
If you need Outlook to keep track of your stand up meetings, you’re doing something wrong. Keep them at the same time and same place every day – preferably first thing in the morning and close to where the team works. It gets the whole team off of the right foot and sets the cadence for the day. By keeping the time and place consistent, you don’t lose time “gathering the troops”. If team members need to coordinate on a task, they can arrange it at the beginning of the day. If there are any impediments that need tackling, the team can figure out how to tackle them together without wasting time waiting for the stand up meeting.
Stand up meetings should be short and to-the-point. They should take no more than 5 or 10 minutes. Even a large team of 10 to 12 people can finish a stand up in about 10 minutes if everyone stays focused on the three questions above. The focus is on making sure the entire team is on the same page and heading toward a common goal. If meetings are taking longer, this is usually because team members start trying to solve problems rather than staying focused on reporting their progress. As developers, we love to solve problems and it takes a great deal of discipline to not start offering solutions when someone has a problem or you think of an elegant design for some new feature. Resist this temptation. Chances are that only a handful of people in the room need to be involved in the discussion. Respect their time by saying, “I’ve got an idea about how to solve that problem. Let’s talk about it afterward.” Everyone on the team has the authority to declare that a discussion should be moved to the “parking lot” to keep the team focused and on track. Remember a stand up meeting should be 5 to 10 minutes maximum.
If a team member reports day after day that he/she has “no impediments”, that’s usually a good sign that there is a problem. Usually this goes hand-in-hand with missing commitments. It is virtually unheard of for a project to go completely smoothly for all the developers all the time and a few issues crop up every week across the team. Often team members feel self-conscious about asking for help or feel that they will be judged for complaining. The stand up meeting is about honest communication within the team. The point is to solve problems, not lay blame. If you are the project manager, team lead, or scrum master, talk to the individual afterward to see if there are any problems and encourage them to share with the group. This is a great opportunity to lead by example. Next time you hit a problem, discuss it at the stand up meeting and look to the team to help solve it. Show that the team is a supportive environment for everyone to excel.
Stand up meetings are for the whole team, not just the developers. Agile encourages cross-functional teams and everyone involved in the project should be participating in the stand up meetings – developers, project managers, technical writers, QA, … Successful projects are those where the whole team takes responsibility for successful delivery. If a task needs doing, the team figures out how to get that task done regardless of official roles. For example, if the technical writer is behind on end user documentation because he was sick last week, the lead developer can step in and lend a hand. It shouldn’t be “beneath her” to do documentation work. Documentation is part of the deliverable, just as is testing, coding, coordinating with beta testers, and more. Sometimes multiple team members will need to juggle tasks around so that team members with the right skillset can tackle a particular problem. If you’re the project manager, team lead, and/or scrum master, remember to let the team figure out the solution (possibly with some gentle nudging) rather than you dictating it. The team will feel more ownership and responsibility for delivering on their commitments if they own the solution.
Team members should be reporting their progress to the team and not the project manager. Stand ups work best when everyone stands in a circle. This encourages reporting to the whole team and make it easier to remember whose turn it is. The stand up meeting is about keeping the team synchronized, focused, and collaborating. It is not for updating a Gantt chart or explaining to your boss why the feature wasn’t completed on time. It is a forum for discussing progress of the project with the entire team and solving problems as a team. Team members should be making commitments to the other team members, not the project manager. It’s more important that the team meet its project deliverables than individual team members hit individual goals. In making the project successful, individual team members are also successful.
Stand up meetings are about more than just standing. They are about encouraging regular communication and collaboration between team members. They help to synchronize a team’s daily activities and facilitate just-in-time problem solving – removing impediments and keeping team members productive. They are one effective tool in our agile arsenal for delivering successful projects.
About the Author
James Kovacs is an independent architect, developer, trainer, and jack-of-all-trades specializing in agile development using the .NET Framework. He is passionate about helping developers create flexible software using test-driven development (TDD), unit testing, object-relational mapping, dependency injection, refactoring, continuous integration, and related techniques.
If you liked this blog post you can subscribe to the TeamPulse RSS feed to receive similar articles in the future.