Scrum, Scrumban

A Burndown Chart is much more than Traffic Lights

This post is a wonderful example of me being a project manager struggling to become an agile coach:
As a project manager I loved to show the status of a project via traffic lights (see image below). I always pinned those traffic lights on the team board and every developer could move his or her name sign anytime on red, yellow or green, depending on the developer’s opinion.

traffic lights milestone project

Traffic lights are easy to understand for everyone (also for externals like management or other teams). Additionally I could quickly react and adjust the plan with the developers if most name signs were on “yellow” or “red”.

At the moment I work with a small Scrum team (2 developers and 1 UX), our Sprints are 3 weeks. So we actually require a Burndown Chart to show the teams progress.

At the beginning I suggested to use traffic lights instead of a Burndown Chart to show the team’s progress. Why?

As the team is small, we do not have a lot of stories for the Sprint; only 2 to 3 per Sprint. I felt it was not very motivating to have a burndown chart that changes only 2 or 3 times during the Sprint (see below). Furthermore the developers used Scrum for the first time in a project and were rather skeptical about giving a commitment. (Due to bad experiences about effort in man-days commitments in the past.)

burndown chart scrumNow there are no more traffic lights on the board. Why?

A much better agile coach than I am worked intensively with the team in the last week. He cleaned up. 😉 When I asked him where the traffic lights were, he answered: “The team commits on the Sprint goal  and not on traffic lights.”

Of course, he is right. Although he understood my idea of a “Burndown Chart Substitute”, traffic lights only have a “binary” explanatory power: “Yes” – “No” (and maybe “Maybe”).

A Burndown Chart is much more than traffic lights.
It has the  “binary” explanatory power of the traffic lights.
PLUS: It shows the progress of the team (no matter if there are a lot or just some stories), it visualizes the time (remaining & past days of the sprint) and it shows the amount of work still to be done (based on facts not opinion!).

The much better agile coach than I am missed to replace the traffic lights with a burndown chart. This will be my first ToDo on Monday. 🙂

Books, Kanban, Scrum, Scrumban

3 Retrospectives in 2 Days

Last week I had retrospectives with three different agile teams within 2 days. I love retrospectives and a retrospective meeting is one of the first agile things I try to establish when I start working with a team. Every team needs to get used to the advantages of retrospectives though…

The agenda for retrospectives always includes the following 4 questions:

  • What went well since our last retrospective?
  • How can we do better, how can we improve our process?
  • Is there anything we CAN’T change by ourselves?
  • What in detail will we change until the next retrospective?

Besides those questions I experienced that a warm-up at the beginning is more than helpful: Draw a timeline of the past sprint (or period of time concerned in the retrospective) on a flipchart. Ask the team “What has happened in the last weeks?” and then let the team put sticky notes with their answers on that timeline.

The warm-up helps everyone to get their minds focused and it shows that everyone in the team can have a different view of the past couple of weeks.
In addition:
For teams that work with a Kanban system it is sometimes difficult to see what has been accomplished in the last weeks. This warm-up shows them that a lot of work has been finished.

Maybe you like to try out 2 things I experienced as useful:

  1. Have a short break after you have answered the first question (“What went well since our last retrospective?”): It could be a smoking break or as simple as just opening the windows to let in some fresh air for some minutes. The team (normally) has just mentioned a lot of positive things, so try to keep the good vibes for some moments! 😉
  2. Feel comfortable with the silence while the team is writing their sticky notes. Don’t hustle the team when the team seemingly is not writing anything more. Sometimes it only takes a couple of seconds and someone starts writing again.

Read “Agile Retrospectives: Making Good Teams Great” from Esther Derby and Diana Larsen for different tools and recipes in retrospective meetings.

In the next weeks I will try to write a post about how to get the results of retrospectives done.
[Update Sept. 07, 2011: Done. 😉 Please read How to Deal with Results from an Agile Retrospective?]