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

KLRIS

... stands for Kanban Leadership Retreat Iceland, which took place in the wonderful Icelandic summer 2011, luckily one not being impacted by any physical volcanic activity (even though I've learned that the people on Iceland love and repect but do not fear heir volcanoes the least.)

Replenishment

It was a gathering arranged by David Anderson to answer demand from the best trained and most well known Kanban coaches and practitioners around the world to discuss matters. The event was organized in the unformat of an unconference.

Famous German Kanban Authors ;)

If you couldn't make it, don't despair. Today David has published a free ebook, edited by Janice Linden-Reed, full of quotes covering several pillar topics of Kanban like Foundation, Transitioning, Visibility, Limited WIP, Measurement, Flow, etc. The end of the ebook also provides some longer contributions by Arne Roock, Al Shalloway and Jim Trott, Mhesh Sing, NIcholas Muldoon and also yours truly w/ 'Estimates are overrated' which you could already read here. The book contains a slightly revised version of the text thanks to some editorial work by Janice Linden Reed - thanks for the support! The text got so much better and clearer after review by Janice as a native speaker.

Thing area - birth of icelandic democracy

Please enjoy the ebook! Browsing through the ebook happily today, I was really amazed how good the experimental format of collecting quotes works. It really captures some key Kanban insights as well as some of the spirit in Rejkyavik (esp. for those who haven't been around).

Anarchy in Iceland?

There have been many insights for me in (on?) Iceland. There is one insight I had, which is rather on a quite meta level, that I want to share to reflect on the state of the community. And this one insight was not easy for me to digest in Rejkyavik itself but grew on me ever since.

close to ...

... bursting

Regarding culture, background and experiences we have been quite a diverse crew gathering in that hotel. To me that was quite a challenge at times. You can not imagine how complex it was in some of the sessions to nail down the topic that actually seemed to be so clear to me in the beginning. Just take a topic like ’Portfolio Management’. Already having contributed a chapter to the German translation of David's book, I was sure to have a grip on the topic. But after only some minutes I was shocked by the wealth of different contexts in which Portfolio Management may take place beyond what I experienced until then. There was quite some time of cognitive dissonance and dizziness in some of the sessions for me, summing up the whole picture of all participants. What is now left for me as the basic impression and insight is the openness of the leading Kanban Crew and most of all the openness to not only try to verify the Kanban model but to also look out for falsification.

Famous German Kanban Author before nearly drowning in Gullvattn

In short, I love the community, I loved the retreat and I really loved Iceland.Thanks a lot to David and his whole team for making it happen!


Go on and don't hesitate to download the ebook, read, enjoy and capture some of the spirit of those great summer days on the Mid-Atlantic Ridge. It's a gift :)


Thanks for your attention,


Markus

Me, stoked by Ielandic nature