Recommended reading from #ProductTank, first edition in Berlin


The ist of books recommended at #ProductTank 1 in Berlin.

The abstract but most worthwhile stuff for me: 

  • Don Reinertsen, 'Principles of Product Development Flow': This is really basic stuff why lean works, based on queuing theory, applying insights from network switching to resource allocation, explaining why the focus on resource utilization is leading to blocked systems ... it will turn your head around. But very dense, zero fluff, so it is hard to consume.
  • David Anderson, ,Kanban', German edition w/ final chapter on Portfolio Kanban: THE book on Kanban, here the German edition w/ my chapter on Portfolio Kanban.
  • Taiichi Ohno, ,The Toyota Production System': Not really that much on product, and it is always dangerous to draw conclusions from production towards knowledge work, but: This is just a great book covering the soft topics, purpose of companies, how to deal with the human side etc. Also, in this book, I think, he predicts something like what we are today doing w/ Kanban in PD.
  • Stephen Bungay, ,The Art of Action': Stephen Bungay is a historian. His topic of expertise is prussian war strategy and tactics. Funny enough, they had agility and the whole autonomy, decentralised decisions etc. thing already decoded - but unfortunately this was all forgotten in the meantime. He explains all the basics about it and what role alignment plays in this game and how to get there and then ... how easy all of this could actually be (Hint: Spice Girls - ,Tell me what you want, what you really really want‘). 

The following books came to my mind during our discussion on metrics: 

  • Kahnemann, ,Thinking, Fast and Slow': On how our brain ticks, how we think, why we fall for all these strange cognitive biases. (OMG how many of them there are!) I think the most dangerous one w/ regard to extensive metrics is optimism bias - oh, I have seen it happen by the million! Yesterday I had the feeling that some people think they are safe from bias ... read this, do some of the exercises and you know ... you're not!
  • Avinash Kaushik, ,Web Analytics 2.0': The book on Web Analytics for me. Easy enought o understand. he also understands the principle of ,measuring up‘ (not doing too much) Also he explains how to get some qualitative data in addition to all the quantification.

And finally really specific to Product Management

Have fun,


Hedgehogs and Foxes - it is hard to get along (but worth it)


As for many others, one of the more interesting aspects about the election campaign in the US was the success of Nate Silver in his prediction. That, of course, led me to reading his brilliant book 'The signal and the noise'. In this book while explaining his path towards the prediction of elections, Nat Silver describes some interesting facts about political pundits e.g. in TV shows.

He analyzed several hundred predictions made TV pundits in a popular political talk show. He came to the conclusion that the predictions of those specialists weren't any better than simply rolling dices. Basically the distribution from 'prediction completely wrong' over 'prediction somehow ok' to 'prediction completely right' was a perfect rendition of a Gauss distribution aka bell curve. Depressing. But to Nate Silver this meant he saw a chance. After being busy in Poker and coming up with Pecota, a prediction system for player stats in Baseball, he decided to make a move into the fields of politics. It simply couldn't be harder to predict politics better than those lousy pundits. Of course, first he analyzed just why those predictions were so bad. What he found out, after talking to psychologist Philip E. Tetlock was the following, which Tetlock also describes in his book 'Expert Political Judgment: How Good Is It? How Can We Know?'.

Regarding proneness to biases and certain views which influence predictions, there are basically two kinds of people: Hedgehogs and foxes. Hedgehogs believe in the one great idea that holds the world together. Thus they express clarity (vision?) - but of course they are also more prone to evangelizing the one important idea. Foxes on the other hand like a more complex view of the world, combining several smaller aspects and forming a very specific and flexible view. Foxes are sometimes hard to understand, it is hard to follow their complex views, but they are open to new facts and feedback which can again alter their world view. The issue is - foxes rarely make it into TV, much less even into political talk shows. In TV they are no fun. They don't polarize, they don't fight. They simply don't draw attention towards them. Hedgehogs on the other hand make it into TV. Often. That is because they do like to polarize and fight for their one real, true idea(l). This leads to the worst predictors - hedgehogs - being more frequently in TV. Hedgehogs sell, foxes don't. The result is known - see above.

As Tetlock describes, the properties of hedgehogs and foxes lead to hedgehogs being terrible in their predictions (dices!) and foxes being quite good at it. Given the above description you can already figure out the reasons: Hedgehogs despise feedback and information that is dangerous to their one big great idea that saves the world. They are the epitome of being biased, even after reflection. If you ever read Kahneman's 'Thinking, fast and slow' and were surprised about how much are biases are influencing us without us knowing - imagine hedgehogs as hallways consciously blending out slow thinking because it hurts their idea. Foxes are grateful for all kinds of small information, enriching their world view, although making the collection of neat small ideas ever more complex and thus ever less easy to communicate. But they always update their model of the world with the latest data given to them.

While hedgehogs feel comfortable only with supportive feedback, foxes feel comfortable in a complex world of wild ideas.

Now, after a lengthy introduction on the topic you are allowed to ask Markus, why are you telling me this?'. Let me get back to a twitter debate I encountered some days ago based on this nice blog post by @klausleopold (Foxy!).

Enjoy the twitter conversation here: Klick on the Link to the tweet and try to detangle the conversation that ensued in your favorite twitter client. ;)

The whole point of the tweet stream here in this context is to show that there are huge debates amongst the communities, tribes, religions?, leaders? etc. of  Agile, Kanban and Scrum (and sure many others). Which is an interesting enough observation in itself, as to the outsider (such as my wife, my mother, my kids - basically everyone except myself) it could all be the same. But it obviously is not. Like brothers and sisters, debates about the seemingly small differences (seemingly!) can be fought at incredibly high noise levels. (If you don't believe me look at the tweet stream again - it is there for a reason). But that arguing about 'small' differences (and I could go hedgehog here for once: THEY ARE NOT SMALL, BUT IMMENSE!) can be harder than arguing about huge differences is only part of the truth.


Let us watch the following Venn diagram which is only my personal view of the common ground between Agile, Kanban and Scrum. We have a huge group of Agilists having much in common with Scrum (also a large group). Then we have the Kanban group of people, not too big yet but growing (sorry, no dynamics in this diagram). They have a certain something in common w/ both agile and Scrum and vice versa.

Where are you in this Venn diagram - which is completely agnostic about the hedgehog / fox dichotomy
The situation is complex. The picture could be about common ground in beliefs, values, practices or simply about people being part of a certain or several tribes. For the moment being lets just think about the latter. Also for simplicity sake, let's say we are looking at one individual being part of just one tribe - let's say 'Scrum'.

Hedgehog Time: A Scrum hedgehog knows Scrum will save the world, not only in the world of software/product development (PD) but in basically all areas of Life. There's hard data to support this. Thousands of companies were already saved by migrating to Scrum. Also, a wicked sports car company is completely based on Scrum. Even if Ken The Schwaber himself says that (was it) 80% (?) of Scrum is more or less ScrumBut - a hedgehog knows what he's doing. Also, the success of the Scrum alliance, one of the most successful pyramid schemes speaks for itself. Thousands and thousands of CSMs (handshake included and approved) can not be wrong. Also, the hedgehog heard about this thing called Kanban, which claims to be agile but even got rid of the agile success factor iteration. These guys must be looneys, also why the hedgehog heard - these guys simply copy techniques from the inhumane area of car manufacturing. That much for agile. Kanban clearly is not the one great idea saving the world - rather the opposite.

The Scrum Fox sees some problems in Scrum, lives with it. He also sees some issues with it. Scrum changes his life a while ago, but also he somehow feels stuck. He incorporated new techniques and idioms all of the time. BUt somehow he is stuck. He watched his data, velocity didn't improve after a first bump. He is now aware of this thing called Kanban, bought Corey Ladas' 'Scrumban' and in the last retrospective he mentioned if iterations currently make sense and if foxes team couldn't try without iterations for 4 weeks.

But all this is not my point. Hedgehog wants Kanban to be THE thing. He also wants people to accept this. He wants to move people towards Scrum. Same is true for the Kanban hedgehog. The Scrum fox on the other hand likes Scrum, but it isn't THE thing for him, no life saver. Last week he was at a meeting of a local Ltd Wip Society. He wondered why all the talk on Scrum vs. Kanban was mentioned, let alone be a heated debate.

When the hedgehog visits a <enter your favorite methodology here> conference he feels among the same, he is at the place to be. The fox, well, he has some doubts about the uniformity of the tribe. It is all too good to be true. Too much preaching to the converted. Something feels wrong, something is wrong. Pushing the fox leads to loosing him, not supporting the hedgehog does the same to him.

This sounds complicated enough, but we can explore the model further. Now let's say a hedgehog has gone the whole way - he started ages ago w/ XP (after having survived  RUP - he was a RUP hedgehog at the time). Then it was agile, the  *right* implementation of agile was Scrum and yes, he can't deny it - now Kanban has some advantages in his environment. But now it is Kanban. So our hedgehog likes agile, he understands Scrum, but he knows that the real deal simply is Kanban. Fine. He is a happy man. But … he wants everyone to see that this is actually one great big thing. *Scrum is agile, agile becomes agile ^2 which is Lean is Kanban*. So obviously we are all one tribe, one big family. We must all understand this. This is what the multi hedgehog wants - unity for the one big idea of Kanban/Scrum/Agile.

Enters the multi fox. He has the same history as Mr. Multi-Hedgehog. He is convinced that his way was good, but all data shows that he has made best progress with Kanban. He likes all the folks. But some are really getting on his nerves. They want to tell him he has to be part of that great, big, huge thing, the conspiracy against management: The Kanban, Agile possibly even Scrum thing.   We must all be alike now, must be the same. But Mr. Fox knows he likes to think in terms of Kanban. It gives him flexibility. He thinks it is elegant. He does not understand at all while he should call himself agile. Being a fox he doesn't need to believe in the huge *Scrum is agile, agile becomes agile ^2 which is Lean is Kanban*-will-save-the-world-idea. He knows there are many methods, many models. They can co-exist, they don't need to be the same. Vive la difference.

And so, while the fox and the hedgehog do the same thing they don't get along. The multi hedgehog knows he's right while the multi fox is still searching. The multi-hedgehog wants the multi-fox to be more supportive of the agile folks, which the multi-fox has no interest in at all. In fact, the multi-fox feels pressured into a tribe he does not want to belong to. He just knows tools he uses.

And now go through this exercise for all kinds of tribal combinations of hedgehogs and foxes. Have fun!

The hedgehog's closed view and system is a threat to the Fox, whose openness is vice versa threatening the hedgehogs views. While what they do is exactly the same.

Why am I telling you all this and for oh so long? The thing is that most debates are not between methodologies - I think - but between very close foxes and hedgehogs. Once you get this, I hope, you can better lean back and relax. Now you know why your colleague fox seems so unambitious towards your religion and resists your pressure to join the tribe. As a fox you know why the hedgehog colleague does not feel supported in his belief system and values, even as you share them. While arguing on twitter guys, or on conferences - always try to think of the hedgehog and the fox. There is no difference in value between hedgehogs and foxes. They're just different. The openness of the fox is great, as well as the clarity and determined spirit of the hedgehog. They're both ok, it's fine. But it is hard, but necessary work to always remember this. Wiki says Gary Hamel prefers hedgehogs which I absolutely do no understand. I think they are a great combination in real life, once they get to understand their underlying issue.

I am a fox, of course. Hence I don't like tribal enthusiasm. Sorry. ;)

PS.: For fun have a look into this dispute between what I would characterize as Scrum hedgehogs and Scrum/Kanban/Agile/I-am-beyond-estimation hedgehogs, amplified by twitters great 140 char communication bandwidth constraint. Please do me the favor and read the whole tweet thread rant conversation:

Footnote 1: The story of hedgehogs and foxes originates in Tolstoy and was then reused by Philosopher Isiah Berlin in 1953 (See:

Footnote 2: If you want to find out if you are a hedgehog or a fox - try this simple test

Footnote 3: Here a short text on the impact of hedgehogs and foxes on science.

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?