+43-676-330-4803ContactImprint en de

Blog

Achieving continuous improvement through Kanban

I am often asked, “how do you create the right motivation for real organizational change?” Just because you’re using a kanban system does not automatically ensure your company will see all the success it is looking for or that you can make the improvements you seek in productivity. What is the missing ingredient to vast improvements in the fastest manner?

One of the leading success principles begins with creating a culture of continuous improvement. This goes way beyond the constraints of problem solving and ventures into a completely new mindset of permanently solving problems by improving your systems continuously.

With this mindset, there is no longer a beginning and an ending, but rather an evolution and progression of new solutions for new problems and the process continues… forever. However, this change does not come by adding sticky notes to a board. It is a literal shift in thinking that allows more significant system improvements.

But how do we start a culture of continuous improvement? That’s probably the biggest mistake one can do to think “we only have to roll-out our genuine change plan and then we have a culture of continuous improvement in place.” I guarantee: you will fail! Culture is broad, culture is deep. Culture is “how we do it here” and culture is “how we always did it here.” There’s no way that your change plan will change a firmly established culture. The point is your cultural change already starts with the change process! The Kanban Method supports exactly this idea, which I also discussed in the article “Signposts towards a culture of continuous improvement.”

Form a Kanban Change Team

If you’re starting with more than a guerrilla Kanban initiative – let’s say at least Flight Level 2 and 30+ internal and external stakeholders – you’ll have to do a little bit of homework. One of the fastest and most effective ways to start is to form a Kanban change team. By building a team, it allows an entire group of people to be responsible for the change. Furthermore, we all know that…

  • Groups make better decisions than individuals. We know from experience that the power of groups is far more effective than the single minded purpose of one individual to make good change decisions.
  • A team protects an organization from a single point of failure. As an example, what if you had a single person designated as the change agent and she decided to leave your organization? By using a team, you never have to succumb to the limits presented by one person’s issues or concerns.
  • Dividing up the work between team members will lead to increased productivity. 
  • etc.
Building the dynamics of such a diverse team has the potential to affect change more significantly because everyone must come together for this single purpose, yet with differing views and perspectives. How can you use this team to develop its collective power for optimal performance?

Begin by building a diverse change team. Try to win over people from different hierarchies as well as various functions within the organization to be part of the change team. For example, choosing some business individuals along with development people interspersed with project managers and team leaders. The contrasts between functions and hierarchies provide an opportunity to come to joint decision-making that is far superior to stewing in your own juice.

Improve the way you change

In a culture of continuous improvement, an important goal is to improve the way you make improvements. In other words, improve the way you change. A key to making this happen is by conducting a retrospective of past changes.
How can you really improve the future without clearly understanding the past? A retrospective answers two very important questions:
  1. What went well last time?
  2. What should we improve this time?
Since the Kanban change team has various levels of experience, expertise and different perspectives, these answers can guide the way for more effective communication and discussion towards problem solving. 
Creating an environment of collaboration keeps everyone interested and engaged in the outcome as well as the process. This is also true for change processes! Of course, you still need more than a change team and a retrospective if you want to achieve continuous improvement. The good news is there are three more articles in the queue where I’ll elaborate more about this topic… 😉

Kanban im Praxiseinsatz

Eric-Jan Kaak, CIO bei Blizzard Sport, erzählt im Rahmen des diesjährigen CIO-Summits über seine Erfolge mit Kanban in der IT. Und die können sich sehen lassen: “Mittlerweile sprießen die Kanban-Boards wie Schwammerl aus dem Boden” und Kanban macht auch vor IT-Fremden Abteilunge nicht Halt, meint der CIO des Jahres 2013 im Kurzinterview mit Klaus Leopold. Die gesamte Geschichte zu Kanban bei Blizzard Sport gibt es auch als Case Study zum Download.

Hier gibt’s das Interview zum ansehen:

Kanban und Visual Management

Was ist Kanban? Was ist Visual Management? Wen das interessiert, sollte sich mal das folgende ca. 30 minütige Video von Klaus Leopold ansehen, indem genau diese beide Fragen einführend beantwortet werden. Das Wort Kanban ist ja sehr bekannt, die meisten bringen es jedoch mit Produktionsabläufen in Verbindung und nicht mit Wissensarbeit. Kanban gibt es auch für die Wissensarbeit – Lean Kanban – das darf man aber keinesfalls mit dem Produktions-Kanban gleich setzen. Produktion ist etwas völlig anderes als Wissensarbeit!

Was sich jedoch beide Kanban-Varianten teilen, ist der Fokus auf den Kundenwert. Wie man die Wertgenerierung in Kanban-Systemen optimiert, erkärt Klaus anhand von einem einfachen Beispiel in diesem Video. Reinschauen…

 

The Pre-queue: See what’s after next

The idea of the pre-queue came about three years ago in a system design workshop with a Swiss financial services company as we were contemplating the input queue and its dimensions. We thought a weekly queue replenishment would be good and set the length of the queue to 8 as the staff assumed that this was the maximum number of tickets they could close in a week. After trying out a short simulation of how the kanban system would behave in real-life operation, there were mixed feelings about the input queue. “Surely you don’t believe for one moment that our stakeholders can decide which are the next eight items we should process,” one of the heads of department said. An experienced developer continued with the argument: “Not only that they have to agree on the next 8 work items – they are not allowed to change their minds. As soon as something lands in the input queue it cannot be removed. That sounds like science fiction in our current way of working.”

A testing assistant spoke up and countered: “Yesterday we were still speaking about what we were dissatisfied with,” she says going to a list of improvement wishes and points to a specific card.” And in second place in our pain points we can read here ‘We want to know what is to be done next.‘ We get this information from the input queue. If we take a look at number 5 on our improvement wishes, I read ‘We want our priorities to stop changing constantly’. We can address this with a controlled input queue. As soon as a task is hung up, we do it.” Everyone nodded in agreement but they did not seem really convinced that the stakeholders would agree to this change.

The analysts’ perspective

We decided spontaneously to ask two of the stakeholders – business analysts – to join the workshop and to discuss the topic with them. That worked really well, because we then understood better what their wishes were. “Above all, we must be able to react flexibly. It’s just the way things are the time and new opportunities come up and we want to be able to respond to these,” one of the business analysts said. A recurrent pattern in system design: One wants to achieve maximum room for maneuver and the others want to know exactly what is to be done next. Opportunities can also be addressed with classes of service, which also was suggested by some people. In this particular situation it was, however, a matter of ensuring that the stakeholders did not want to state categorically the standard work they required one week in advance.
The other business analyst continued to argue. “Another important point is that we want to see what will be completed by you in the coming two to three months. If you want this thing-a-me-jig queue, then we must set the limit to at least 64 – which matches your calculations for two months. But as already mentioned before, we must be able to permanently change the sequence, otherwise you are cementing in the agility we require”. And this is where the A-word fell: agility. I did not want to open this big door once again and bit my lip. A discussion between agility vs. chaos is the last thing we needed. 

Large and small at the same time

In my role as moderator I tried to sum up the discussion: “I have heard that the main issue is that priorities keep changing and that you want to know what work you can expect in the coming period. We can achieve this through a regulated flow to the kanban system – the input queue and queue replenishment. From the business analysts I heard that for you it is important what can be achieved within a large time window. But you want to maintain flexibility so that the sequence of tasks may change.” Fine, at least we have consensus on the issue. 
My brain was ticking like mad: More flexibility or agility is achieved through a shorter input queue and more frequent replenishment. We could reduce the input queue to four and replenish it twice a week. That would give us more flexibility but we have reduced predictability from the desired two to three months to half a week.  Simultaneous large and small input queues cannot be created. So the solution does not lie with the input queue. I made the following suggestion: “What would you think if we built a pre-queue in front of the input queue where the stakeholders could change the sequence? This queue could be large so that you have the necessary predictability. 64,  for example, corresponding to two months. At the same time we reduce the input queue to 4 and it is replenished twice a week giving you greater flexibility.” After some discussion we came to a common understanding of what the benefit of the suggestion could bring and we agreed to simply give it a try. It cannot be stated enough. In Kanban system design pragmatism is what is needed. The initial design looked similar to as follows:

A few weeks later

When I visited the company again a few weeks later, a lot had changed. The pre-queue was reduced to 20, because it turned out very quickly that the business analysts were not able to define 64 work items in advance. The size of the input queue had increased to 9 and it was replenished only once a week. The issue of queue replenishment had caused a lot of interactions among the stakeholders and so the permanent reordering of tasks was reduced significantly. 

What are the benefits of a pre-queue?

What had I learned? A lot! I identified the following main reasons why companies often go for a pre-queue:
  • Look ahead: An instrument to see what may be achieved within a lengthy period of time. 
  • Higher agility: The input queue can be kept small so one can react faster to changing conditions. 
  • Shorter lead times: The input queue can be kept small which leads to reduced lead times for individual work items. 
  • Late commitment: The contents of the pre-queue can change continually, something very valuable for business analysts.