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
– Lead Time
– Optimize size of batches

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

(5) Scrum
Do it without ScrumButs

Good Question!, Scrum

Scrum of Scrum introduced. Yes!

It’s great to witness how a company changes from somewhat “old school-ish” to something agile-like: Last week we finally started with a Scrum of Scrum and it turns out to be working pretty well only after a few days.

Actually most of our teams have been working with some kind of agile process for some time now: some are doing Scrum, some Scrumban, most are doing Kanban (although predominantely it’s more a visualized work-flow than “real” Kanban). All of them were having a Daily Stand-Up (or Daily Scrum) right from the beginning: some were having theirs in the morning, others before lunch and others after lunch.

I visited several Daily Stand-Up every day and experienced what happens to issues or tasks depending on other teams. Either a team member was planning to talk to the other team (and most often forgot about it right after the meeting: Damn short term memory…) or the issue was bounced via a project manager like myself (who most often missed the crucial part. Sorry…) or the team just simply complained about the fact that it had to wait for another team (but was not doing anything against it). In the end the tasks normally moved to the “pending” column and stayed there for much too long.

Funny enough we actually were doing a kind of Scrum od Scrum since about a year: It was the earliest meeting of the day with all Tech Leads dealing with only one question: Are you about to put something in another team’s way today? It is only natural that the info that was given in this meeting was not up to date anymore (as the last Daily Stand-Up of the teams were at least over 16 hours away).

Introducing a Scrum of Scrum does not only optimze communication but also enables fast and direct communication. We now have a synchronisation of all teams within 30 minutes: First all Daily Stand-Ups of the teams, then the Scrum of Scrum meeting.

All dependencies or impediments between teams are solved or at least communicated within 30 minutes. There is no failing because of short term memory, project manager etc. (see above).

Must read: Advice on Conducting the Scrum of Scrums Meeting from Mike Cohn

BTW: Our UXD are having a UX Scrum of Scrum at the same time. It seems to be working fine. We are still working to get our Product Owner to have their Product Owner Daily Scrum…

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