Kanban is (just) a model

In the past weeks, my last active Kanban event way back in the past, I had some unfortunate discussions about Kanban.


The conversations that went bad, have all been trigged by others, not really doing Kanban asking me question on my experiences w/ Kanban and how I am (or was) doing or seeing things. I simply answered. My conversation partners in at least two cases left the conversation annoyed. I wondered what happened.


What I think what happened is that I was so sure and certain about my statements that this was indeed really annoying. What helped me in many cases and conversations, turned against me in the newer cases. The level of certainty I expressed in the conversations was disturbing, although honest and true, being based on empirical analysis of what I have been doing in the last years and several environments. Empirical analysis being a core part of Kanban.


What changed was, that in the past I was mainly questioned by colleagues who saw the effect of my work and who where happy of me sharing the knowledge. In the newer cases I was asked by people who didn't observe the effects of my work. To them my certainty must have come across as that of an ignorant super jerk. In fact one guy said I wouldn't know his organization and thus I would be coming with ready made recipes. I know the danger - but in fact I thought he asked me what I do and so I answered. I didn't even consider his environment - that would've been the next discussion. Again, I simply answered his questions on how I was doing things. Anyways - this is not about communication. During thinking about this disturbing effect I came to the following conclusion.


Whatever Kanban may be: a method, a tool, a process, a process to improve processes … whatever. To me it mainly is THE model to describe Product Development in an intuitive way. Whatever I am doing I somehow describe it in the language of Kanban. And until now it never failed to me to describe and explain effects I have observed. This really helps me to have a good model in my head to discuss and think over all the options that I have.


The model has about a million layers, starting with the visualization, the WiP limits, the core practices, the principles, the values, the culture, the queue model built in, flow ... Millions. All of them together have a certain effect and none of the effects can be reduced or deduced to a single measure we took at work. This also explains why the whole thing is so fragile ... As lean (and agile?) in general are.


So Kanban is a whole set of layers working together. As a conscious or unconscious effort (deep vs. shallow) doesn't matter that too much to me. Lots of the work being done by most of us currently is digging deeper into this model, deepening and trying to detangle it at the same time. Let's keep on.


THE model also now explains to me why my discussions ended in a bad way (besides me possibly being a jerk). Without explaining to the outsider or the uninitiated that we are always talking about the interplay of a multitude of layers, people must think we talk about a mere, lame white wall with stickies and numbers, which couldn't have those effects. And they couldn't. WE'd indeed be jerks if we claimed THAT. But we aren't - just the white wall with stickies and some stupid numbers is not what we are talking about. Since years. But it doesn't seem to get across easily.


But it also something we need to remember: We are not talking about Kanban. Even not capital K Kanban. We talk about all the positive effects we achieve and map these to Kanban. This can be or at least sound annoying. The name may be a problem - it suggests that we talk about the whiteboard with the ... But we don't. And we know, we take it for granted. But they don't know. And we have to explain. (If they don't get mad too soon ;)


In the end, Kanban - yes - is just a model. Possibly the best we currently have and it is still evolving pretty fast. Once it stops evolving it will be done and dead and ripe for replacement for the next great thing. But I don't see that coming soon. Too much is still happening, too much still needs to be explained, too many discussion to be held - possibly me being a jerk ;)


To end, after writing this, it occurred to me that I am saying similar things as David in his last blog entry on Tolerance - 'Are we doing Kanban or not?'. Just from quite different a vanishing point. Read it, it explains a lot.

Projects as a bad proxy and container for value in the product context

My buddy Arne - of freshly earned and well deserved Brickell Key Award fame - and me are just back since a couple of days from the LSSC12 conference in Boston, MA.


I was impressed by the broadness of topics addressed at the conference. During the next days and weeks I will digest them for myself, and hopefull in parts here on the blog as well.


Until then, I'd like to point out a topic that Arne and me were presenting at the LSSC12 ourselves, and which keeps growing in me even after writing it up in the proceedings of the LSSC12.

During our play onstage at the LSSC12

Actually there are two topics: 

• The structure of how to improve flow across your PD organization in a model of three main queue types: a) output queue (product release) 
• product development process queues (standard), and c) the input queue (product discovery and portfolio)

The way we see it now is that in most organizations, once you start with Kanban, it becomes obvious that the output queue is tha single largest queue. Thus is should be the first one that gets handled. The good part is that this is actually easy. Out of the easy problems it is admittedly a more comlicated easy problem but in no case really hard. It is, otoh, hard enough for Kent Beck to come up with one of his very great talks, called 'Software G-Forces'. In this he very lucently describes the challenges and forces that each step toward towards more frequent releases introduces to your PD process.


This leads to the effect that it makes sense, to start the standard Kanban work, in which by slooowly lowering the WIP limits in a sensible way across the development queues (in any model, e.g. Analysis, development, QA, Integrate, Rollout, Live to Site). This will have great stabilizing and quality effects on the out put of the development system. 

Effect of limiting WIP over time on lead time, standard deviation -> enhanced predictability  

As a third queue, now the input queue gets into the focus. This is basically any portfolio or even the product discovery process of your company.


Coming back to the project vs. product development topic, we came to the conclusion that a project is by definition simply a timebox around a purposeful action of a team. The purpose is in general simply to add value to your product. The whole concept of a project and then project management was born in industries moving tangible goods. Basically, project management is derived from the scientific approach towards labor as invented and described by Frederick Taylor. This was a good thing a the time in the context. Even, Taylors motivation was very humane and philantropic. Anyway, to transpose and adopt the methods into the area of knowledge work and intangible goods, such as software, introduces an unfortunate idea. The idea behind project management is that by planning, the outcome of an activity is repeatable and defined. This is achieved by making detailed plans for repeatable actions, laying out pre-defined dependencies between different activieties, resolving thos in the best manner beforehand, coming up with predefined risk mitigation strategies etc. The focus is to gain control over a large batch size of predefined actions, mainly bacause the transaction cost is so high that you don't wat to get 'out of control' in the slightest.


This approach brings with it certain constraints on a ver serious planning, which increases the overhead on the one hand. Much worse in our opinion is that it rediuces options over the course of the project - learning options and also options of acting. Options will always increase uncertainty and uncertainty is the poiseon of the planability of a project. Option, on the other hand, are wbat you want to constantly improve the value of the product. This is where Kanban comes into play on the portfolio or product discovery level.


In our experience, handling the portfolio on a simple Kanban board, makes your organization optimze against flow of value on the product, rather than on plannable projects - which are a mere bad proxy for value generated. The notion of a project tends to get resolved in smaller and smaller batches until only EPICS or features are left and real flow of value sets in. Also, as the features and thus the batch size and then the lead time decrease, feedback time - real feedback from the market - will also drastically get faster. And this is where we want to be: We want fast feedback on value generated from the real market. 

A standard portfolio Kanban board

There may be many ways to get there, but Portfolio Kanban is a very naturally evolving way to get there without to many steering involved. If you are interested, download and read our in depth analysis in the proceedings of the LSSC12.


In summary, what we found out is that taking care of

•  the output and development queues leads to organizations doing the wrong thing (projects) better (better lead time and overall quality i the system, enhanced predictability), 

but the real deal is 

• handling the input queue with Kanban, which leads to doing the right things right.

Also, we would be happy if you leave comments with your insights and questions!

Arne and Markus 

On Queue Management at the Berlin Hadoop GetTogether

Another video of another talk of mine. Some months ago it happened that, on a walk to a talk I gave internally to some of my European Product Manager colleagues, I met an old and nice colleague of mine, David Obermann. So I told him where I was headed and told me what he is doing right now. Turns out, we made a nice coupe. The talk I was about to give - a short summary of Queue Management in PD and what I made from it at my work in the last three years - was interesting to him and as fate wants it - David is nowadays organizing the Berlin Hadoop GetTogether. So I was invited 'for one of the next meetings'.


The meeting was held on February 22, in the nice environment of the Axel-Springer building in the middle of Berlin, floor 19 :-o with a great view over the city. (You can drive one of the famous Paternoster elevators there.)


Watch and enjoy the talk, which is a shameless collection of knowledge from Don Reinertsen, David Anderson, Eric Ries and of course lots of others whom I've met during the last years. (Thanks to all of them!)  It is also nearly the end point of this stage of my work life, as of 1st of May I will have a different job somewhere else. I'll keep you posted.

Just before the talk started, I was told I only had 30 minutes, so I kept improvising all the time, which led to me forgetting - of course - a central part of this talk, which really holds the theme together. Anyway.

The Democracy of Kanban - Pecha Kucha from LKCE 2011

Another 5'40'' that rushed my heart.


Arne Roock (@arneroock) has been so nice and did all the work to not only upload the videos of all the Pecha Kuchas from Lean Kanban Central Europe 2011, but he also sent me a cut down version from only my own Pecha Kucha - 'The democracy of Kanban'.


My basic line of thought is: Kanban delivers a more detailed view on a teams' process. This helps to get rid of he black box view that simple boards of the 'ToDo | Ongoing | Done' structure deliver. The more detailed view helps not only to visualize the workflow better and more detailed and thus get more frequent and shot term feedback, it also helps to do some analysis on what's going on.




The Democracy of Kanban from Markus Andrezak on Vimeo.


In this Pecha Kucha I describe why Kanban is a crucial step towards democracy. Kanban is delivering teams a more detailed model of what is going on in their doings. This helps them to get an outside view of what they are really doing in the software development process. This detailed outside view helps the teams to come to decisions that are based on analysis rather than just a hunch.
This fact, of course, is unnerving to those advocating and selling the same recipes over and over again, regardless of the concrete context of the teams.


That again helps the team to reflect on real data of the real 'system', rather than having intuitive hunches on what's going on all the time. Indeed, doing this, has helped me to get rid of several myths that were going on all the time at my workplace. We found out that we simply do not have a problem with too much variation in requirements sizing (which many thought), we as PD are not a bottleneck in our organization we found that out by mapping our portfolio to Kanban), also some teams got better by just leveling their WIP limits differently.


I am fine and can very well accept that some people might get to similar results with intuition. But not all, very few indeed. We didn't. Many don't. That's why I think that the detailed model enabled by Kanban's visual boards together with the metrics are incredibly powerful means for teams on their journey to continuous self improvement. Guru' are not needed. That's why I think that Kanban is helping us democratize the way tat teams can improve their work(flow).


Oh, BTW ... make sure to watch the great and entertaining LKCE11 keynote by Stephen Bungay on how we lost the art of management that Klausewitz and von Moltke already discovered nearly 200 years ago. 

The (limited) value of 1x1 flow in Product Development

There is a lot of discussion going on in the net right now on the issue of single piece flow as a great tool for ... actually what? This is actually rarely defined. (And I think that is the issue of a lot of misunderstanding and disagreeing on things that are actually agreed upon - context being left out.) Also it is brought into play as a true north for a continuous improvement process - as the means of all means, the end of all ends which will lead to the ultimate goasl - the dissolving of the Kanban. Hmmm. I doubt it. Before we go further let's have a look into the follwing recruitment ad: 


Looking for Software Developers


Nickel & Dime Inc. is a new software shop that is working on highest qualty standards. We have opened new facilities that are working under lowest WiP limits. We have achieved a great level of flow. We now want to go to the next level and we are seeking your support: we want to achieve sustainable single piece flow throughout our software shop. If you are not only up for the adventure of getting there but also working under a strict, sustained single piece flow for the next years, no matter what product will be developed, no matter what other factors are weighing in - you are our man. Call us under 0800-111111


This is an impression for the recruitment going on for a company going for single piece flow in software development. Are you likely to hire? Are you likely to stay? Why? Why not?


Let's say Nickel & dime really hasn't achieved 1x1 flow yet. To get there immedeately means revolutionary change. Which problem would be triggering the need for 1x1 flow and solved right away that would justify revolutionary change?


OK, let's not go for revolutionary change but instead use Kanban to control WIP. We lower WIP piece by piece, make problems in the flow visible, caused by whatever issues in handover and development process and environment. We resolve those issues. At least we now have an idea which problems we are facing when we opt for revlutionary change. Let's say all goes well. We achieve 1x1 flow after a certain time. Did we have the right true north now, leading us through the continuous improvement w/ Kanban? That would mean we are in Nirvana now, happy, happy for ever? To answer that question, look at the recruitment ad again. Do we want to develop in strict 1x1 flow for the rest of our time? I guess not. If not, why did we go there, why did we choose that exact true north of 1x1 flow? 


Then, why did Toyota choose 1x1 flow as true north? Because in manufacturing, where you want to elminate variability this makes sense. You want to have a great takt time. As Jim Benson of Personal Kanban fame, @ourfounder tweeted today,

"1 pc flow is based on perfect value stream and like sized / defined work items. Knowledge work has high vriation of work items, rapidly changing contexts and fast evolution. Therefore 1 pc flow achieved will either be temporary or for subsets of the overall work. The moment 1 piece flow is achieved for an entire prod dev process, it ceases to be knowledge work." 

I might add, that ineed we are making money in PD beacuse of the high variation of the work, because there is no repetition and no equally sized work.


This is completely different at Toyota. They go for a minimum of variation, which is the complexity they have to master. Therefore, getting ever closer to 1x1 is the right challenge and the right true north. Still, they use it as an Utopia, no place nowhere and in fact they will never reach it across the whole line. Even less will they reach the even more favorable true north of 1x1 flow in the sequence of incoming client orders. They still try to - all of the time. They'd even be happy to get there. Except for one reason. This is where the Toyota Kata comes into play, which is embeded into their change, indeed defines their change all over the place. They are seeking for ever new small, but challenging steps getting closer to 1x1. The only reason being to make new production problems visible and trying to resolve them. The reason behind that is simply and at the same time as a stroke of genius to keep moving and in a problem solving mode all the time. What is happening along the line is that Toyota keeps awake and energized and creative all the time. Highest quality, great products, etc. are all great but calculated side effects.    


So, if we in our industry take 1x1 as the true north, would we get the same benefits as Toyota? As we are talking about knowledge work and everything Jim mentioned in his few sentences, aren't we rather risking customer focus and generation of value? I have been fiddling with the idea of 1x1 flow for a long time now - because it seems attractive, elegant, compelling. When I think it to the end - for myself - I come to the conclusion that this leads to inward bound, process releated activity rather than customer facing benefits. It gets a stale, dead end best practice with no added value.


I do see a value in 1x1 flow, though, which is using it for a sgort perod of time as a didactical tool to show teams definciencies in flow, excessive handovers, immature PD processes and environments. It is a tremendous learning experience in our field - for a certain time. No more, no less. WhenI talk about 1x1 flow I will make sure that this is the purpose I see in it.


Kanban done right will actually help to achieve Rightflow, the right level of WIP under the given context.


What do you think?

Replenishment - Craving for Feedback :)

First off: We are incredibly greatful for the response we have received so far. Thanks to all of you!


When we published the book - of course - we had plans. We also had vanity metrics in mind. We wanted:

• 200 Downloads
• 50 filled out feedback forms.

What happened is nothing short of amazing: We have more than 1100 downloads from close to 50 countries. But: We are short of reviews and feedback.


Why do we need feedback? Short question- long explanation: The whole book is a multi variable experiment to us. There are a lot of things unknown to us:

• Should we even write a book. apart from the vanity effect of writing a book, the question is: Is there a market for a book, which means are there interested readers out there, which means do we have topics that people are interested in? We don't have a clue. (Still.) The question, of course, is - why embark on a long (high WIP-limit, large batch size) unpredictable journey if it may not be relevant? 
• Which of the topics we could write about are most requested, driving most demand.
• General questions on writing a first book: which format(s), normal publisher vs. self published, distribution channels (eBook vs. print book), etc. We had the trigger when amazon came up with the amazon single concept, which made us think - ah, we can just publish something in small batch size whenever we want. (And we already drfited away from that a little, I guess).
• A million other things, basically we don't know a thing except that we some experience in some aspects of Lean and Kanban that might be worth spreading. 
• Is a German language edition important, or will English suffice?

This means, circulating a small shot and geting feedback on it is a chance for us to learn. Hence the feedback form.


As we said before, the first part has worked out brilliantly! We have more than 1100 (!) downloads in the various formats. (Still more tan half of it in PDF format, which to me as a die hard kindle fan was the first surprise - I thought most people in our community already ditched paper books, PDF etc. for the more convenient and functional formats of .mobi and .epub.)


Now comes the hard part. We planned for 50 feedbacks. We have ... less than 10. Of course, we can't expect too much yet - the book simpy needs to be read first. Also, of course, people have to *care* to give feedback. So, not getting the feedback is the first indication of not being on the right track. We also think, feedback needs time as opposed to ... downloading (for free).


The feedback we have is actually already great as it includes the statement from someone important to us and the community that it gave him the last impulse he needed to also start writing a book. (If this is all the effect we had, it's also fine!)


In short: We would *love* to hear from you:


http://bit.ly/replenishment_feedback or in free form to replenishment@portagile.com


Thanks for staying with us


Arne and Markus

Replenishment - Free eBook published w/ Lean Kanban Central Europe 2011 conference

Edit: We extended the free download until mid November, so that attendees of LESS2011 in Stockholm can also download and comment on the eBook. We already have incredible 800 downloads of the book. We now are really keen on your feedback :) 
Thanks for all, Arne & Markus 




I am happy to announce that today, with the opening of the Lean Kanban Central Europe conference, Arne Roock and me published a free eBook "Replenishment". 

The book's cover

It contains 4 texts on Kanban:

1. Wip Limits
2. Guarantee bandwidth for intangibles to address sustainability of your business
3. Tool Support
4. Project Development vs. Product Development

Our preface explains why we are publishing this free version of the book, so I'll just post it here:

Dear audience,

You are holding in your hands our approach towards a MVP on an eBook on Kanban in the form of loosely coupled essays. We would like to publish it as an amazon single, comes time. Time shouldn’t be long, as the real benefit of publishing eBooks is that you can get away from large batches sizes to small batch sizes, even in publishing. We are thankful for these new options and would like to explore them. 

As this is our fist publishing of this sort and we are yet developing our model we wanted to take the opportunity to publish the smallest possible batch to you for validating our model. We assumed there is a demand for insight in the short form. We also assumed there is a demand for loosely coupled topics that came to our mind which aren’t covered in long form. We assume we should rather hit sooner than late. We also assume that in later phases of the project we publish more amazon ebook singles and can very well imagine to broaden the content by including numerous other authors. 

You now know what we assumed. We have prepared a feedback form and would be happy to receive feedback from those interested. The feedback does not only check our assumptions but leave space for feedback on anything that comes to your mind as well as topics that we have not covered but are of interest for you. 

We had the idea for this book while thinking about the great KLRIS event, organized, of course, by David J Anderson and made the approach more concrete during and after this event. Thanks again to David and his team for coming up with this great event and thus the inspiration! (The KLRIS event is also brilliantly covered in a free eBook ‚Quotable Kanban‘. )

Some note on the cover photo and the title of this book. Standing in front of the famous Geysir Stokkur (and in fact bigger, but younger brother of the actual Geysir ‚Geysir‘) and being still inspired by two full days of discussing Kanban and its future it was obvious that this is one of the most brilliant examples of replenishment. And also, what is the whole of Kanban without proper replenishment? What happens downstream if upstream doesn’t work and what is more upstream than replenishment? Indeed, Kanban leads us the way to exploit the opportunities of clever replenishment.  Read more on this in in ‚Project Development vs. Product Development’. So, rather than going for a shallow effect of showing the eruption, we go for the deep result of serious, powerful, value defining replenishment.

We hope you enjoy and have fun reading our (still) small eBook and don’t forget to give us feedback! It’s appreciated!  

Arne & Markus, 

Hamburg & Potsdam, October 2011

You can download the free version of the eBook until end of October from the following links in mobi (kindle), epub (most other ebook readers incl. iPad) and PDF formats under the following links:

http://bit.ly/replenishment_kindle

http://bit.ly/replenishment_epub

http://bit.ly/replenishment_pdf

As stated in the foreword, your feedback is greatly appreciated and crucial to us. We prepared a feedback form under 

http://bit.ly/replenishment_feedback

There you can also leave your email address if you want to be informed on updates and the final version we will sell over amazon in the not too far future.

You can also leave feedback via mail at replenishment at portagile.com ...

Thanks for your patience, interest, download and feedback

Markus