Books, Good Question!, Meeting Facilitation, Scrum, Scrumban

Check-In Activity for Agile Retrospectives

Fortunately retrospectives are already a standard at our company now. Not only our developers teams, but also our sales team, our team assistents and as of late also our management (surprisingly, the last.. :)) have regular retrospectives. Because it has become standard to have retrospectives there is also the chance of falling into a dull routine, both for the team members and the facilitator (mostly myself). To counteract this dull routine we try to do different activities. I tried the following Check-In activity in the last weeks:

Esther Derby and Diana Larsen suggest in their book “Agile Retrospectives” as a Check-In activity to ask every participant “In one or two words: What are your hopes or wishes for this retrospective”. No post-its, no explanation, just one or two words. This always works great.

This question inspired me to ask participants an even more general question as a Check-In excercise: “Why are we doing retrospectives anyway?” I do this as a kind of fast brainstorming and jot everything down on a flipchart. It is surprising what the participants are coming up with. I heard everything from “I don’t know.” (Oops!) and “Because you told us to.” (Ooooooops!) to “Kaizen. Continuous Improvement.” (Thx.) and “We don’t want to do mistakes a second time.” (!!!)

It is also a good excercise to remind the participants of the principles of the agile manifest, one of them is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” (Dare to ask if everyone knows and understands the Agile Manifesto… and maybe be surprised.)

And, of course, it is a good excercise to jolt the participants from their retrospective routine.

BTW: I recognized only days ago that Esther Derby and Diana Larsen book “Agile Retrospectives: Making Good Teams Great” is legally available also as eBook! Buy it!

Agile Coaching, Books, Kanban, Scrum, Scrumban

Soft Agile Transition: Slowly from nowhere to Scrum

Lean Thinking is what I’m trying to learn and adopt at the moment.
What a perfect coincidence that I stumbled over Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum from Craig Larman and Bas Vodde. On page 54 they describe Kaizen, one of the crucial Lean Principles, as a plausible “inspect & adapt”:

  1. choose and practice techniques the team and/or product group has agreed to try, until they are well understood
  2. experiment until you find a better way
  3. repeat forever

When I try to find this Kaizen practice in my work of the last years, it fits to what I call the “soft agile transition from nowhere to Scrum.” 😉
Here is the formula:
(0) Nothing > (1) Daily communication > (2) Visual Workflow > (3) Kanban > (4) Scrumban > (5) Scrum

When we started working with agile techniques we had a divergent mindset in our product teams. Only one team was ready and willing to start with Scrum straight away. Other teams were reluctant to try anything agile and stayed with “Nothing” or were led by project management.

By now all our teams are somewhere in the “soft agile transition from nowhere to Scrum” and I’m happy that all of them have passed step “(1) Daily communication” already.

The above described Kaizen was my fundamental line of action to move step by step from (0) to (5).

What are your experiences with introducing agile techniques to your company?

from nowhere to scrum via kanban and scrumban

Characteristics of the “soft agile transition from nowhere to Scrum”

(0) Nothing
– Black Box
– Led by Project Management

(1) Daily communication
– Daily Scrum

(2) Visual Workflow
– Daily Scrum
– Team board
– Regular Retrospectives

(3) Kanban
– Daily Scrum
– Team board
– Regular Retrospectives
– WIP
– Lead Time
– Optimize size of batches

(4) Scrumban
– Daily Scrum
– Team board
– Regular Retrospectives
– WIP
– Lead Time
– Optimize size of batches
– Agile Estimation
– Regular Review Meetings
– Release Plan via Lead Time

(5) Scrum
Do it without ScrumButs

Kanban, Scrumban

Visualizing Kanban Lead Time

Measuring the lead time is one of the three core means of Kanban (next to Workflow visualization and WIP limitation).  But whereas Workflow visualization and WIP limitation are easy to understand for the team, I experienced that nobody really cares about what to do with Measuring the Lead Time. This week I tried a different approach visualizing the Lead Time and got instant feedback from the team. 

One of our team is working with a two tier Kanban with an additional fast lane for immediate support tickets (similar to a bug line).
It looks like this:

kanban team board

We measure the lead time for the orange tasks as well for the blue tickets; Lead time clock starts from the moment the tasks/tickets are moved to In Progress and stops when they are moved to Done (blue tickets) / Done-Done (orange tasks).
We are not starting the clock when the ticket or task has been created (as described in Stefan Roocks Post), although this seems very reasonable especially for requirements from other teams.
Why measuring the lead time?
In theory, the goal is to make the lead time as small and predictable as possible by optimizing the process.

In reality, nobody here really seems to be interested in the lead time, even though I’m sending out a report every 4 weeks that is also printed out and pinned to the team’s board. It shows an overview of all finished tasks/tickets visualized in some charts. Most probably my report doesn’t make sense to them.

As a consequence I tried a rebrush of the report this week.

It now starts with a chart like this:

visualizing lead time in kanbanI got fast and positive feedback from the team: What does the lead time say exactly? … Interesting number! It’s good that we have a number like this! … Now I understand why all tasks should have about the same size and why we have to break down the tasks into smaller batches …

It seems as if it only needed a (simple) visualization of the lead time to get the team’s attention. Now that I have the team’s attention we can start to make the lead time as small and predictable as possible.

BTW: A much better agile coach than I am suggested to use the median of the lead time and not the average. This defintely makes sense!

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?]