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!!
Sunday, January 25, 2015
Wednesday, December 31, 2014
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
|Troy & me - thanks Peter Hundermark for this picture :-)|
- 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 ClusteringFor 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 ScaleAs 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 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 scalingI 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 scalingBreadth 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".
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?
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
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:
- First all necessary books are organized. They are fetched from storage or books not in storage are ordered from the publishing house.
- Then the books are packed into a package.
- In the next step, an invoice is created.
- Subsequently the book is ready for delivery and can be handed over to the package service.
- 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
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.
Millions saved by moving the printerLet'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
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
Making the system work for youAn 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...