Tuesday, September 15, 2015

Flow Exercise: Building Paper Boats

After my workshop at LKNA15 in Miami and my session at the Kanban Leadership Retreat in Austria this year, I got tons of questions regarding the boat exercise. Unfortunately, I had to disappoint all inquirer as I don't have any instructions for the exercise. This changed, thanks to my friends Peter Hundermark, Joanne Perold, Amy Bridge, and Mike Freislich.

Peter video taped the boat exercise during one of my classes in South Africa. Then they approached all participants and asked for permission to publish it. And the result is now a video of the boat exercise, featuring Austin, Cecilia, Christina, Henk, James, Joanne, Karen, Marietjie, Mike, and Olga. Camera, sound and technics: Peter. The guy with the hat asking stupid questions is me, Klaus ;-)

Thank you so much guys! I am looking very much forward seeing you in November in the Improving & Scaling Kanban training in Joburg and the Applying Kanban (Foundation) training in Cape Town.

Sunday, January 25, 2015

Practicing Kanban Book Survey

EDIT: Thanks a lot for filling out the survey!

I'm currently working on my second book on Kanban with the working title "Practicing Kanban". It's basically a continuation of the first book "Kanban Change Leadership" (Kanban in der IT in German) which focuses on starting with Kanban. The main idea of Practicing Kanban is that one already started with Kanban and now wants to improve and scale the system.

The first half of the book is almost finished and if I'd follow the original plan, I'd have to write an additional book :-/ And that's exactly where you come into play. I'd really appreciate if you could spend 3 minutes and help me figure out what topics I should focus on.

Thanks a lot for your help!!

Wednesday, December 31, 2014

Lean stakeholders achieving continuous leadership on home trainers without value creation

That sounds like a rather weird title for an article. Hmmm... Well, it pretty much describes 2014's highlights of my blog. As another year is over, I thought it might be a good idea to take a look at my blog statistics. What were the most read articles past year? Here they are:

1. Identifying stakeholders and their dissatisfactions 
This article got the most views in 2014. Maybe it’s because of the picture of beautiful Buffy holding a stake. Stake holder - what a joke… ;-/ Perhaps it was also a bit about the content - I basically explained how to draw a stakeholder map which is actually the groundwork when it comes to addressing dissatisfactions of stakeholders.

2. That’s not what I mean with Lean
This article summarized a lot of my pain I was going through this year. I was an involuntary observer of so called Lean initiatives within different industries. The consultant company’s approach was  pretty much the same every time: shadow staff with a stop watch and squeeze the last drop of efficiency out of human beings. Well, that’s definitely not what I mean with Lean!!

3. Achieving continuous improvement through Kanban
I actually quite like this one because it covers the fundamentals of improvement work: Forget the Highlander principle and change the way you change resp. improve the way you improve.

4. Kanban is like a Home Trainer
That’s my number one! It’s really important for me to get the message across that Kanban or whatever other approach you find useful will fail if you don’t get individuals to actively participate. It sounds so obvious, however, it is not! Unfortunately, people prefer to waste tons of money trying the latest panaceas instead of actively changing their own behavior.

5. Leadership at all levels
This article is about the 4th principle of Kanban: “Encourage leadership at all levels in your organization,” featuring a survey of British first line managers with a rather curious self-perception: 80% of the asked managers believe they are among the top 20% managers. Happy self-reflecting!!

I think one article is missing in this list: Optimize value creation and not teams. From time to time I get the feeling that the whole world decided team improvements are the holy grail of organizational improvement. Yes, it’s easy. And yes, most (Agile) methods target on teams. Nevertheless, the performance of an organization is by no means the sum of its team performances! In my Kanban training classes I often run an experiment which shows that optimizing teams often leads to poorer organizational performance. Although teams are delivering faster, the customer gets stuff later. That’s not intuitive! Nevertheless, that’s correct!

I’m really not good in New Year’s resolutions, however, writing more about agility beyond teams will be mine for 2015! And I think I can accomplish this resolution because “Agility beyond teams” is the subtitle of my new book which is coming out in October 2015.

In this sense, Happy New Year!!

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