Monday, July 28, 2014

That's not what I mean with Lean

I currently notice a significant accumulation of so-called Lean initiatives that are being rolled out on a large scale in companies by major consulting houses. Four of my clients are currently affected at the same time by these Lean waves and I will try to put my observations into words. The examples and figures used are of course fictitious and any similarity to real-life situation is, of course, pure coincidence.

So the Lean initiative - what is this meant to achieve? This is easily explained: Increased efficiency. How can you imagine this? Well, in an initial step it is analyzed where greater efficiency could be created. This is quite simple: A horde of consultants is driven through the company, with the mission of "shadowing" staff with a stopwatch and to find out where time can be saved. The resulting improvement measures are for a person who thinks in systems - shall we say - rather surprising:
  • The printer should be located closer to the staff.
  • Office supplies should be available in the team rooms.
  • It must be determined who may speak to whom and when.
  • The meeting rooms should not be closed off.
  • etc.

Millions saved by moving the printer

Let's take a closer look at printing optimization: Our stopwatch consultants have discovered that the employees take on average 75 seconds to fetch a printout from the printer. On average, each employee goes to the printer twice a day - so that makes 150 seconds per employee per day for spent on fetching copies. With 10,000 employees, that amounts to some 1.5 million seconds or 25,000 minutes or 417 hours every day. In a calculated mixed hourly rate of € 85 per employee, the transaction costs of printing jobs amount to approximately € 35,000 per day or € 175,000 per week or € 9 million per year. That's a lot of money - only for the employees to fetch their printouts from the printer. This has revealed, of course, an immense potential for savings!

So it's clear what needs to be done: The printers have to be better located to reduce the time to fetch the printouts. This can save millions! If the printer would be placed, for example, directly in the team rooms, one could halve the time it takes to pick up a printout. Cut in half! Yes! This means the company saves a pretty sum of 4.5 million Euros per year with this simple step. Amazing!

When you combine a few of these brilliant improvement steps in a so-called Lean initiative you will quite quickly reach a potential savings of 20 million Euros, for example. Not quite - the consulting company would, of course like 5 million of this - after all, you need a lot of manpower to streamline the company's work to such an extent. But you can have this with pleasure! For there is still a saving of 15 million Euro. Fantastic! We love Lean!

But what do we do with the 15 million Euros we have saved? Well, the average staff costs amount to € 100,000 Euros annually per employee - that is, we can dismiss 150 employees and still achieve the same performance. Great! And that works through simply moving the printer around a bit. Money really is practically growing on trees.

Knowledge work and the toilet

Unfortunately, this approach has a tiny flaw: It does not apply to knowledge work! People are not machines. How much real "performance enhancement" does a company achieve when software developers or engineers save 30 seconds per day when fetching something from the printer? I don't mean the absurd sample calculation that gets better the more people you multiply into the calculation.

The supposed savings does not result in 30 seconds of more products being developed that the company can then sell at a profit.

What are already 30 seconds of an 8-hour workday of a marketing specialist or a project manager? A typical day in knowledge work is full of unexpected events, which simply vaporises the ridiculous 30 printer seconds: an unplanned 10-minute phone, help a colleague for 15 minutes, repeatedly unforeseen troubleshooting after an integration test, unforeseen delay because a supplier has not delivered on time, a hypothesis has proven to be wrong and needs reworking, etc.

And then there was the spicy chili con carne from the day before, which caused even unplanned additional work of the digestive system, thereby increasing the daily toilet-time of an employee from the average 5 minutes to 10 minutes on that day. The few seconds saved in efficiency gains getting something from the printer is - with all due respect - shits.

Is there anything more than efficiency?

I have in principle nothing against efficiency gains through waste reduction. However, these are only in rare cases the real problem of companies. My experience says that companies have much bigger problems whose reduction brings an incomparably greater leverage over any ridiculous seconds waste optimization:
  • making blind decisions on the basis of invisible work; keyword visual management
  • installing solutions without understanding the problem; keyword lazy management
  • unlimited work in the system; keyword stop starting, start finishing
  • permanent re-prioritizing of tasks due to unstable work systems; keyword pull instead of push
  • optimization of individual staff utilization over managing work flow; keyword manage work and not workers
  • unclear connection between strategic goals to employees' daily work; keyword fit for purpose

This list is by no means complete and can be extended easily to include more serious problems. If some of these problems are present in a company - and the likelihood is damn high that this is also the case - efficiency programs are of no use at all. Quite the contrary - the situation deteriorates dramatically:
Staff is permanently busy while work is not getting finished, lead times are getting higher and higher while customer satisfaction is decreasing, and throughput (= money earned) is reducing because of induced overhead like permanent re-prioritization and constant status reporting. 
And all this, although on paper one had calculated zillions in savings.

- Stopwatch photo by Tim Reckmann
- Toilet photo by Alex Guerrero

Monday, May 26, 2014

A tailored Kanban system design

One of life’s most revealing philosophies is to embrace the journey rather than the destination. The same is true in the context of pursuing improvement in problem solving for corporations of all sizes. Any company who wishes to learn, grow and improve, never really stops doing so. In their quest for perfection, they simply acknowledge that the most sought after quality is the perspective of staying on a path of continuous improvement. That is where real success lies. It is this constant journey of working to make more progressive changes and getting better at doing so as time lapses where they find their greatest success stories in achievement.

Making the system work for you

An important element in solving problems is to design a tailored kanban system within your organization that works for you. Here is an easy 3 step process that allows any organization to get started.

Step 1: Form a system design team.
You achieve best results if you involve as many people as possible in the system design. However, if let’s say, 200 people are working in your system, you need a quite big room to run your system design workshop. And I also doubt that 200 people working on a system design is very efficient.
A system design team has been proven to work quite well in such situations. The easiest way is to work with delegates from teams that are involved in the final kanban system. That’s actually how I lead most of my Flight Level 3 system design workshops.

Step 2: Design your system.
Remember, you do not design a kanban system for the sake of designing a kanban system. You want to work towards dissatisfactions of your stakeholders. Therefore, it is important that you focus on solving the specific dissatisfactions, which you discovered during your stakeholder interviews (see "Identifying stakeholders and their dissatisfactions").  By narrowing your focus to problem resolution, you are targeting the specific needs and desires of your stakeholders who want to know you can fix the problems they are facing. It is also important to show them you share their interests and concerns.

It is not a time to go deep in solving problems in coming up with process revolutions. It is more important that everyone is truly involved in setting up your future improvement environment aka “the kanban board” and addressing some of dissatisfaction in a first step. And it is really important that the system design team is doing the improvement work on their own because that’s the core when I say "improvement starts with the change process". Don’t walk into the trap and tell people what to do! Help them figure out on their own. The coach is definitely NOT the smartest person in the room when it comes to a system design ;-)

Step 3: Start your system. 
Once your system is designed, it is time to present it to your stakeholders and ask for feedback. If you solicited the advice of stakeholders in the beginning of the process, then this should be easy to gain their support. However, be open to more feedback as the process evolves and you receive more input.
A good system is achieved when it addresses very specific dissatisfactions which have been identified, one after the other, in a sequential or prioritized fashion. Because the journey is never quite complete, you will stay in the continuous improvement loop...

Tuesday, May 13, 2014

And the Brickell goes to...

This year's Lean Kanban North America conference was very special for me. I won the Brickell Key Award "for outstanding achievement and leadership" as the stylish glass block says. Thank you so much to everybody who nominated me and provided references! It's really a very big honour to be selected out of this outstanding list of nominees:
  • Amanda Varella, Rio de Janeiro, Brazil 
  • Bernadette Dario, Ontario, Canada 
  • Christophe Achouiantz, Borlange, Sweden 
  • Håkan Forss, Stockholm, Sweden 
  • Klaus Leopold, Vienna, Austria 
  • Lu Ning, Beijing, China
According to the official announcement,  this year's jury picked Amanda Varella for her work at Petrobas where she started with Kanban already back in 2008 and currently more than 40 teams are using it. And the jury chose me for my work as a speaker, author, consultant and thought leader. I am also very happy that my friend Mike Burrows won the Community Contribution Award for putting a particular emphasis on ethics, values and principles in Kanban land.

Tuesday, April 22, 2014

Identifying stakeholders and their dissatisfactions

With the article "Achieving continuous improvement through Kanban" I kicked-off a series of blog posts to explain my experience of how you might succeed with seeding a culture of continuous improvement in your organization. As you probably know, I am totally no fan of recipes and thus, it might come with no surprise that I won’t present you the best practices and if you only follow them you’ll be successful. Stop dreaming!

However, I do think there is one very important practice, which it’s worth knowing if you are on the way to create a culture of continuous improvement. In fact, this practice is so important it can either propel you forward to great success or become one of your most difficult struggles that keep you from optimal productivity. Identifying stakeholders and getting them to work for you as opposed to against you is one of your potential greatest assets in achieving continuous improvement. But, here’s the big question. How do you get them to work for you?

A good starting point is to find out your stakeholders - visualize them and their relationships. Stakeholders are anyone who has a vested interest in the outcome of your change initiative. Internal stakeholders are those who are directly affected by the initiative – basically everybody who’s working with the kanban system. However, what about those who may be indirectly affected by any changes made to your systems or procedures? These are your external stakeholders who may not be directly involved with your day to day operations or decisions, yet still have a particular interest in the outcome of any decisions you make. 

By identifying both parties and bringing them in to your problem-solution equation can be extremely beneficial to any organization and create a win-win for everyone. 

Create a map of stakeholders

Here is a 5-step process for identifying and targeting key stakeholders on your quest for continuous improvement.

Step 1: Brainstorm your stakeholders.
Step 2
Start making a list of key stakeholders. Remember they can be both internal and external stakeholders. Think of departments like sales, operations, business development, customers, quality assurance, suppliers, works council, etc. 

Step 2: Visualize the influence and power of each stakeholder. 
Now that you have a comprehensive list of stakeholders, use e.g. differently sized cards to show what level of influence to your Kanban initiative each stakeholder has. Make larger cards for a stronger influence and smaller cards to represent a smaller influence. Your cards will now look something like the graphic to the right. 

Step 3: Visualize the buy-in to your Kanban initiative. 
Step 3
You now have an opportunity to visually represent where each of these influencers are with respect to buying in to your initiative. Will they be difficult to reach or convince or very easy? Take a look at the graphic "Step 3" which shows your Kanban change initiative shown as the center of gravity. Place each influencer card in a spatial relationship with how close or how far they are from accepting your change initiative. This will help you see two important things: (1) how powerful each influencer is, (2) how positive each is relative to your change initiative.

Step 4: Visualize the frequency of these relationships.  
Begin drawing lines between stakeholders to show what the real life relationships look like. Use solid lines to  represent good relationships between two stakeholders. A dotted line means a relationship is in place, but perhaps not very strong or the communication may be weak or infrequent. Use two or three parallel lines to show a healthy, strong relationship between two stakeholders. In the end, you get a graphic representation showing strength, power of influence and the nature of each relationship which will bring you closer to identifying key stakeholders. 

Step 5: Visualize the quality of these relationships.  
Step 5
Are these stakeholders friendly? Adversarial? Love-hate relationship? What we are trying to understand is how these groups will relate to the change you will be proposing. This helps the Kanban change team (see "Achieving continuous improvement through Kanban") to fully visualize and assess what they are up against as well as help prioritize whom they should try to target first. To illustrate the nature of each relationship, try drawing e.g. a heart to represent a strong accepting relationship or a positive alliance. Draw a thunderbolt for an adversarial or difficult relationship. Your graphical representation may look similar to the graphic shown. 

You see that’s no rocket science. However, it’s a perfect tool to define a strategy of how to win over your stakeholders for you Kanban change initiative. And remember that a change team developed this stakeholder map – so the chances are quite high that it’s pretty close to reality.

Uncover dissatisfactions

Once you have identified key stakeholders, you are ready to approach them to bring them to your change initiative. A good way is to address some of their dissatisfactions with the kanban system. However, in order to do so, you'll have to figure out what your stakeholders' dissatisfactions are. There are different ways to do so: mind reading or gazing at the crystal ball are not very reliable methods. I have a lot of success using the world famous A.S.K. method - go to the people and ask! Try it! It really works... ;-)

You can conduct one on one interviews or group interviews depending on the method that works best for you. Your stakeholder map will help you figure out the best way of how to approach your stakeholders. When asking about dissatisfactions, be sure to ask for a ranked list of dissatisfactions so you understand their order of priorities. Make sure your stakeholder understand that your effort is not about introducing Kanban. No! Nobody needs Kanban on its own. Kanban is a means to its end. The real goal is to improve work - solve dissatisfactions of your stakeholders.

One of the greatest advantages of going through this process is that you are no longer working on assumptions, but the reality of who holds the most power, where each relationship is in its present state and where to go on a step by step basis to get closer to the solutions to your problems. This removes the guesswork and allows you the most direct, honest route for the fastest resolution. 

Thursday, April 10, 2014

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... ;-)

Tuesday, March 25, 2014

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.

Monday, March 17, 2014

Brickell Key Award Nomination

I feel very honored to be nominated for this year's Brickell Key Award. The award is named after the Brickell Key island near Miami where our community first gathered for the Lean and Kanban Conference in May 2009. According to the organizers, the award highlights excellence in our community honoring two people who have shown outstanding achievement, leadership and contribution to our community. Wow! Thanks! :-)

Now it's up to the committee to pick two out of six nominees - and you can help them choose! I'd highly appreciate if you would write a short reference about my work and me. You attended one of my training classes and you found it useful? Great! Let the jury know! You're using the Kanban Flight Levels model to communicate the power of Kanban? You found my book useful or you liked one of the community events I organized? Please let the committee know :-)

The award ceremony will be held on May 8, 2014 at the Lean Kanban North America conference in San Francisco and I'm already freaking exited :-)