Tag Archives: kaizen

Improvement Theme – Simple and practical Toyota Kata

Posted on by

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.

read more »

Converting a Scrum team to Kanban

Posted on by

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

West vs. Japan

Posted on by

I went on a study tour to Japan this year to look for insights. We had the honor of visiting companies like Fujitsu, Toyota and a two young, agile software shops. If you have ever visited a assembly floor in Toyota you realize that invention has been happening for years and are very much ongoing. They have never stopped. Why?

One of the answers can be found in the attitude. While we (in west) see improvements as something extraordinary, improvements are in Japan the essence of operations. It is so rooted in the company culture that it has a separate name, Kaizen.

While we succeed in copying improvement activities -retrospectives, quality circles, SPC charts etc, we have much more to learn about adopting the mindset that makes people question and carry through improvements.

As one CEO  remarked:
"The one question I have to answer to at the end of the year is – what have you improved?"

Know your continuous improvement

Posted on by

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 Scrum is running fine, right?

Posted on by

1. You are completing sprints but each sprint backlog is full of failure demand
(Failure.. what? )

Value demand   Failure demand
Demand for service from customers             Demand caused by failure to do something right for the customer
     A demand from where there is no hope of making money
Example    Example
I need..   .. you didn’t..
.. where is my order

A team I worked with was considered doing ok. Team was happy with Scrum. At a closer look 60% of all stories where failure demand and over 19% of all stories returned at a later sprint. The cries from the Product owner of problem keeping commitments turned very real..

2. Sprints are completed but software rarely reach the market, if ever, it is late

The development team completes stories, tests them and move on to next sprint. The result is passed on to a team in charge of integration and acceptance testing. They pass it on to a customer integration team. There is a product owner prioritizing each step. From business side the deliverables are few, random and if ever occuring – late.

The evil side of this is that the problems are unseen by the teams themselves. Each team can rightly point to out they are delivering and indeed at a higher velocity..  Therefore it is not unlikely they will resist when someone arrives pointing out they need to change.  This this is a situation of sub optimizing goals, in my case this was solved by simply aligning the sprint goals of the teams.  

3. Sprints completed, software delivered – a team somewhere else is getting thrashed..

A component team is delivering with high quality, on time,. They are the A team of the IT organization, always delivering on time. Unseen at another department, team B uses their components. But they run at a slower release cycle which makes them constantly readjusting to the frequent releases from the A team.  On top if it all, they get blamed for not delivering "why are you not delivering? We have this top notch process called Scrum.."

In a real case we solved this by aligning the release cycles of the teams.

4. A low but regular percentage of stories committed by the team never gets done

So? – you might argue.."It is in fact Scrum that saves them since it enabling them to work with a clear prioritization…."  Yes a gifted product owner will save you any day. But what is causing this remains hidden.  A broken architecture, unreadable code, coding from incomplete stories, developers untrained in the technology…  it’s all hidden in the sprints.

A team I worked with blew sprint after sprint but did not see this. After all, they continuously met the main business goals. How do you know you can spot this? This requires rich flow transparency (Kanban) or numeric measurements to become visible.

4. Scrum is working, team runs it by the book, quality is good, business is happy.. just that we get no improvements

If we accept status que we are not likely to implement new ideas. And so the continuous improvement process is broken before we even start.

A team I worked with lacked visibility into their results. This made it hard to tell if they were heading in the right direction or not. Once visibility into quality, velocity was put in place up, they immediately questioned the benefit of velocity "this is too linked to customers release cycle, we can’t see our own improvements" (and rightly so!)

Scrum is easy to implement, but hard to interpret. 

Lean teaches situations like these are unacceptable. We cannot accept poor quality, sub optimization or not improving.

My point is:

  • We can improve a well functioning Scrum if we know what we are looking for
  • Lean helps us see areas to improve on
  • Kanban can increase transparency so team can see the Lean things visually
  • Knowing what to look for – is hard. We need to mastering a wide range of techniques well beyond Scrum before we can enjoy the fruits of real continuous improvement

It is not the process, it’s the improvements

Posted on by

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.

A perfect orchestra

Posted on by

The week in Japan has been very intensive and thoughtful.  We have visited about 5-6 Japanese companies, everything from a small software company with 10 employees to Toyota and their software development.

So what is the lesson learned of this trip.

From my impressions there are a lot of differences and similarities between the Japanese and the Swedish culture but what struck me most was the way of thinking towards Kaizen. Every company we visited had Kaizen as their number one priority, from the CEO down to ordinary workers.

Our meeting started with a visit at Fujitsu with their CEO and one of their chief engineering. They were really proud of showing us how they have with help of Kaizen made their productivity increase between 5-6 times from 2001 to 2008.

After that we visited Toyota museum and plant. As soon as you stepped into the museum and the factory you could feel the kaizen all over the place. The factory was so well synchronized that I understood that this has evolved during a long time where Toyota had improved their process to become “the” perfect orchestra.

We also visited some minor software development companies where I again was amazed of the way the companies breathed kaizen. This experience was confirmed in one simple sentence from the former Lexus IS chief engineering Mr. Nobuaki Katayama, with “KAIZEN = DNA”.

Every time I was reminded about Kaizen my thoughts went back to how we work in our companies in Sweden and what if we had kaizen as our most important priority through the whole organization at all time, the question is what we need to do to insert Kaizen in our DNA.

Kaizen (Continuous improvement) should be the first improvement

Posted on by

Since one part of my job is to help companies to improve, I have had the honor to visit many companies. Most of these companies have a good understanding of Lean and Agile and need very little facilitation from my side to take a huge step of improvement and other are much more tough cases. What most of these companies have in common is the lack of culture and facilitation of helping themselves to improve. Somehow the common knowledge is that, improvement is something that will evolve by itself, only a manager can have the right to do improvements or someone from the outside with a lot of experience needs to come in and help us.

The interesting thing is that most of these companies that I visit do not have any process improvement in their process. I have even been introduced to a project called Kaizen (Japanese for "improvement") that did not mention anything about continuous improvement in their process. This was not due to lack of knowledge or unwillingness from the management, they just didn’t think about it. When I mentioned that they have forgotten about continuous improvement in their process they totally agreed with me but somehow they forgot one of the most important ingredients in their new process.  

So when I start to work at a new company I’m pretty open with that “most likely the majority of improvement that I can help them to implement is their own ideas”.  So one of the first changes I usually suggest is a good way of introducing continuous improvement into their new process, a way to empower the employees to come up with new ideas.

By this blog I don’t want to say that you shouldn’t hire an Agile or Lean coach, rather the opposite. But understand the fact that most of the improvement will come from the people in your organization rather than a coach, the coaches are there to help you facilitate the continuous improvement.