Saturday, April 11, 2009

Three ways to run a stand up meeting

Stand up meetings - those short meeting that a team holds every day to update each other. Also called daily meetings, Scrum meetings and probably some other things. The basic format is well known: three questions -
• What have you achieved since we last met?
• What are you working on next?
• Do you have any blocks or impediments?

Yet despite this simple sounding format there is still a lot of subtle detail and variation possible.

Take the questions for example:
• “since we last met” as opposed to “yesterday”: if the meeting happens every day there may be little difference. But there are weekends, people have holidays and occasionally meetings are skipped
• “what have you achieved” as opposed to “what are you working on”: this makes the questions results oriented and many people find it hard to answer because while they have worked on stuff, there is nothing they can yet say they have “achieved”. (I don’t usually enforce this distinction until the team and the developers are experienced in answering the question and actually delivering stuff. To enforce it early can make people negative as everyone reports “nothing”.)
• “blocks or impediments”: blocks might limit discussion to just those things that had stopped work, including impediments means we ask about things which are slowing work down

Still asking the same three questions every day can be boring and sometimes you want to vary the questions as long as you stick to the same key elements I don’t mind.

What is less well know is that there are - at least - three different ways of running the meeting to ask the questions.

For years I asked the three questions in three rounds. With everyone circled around the whiteboard (or if you prefer Kanban board or information radiator or just task board) I would ask the first person “What have you achieved?”, then the second person, then the third person and so on.

Once I completed that round I would start over a second time with “What are you working on today?”. Again, first person, second person, etc..

And then another round of “Any blocks to report?”

One modification was to ask the third question as an open question to the whole group at once. That can speed things up a little although it might lead to one person’s block or impediment monopolising discussion.

The second way to ask the questions - and the one I think most teams use - is a single round asking all three questions at once. So the first developer reports achievements, current work and impediments in one monologue, then the next developer and so on.

I’ve recently started to favour this format simply because it is a little faster so easier to keep a meeting short. But, this week I realised it might be a false economy.

I did some Scrum training for a team in Switzerland and stayed on to do a little coaching. One of the problems the Scrum Master had identified was failure to identify impediments. I stood in their Scrum meeting and heard each monologue, within the monologue people talked about impediments but did not explicityly identify them as such. They were “hidden”.

Splitting the three questions up into three rounds encouraged team members to categorise what they are saying into Achievements, Work and Impediments. It is very clear what is Achieved, what is In Progress and what is slowing them down.

The third way of running a to do it from the team board. Rather than ask each team member in turn you point to a task card on the board and say: “Who’s working on this task? - what’s happening here?” If the task is in the done column it is (obviously) an achievement (only point to done cards that become done since the last meeting.) If the task is in the “In Progress” column then its work that is ongoing and deserves discussion.

After the card have been discussed there are two questions to ask:
• “Anyone not reported?” - which may be the case if two people are working on the same card, in which case they just say “Same as <who ever>”. If anyone has much to say at this point then maybe there should be another card on the board. Why is a team member working on something not agreed?
• “Blockers or impediments?” - which needs saying collectively.

This format works well when the whole team is split into several sub-teams who work together or when some people are remote, in which case someone locally can report for them.

I’d never thought of this approach as anything special until few weeks ago. I read something by David Anderson and he said that his Kanban teams had taken this approach. David went on to say that this format allows for bigger teams because one person can report on a group effort. This formay also deals with remote people more easily.

Finally, there is a common problem I see with team reports: lack of focus.

The cause is usually the lack of a board showing the task (the team board, the Kanban board, the information radiator - I’m repeating myself). Without a board with the task cards on it the team lacks a focus point. When someone can point to a card (i.e. piece of work) and say “I’m doing this” it is physical. Without it the team members end up saying something like “I’m working on that feature which does blah blah blah and ...” which takes more time and looses focus.

Lets be clear: a board showing current tasks brings focus to team reporting.

My Swiss team really want to use an electronic tool. I’ve suggested they look at getting a big plasm screen on the wall to show the status, I’ll be interested to know how it works out.


  1. Very useful post, thanks. Can you give an example of the "hidden" impediments?

  2. Hi Allan,

    I agree that a physical tool is best to start with. I just wanted to mention though that some of the electronic tools are maturing somewhat. One that I've been using is "Target Process".

    It's pretty easy to use and incorporates test cases, business prioritisation and other whole process tools. There is a learning curve to using it but you can minimise that curve initially by just using it as a task board replacement.

  3. Allan, have you seen Agilefant as a scrum project management tool? It's open source and helps teams plan a sprint in terms of what goals they want to accomplish, then make tasks that exist for a particular goal.
    I find it to be a nice tool for project planning.

  4. Where exactly did you do your scrum training? I'm very interested in it myself.

  5. This was a private course I ran in Zug for a financial company. I teach public courses arranged by DevelopMentor in London, Program Utvikling in Oslo and BA specific courses with BA-Solution (London).

  6. I actually enjoyed reading through this posting.Many thanks.


Note: only a member of this blog may post a comment.