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