Improvement Theme is a tool in the form of a poster that works as a conveyor belt for continuous improvements once the Retrospective is over.

I’ve been reading a little bit about Toyota Kata and seen great presentations on the concept. In order to make it practical and useful for me I found myself tweaking it and packaging it in a concept I’ve come to call Improvement Theme. I’ve tried this concept a couple of times now and found it to be a good tool to extend improvements beyond the Retrospective and bringing it into the daily work. In this article I describe how to create the poster and how to use it as a tool for continuous improvements.

The Improvement Theme is a poster. I’ve been using magic charts since they are easily moved between the room in which the retrospective is held and the teams wall.

The charter consists of five areas.
1. Name of the Improvement Theme
2. Now/Problem – Description of the current situation
3. Definition of Awesome – How would we like it to be?
4. Next Target Condition – X weeks from now, what has changed?
5. First Steps – 3 slots for three post-its that describe the first (next) actions we will take?

It’s a living document, preferable put up next to the scrum/kanban wall. Once or twice a week the team reviews the theme and agrees upon new actions as they get completed.

When X weeks has passed the team does a review of the theme itself. If they want to continue on the same theme they identify a new “Next target condition”. Otherwise they create a new Improvement Theme poster.

Here follows an extensive description of how I’ve been using the concept as a tool for improvement and a more in-depth description of the different aspects of the poster.

Continue reading

How do you go about converting a development team from Scrum to Kanban? Can we benefit from incremental improvements in projects under high pressure?

Here is a case study of a team who transformed from Scrum to Kanban and managed to save a derailing project. I hope it can inspire others to experiment and improve.

Some of the things I learned:

• Incremental improvement  works, even under high pressure
• Key problems are typically cross functional. The better you are in building a cross functional momentum – the faster you’ll overcome them
• Kanban works as a tool for incremental improvement
• Quality over speed – always more important than the tool

(… and I have a far way to go until I can order a proper cup of tea and a croissant 🙂

Anyway, here’s the link:

Converting a Scrum team to Kanban

Why do we level out? In many agile teams I have met the introduction of Agile methods have made the teams to take a big leap. But then, after a while, they level out. Why so?

Continuous improvement ( "kaizen") is a core process within Kanban and/or Scrum.

But what does it mean?

Here is an A3 I use to explain the concept

Your team is coding along, sprints are passing by, your somewhere around sprint 15.. life is ok..  ..or?

As a famous test leader once said:
"Team are happily completing sprints but nothing gets’s done"

Here are a couple of  things to look out for in your Scrum organization..

For those of you who wonder "why would anybody convert a Scrum team to Kanban" (see earlier blog) – it is important that you understand the true intent. (..yes there is one! 🙂    What expected output do you have from a process framework?

This important "why" question is often left out in the debate. The heated "Scrum vs Kanban" discussion is a good example. Try yourself  "why are you using Scrum"? (or Kanban). At what point would you throw the tool out for not delivering?

It is no wonder debates turns heated if we disagree on where we are heading. But if we instead start with clarifying intent ("why") – then the actual choice of tools becomes less important (more like a boring context summary 🙂

Why then? How do you know that the process tool works for you?

• First (obvious) – it helps you deliver running software.
• Second (less obvious) – it makes you do continuous improvement effectively

If you are getting results from continuous improvement – your tool is right. If it is not happening, it is probably wrong. (check yourself, what improvements have you benefited from lately?)

This was the main reason I chose to implement Kanban in the Scrum teams. It was not because the sprints where not delivering, it was because the improvements didn’t happen.

As you can read in the Crisp blog, some of us have been travelling to Japan to”Find the roots of lean”.
The experiences are many and I will try to write about them in coming blogs but here I will reveal what was the most

important experience for me.

How can anyone say

that they are Lean or agile when they don’t inspect and adapt.

What most companies have in common when they implement process improvement is lack of continuous improvement…..