Thursday, November 20, 2014

#LKCE14 - it's over

Troy & me - thanks Peter Hundermark for this picture :-)
The Lean Kanban Central Europe 2014 conference is over and it was again just awesome. I had the pleasure to chair the Learning Track and I think what we got to see was a lot of Lean & Kanban learning:
  • A case study from South Africa by Amjid Ali (aka AJ) and Cliff Hazell
  • A story about Lean production and the influence to knowledge work by the CIO of the year 2013, Eric-Jan Kaak
  • A learning story about your beloved blockers by Troy Magennis and me
  • A learning entropy by Marcin Floryan
  • A Kanban canvas by Karl Scotland

Blocker Clustering

For all those who attended one of my Kanban training classes, the blocker cluster is definitely nothing new. I'm already talking about it for about three years. However, we extended the general idea with a nice heuristic which tells you which cluster you should solve fist. Furthermore, we also presented a simulation approach which calculates the economics behind blocker clusters. Putting a Euro sign in front of a blocker cluster is a very compelling reason to work on it! Here are the slides to our session:

Kanban at Scale

As one of the speakers dropped out, I had the pleasure to do another session. I chose the topic Scaling Kanban because this whole scaling Agile thing seems to be a quite big topic today. In the beginning I tried to address some common misconceptions of agility at scale. In my opinion, the biggest misbelief is that agile teams make an agile organization. I'm always a little bit surprised why the whole world decides to do improvements on team level by "installing" Agile methodologies. Don't be surprised if this does not scale. An organization is more than a container of teams - it's a living social system. The good news is that Kanban is not a team method and thus, Kanban cannot not scale. Kanban is inherent scalable. As you might know, I'm totally not a fan of theoretical statements that sound good but don't have any practical relevance. I worked too long at the University ;-) That's why I decided not to elaborate theoretical thoughts but I rather presented a case study where we applied Kanban on a 200 people program. See the slides here:

In my opinion, #LKCE14 was again an awesome event! Special thanks to Florian Eisenberg & Wolfgang Wiedenroth who really did a great job in organizing the event!! I'm very much looking forward to #LKCE15!

Tuesday, September 16, 2014

Scaling Kanban

Scaling Agile is currently a very hot topic indeed. "Unfortunately," in the Kanban world we can't really jump on this topic and paint some beautiful posters with principles and pillars and recipes that explain how Kanban probably can be best scaled. Scalability is an inherent part of Kanban and therefore one cannot not scale Kanban. Scaling in a Kanban context means: Doing more Kanban. This can be done in two directions: in depth and in breadth.

Depth scaling

I understand depth scaling as extending a Kanban system in its implementation depth to improve it. You start initially with shallow Kanban and deepen it successively. This may include the introduction of better risk management, metrics or forecasting, which can provide more detailed information about the workflow. What I do, I do more intensely, more deeply in depth scaling.

Breadth scaling

Breadth scaling means adding upstream and downstream areas to the system. One basically adds more value creation. Let's assume the development department of a company is already working with Kanban. Eventually they come to the conclusion that development and integration are actually closely related and benefits can be gained, if these two steps are better coordinated. The Kanban system is scaled in breath with the step "integrate".
After some time, we now come to the conclusion that more intensive coordination with the business analysts or product owners could make the development much easier in terms of due date performance and faster lead times. So Kanban is once again scaled in breadth with the steps "analyze" and "roll out", as shown in the following figure.
If there were only this one value stream within the company, all the value-adding steps in a Kanban system would now be integrated. If there are multiple value streams, scaling can of course be further thought through and, for example, look like the following figure.
In breadth scaling one extends Kanban via the value stream and finds ways to effectively coordinate the people, departments of teams involved. It is a service-oriented architecture that this procedure creates.

Value creation vs. team optimization

Generally, it is wise to free oneself from the term "team" in Kanban. There may be teams from an internal perspective of the company, but relevant for improvement is the customer's perspective: He is interested in the result. Amazon is a simple example: The customer wants a book. If you now think about how you get the book to the customer, you will not think in teams. Rather, you will orient yourself on the path the book takes from ordering, through warehousing to delivery. In a second step, you consider how you can organize your business in such a way so that this value flow is optimal.

So if it comes to scaling Kanban, the first question is always: How do we improve value creation for the customer? Only in second place comes the question: Whom do we need to do so? 
Please note that I do not say that optimization on a team level is not important! If you're doing a birthday cake and you start by sticking the candles into the eggs, it's probably the wrong sequence. If you start your organizational improvement journey on team level but you don't have any idea about the problems with your value creation chain, chances are very high that you're sticking candles into eggs.
So you see: Scaling in Kanban means nothing more than to do more Kanban. The starting point determines the path. Welcome to the world of evolutionary improvement! Welcome to Kanban land!

Thursday, September 4, 2014

Optimize value creation and not teams

Again and again I am confronted with the problem of having to explain to people that Kanban is not a team-centered method but a flow-based approach. But where is the difference and why is it important to understand the difference?

In flow-based development the focus is not on optimizing the team, i.e. one sees "high performing teams" definitively not as a goal of improvement work, because the danger exists that through this the entire system is sub-optimized. In the flow-based way of thinking, it is a matter of optimizing the value creation chain resp. the workflow and accordingly it is a matter of (more) global optimization. See also the article "Why Kanban Flight Levels" in this regard.

Let's order a couple of books

But how can one imagine that the value chain is optimized and not the individual team achievements? If, for example, you order a few books from your trusted bookseller on the Internet, from the perspective of the bookseller a value for the customer must be created: 
  1. First all necessary books are organized. They are fetched from storage or books not in storage are ordered from the publishing house. 
  2. Then the books are packed into a package.
  3. In the next step, an invoice is created. 
  4. Subsequently the book is ready for delivery and can be handed over to the package service. 
  5. When the customer has paid the invoice, the ordering process is completed for the bookseller.
A greatly simplified representation of these steps as a work flow could look like this:
Organize books --> Pack books --> Issue invoice --> Deliver package --> Wait for payment --> End of story
These steps could just as well be a first draft of columns of a possible Kanban board. What did we do? We freed ourselves from the organizational structure and placed the customer in the focus of our attention. "What do we require in order to generate a value with the customer?" was the central question. The customer wants books - we made it explicit how we are fulfilling this wish. The flow board is complete!

The organizational structure comes later

After we know, how we generate value, we can ask ourselves the question, whom we require for this. Those are probable people who are part of teams, groups, departments or similar organizational units. In the step "organize books" of the example above, possibly an entire department is in charge of the book warehouse. These are colleagues who get books out of the warehouse, who order new books from the publishers when required and pack these neatly. Invoicing and payment tracking is the job of a completely different department - the finance department. This means that in order to generate value for the customer different participants are required from different organizational units in several areas of the value chain. And it is precisely this kind of interaction of those involved that one wishes to optimize using a flow-based approach.

First it must be clarified how the business actually generates value for its customers, and in a second step we take a look at the involved persons/teams/departments/etc. 

If a lot of people are involved in the workflow which is to be optimized and a company cannot imagine "Kanbanizing" the whole workflow, one can use the Flight levels model as an aid to start with less complexity. Nevertheless the fact is: Kanban focuses on value generation and not on the local optimization of teams!

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. If we don't want to let employees go, we could easily start more projects then. 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.