Why flow?

As with any flow, output is higher, faster and more consistent when it’s laminar (continuous) and not turbulent (high variability).

One of the main challenges in product and organization development is managing the ever increasing complexity and the uncertainty that comes with it. It pays to deliver in a flow of smaller increments that provide fast feedback, risk reduction, and other types of value. That in turn also has a positive impact on quality, customer satisfaction and motivation.

Without it, it simply means things stay underwater longer, and that means:

Driving flow

First we need high level guidance of flow to keep it flowing uninterruptedly at high speed in the correct overall direction. This is done by providing purpose, vision, etc. as described in the article Guide Flow.
Next we need to manage the flow in more detail to keep it laminar. This is done by splitting into small increments with limited work-in-process and preventing cluttering by keeping batches small as described in the Manage Flow article.
An important part of flow is the cycle time for design-build-test. To become more rapid and responsive, we can improve physically (e.g. rapid prototyping) and virtually (e.g. model based) as described in the article Integrate, Test & Release.

What’s stopping us?

As you can read in the detailed articles, many of the problems with modern product development come from, as Don Reinertsen called it, “the problems wit current orthodoxy”. It’s highly recommended to read Don Reinertsen’s books “Managing The Design Factory” and “Principles of Product Development Flow”.

1. Failure to Correctly Quantify Economics – Many times, people focus on proxy variables (like hours spend on a drawing) instead of the real outcome (value like early feedback and risk reduction). And also, we mostly only look at how much something costs to build and we miss out on the bigger picture called Cost Of Delay (what does it keep costing if we deliver later). We need to calculate and therefore quantify development cost, product cost, product value (e.g. revenue, market penetration, grow), and risk, and plot that on a time scale (duration). Further, we need to take into account that often we have to make a trade-off and that we need to do this at system level rather than local optimization which can effectively hurt the overall system.
2. Blindness to Queues – Product Development is for the most part information management (models, drawings, specs, manuals) and therefore inherently invisible (both physical and financial). It’s not like being on a factory floor where semi-finished parts are highly visible. This in turn makes it very difficult to see the work piled up everywhere. Also, people fail to understand the direct relation between queues and cycle times and therefore cost of delay.
3. Worship of Efficiency – We’re living in a world that’s still highly efficiency driven often resulting in local efficiency causing system level deficiency. Efficiency is of course important, but only after being effective first. Like Steven Covey said ‘Management is efficiency in climbing the ladder of success; leadership determines whether the ladder is leaning against the right wall’ and also ‘The key is not to prioritize what’s on your schedule, but to schedule your priorities’. Hence the two levels: Guide Flow, and Manage flow. Furthermore, being overly efficient (e.g. by loading people to the max) causes huge increase of cycle times (duration) which in turn increases the cost of delay.
   
4. Hostility to Variability – As new things emerge in the complex domain, it is important to not force thing into the complicated or simple domain (see Product Development Complexity). What works well for series or mass production where we want consistency in output, works counterproductive in product development (it would kill innovation). So rather than fighting it completely, we should minimize the ‘bad variability’ (stuff that we can safely standardize or automate), and manage the remaining variability.
5. Worship of Conformance – Many people still strongly believe that sticking to the plan delivers best results and that the opposite will increase cost and time. But, product development is uncertain (lots of learning to do) especially in today’s fast moving world, so plans become outdated soon. As valuable new information becomes available, we should make use of it and update our plans.
6. Institutionalization of Large Batch Sizes – Driven by blindness to queues and worship of efficiency, we tend to create large batches. Batches delay (its like a queue) and therefore increase cost of delay and cause variation (start-stop). We should make an effort to reduce batch sizes by reducing the needs for them (e.g. automating a manual test). The optimum batch size for a certain situation is a balance between cost of delay (or holding cost) and transaction cost.
   
7. Under-utilization of Cadence – Events like planning, synchronizing, delivering to production, releasing, etc. are mostly planned ad-hoc (when enough information is available and stabilized and all are available). This results in delivering asynchronously in large batches. Delivering small increments regularly (on cadence) actually helps lowering transaction costs and makes small batches more economically feasible.
8. Managing Timeliness instead of Queues – Most companies manage timelines rather than queues. Partly because that’s how managers are trained and mandated to do, partly because we are blind to queues and the statistics of variability. People insert contingency reserves to the schedule. The more we increase planning detail and the harder we try to incentive performance, the worse our problem becomes.
9. Absence of WIP Constraints – There’s a famous (and surprisingly simple) law called Little’s Law. It shows a direct relation between WIP, delivery rate and cycle time. With a certain delivery rate, the cycle time is a direct result of the WIP. Constraining this WIP therefore constrains cycle time. For this one first have to realize this relationship and next visualize WIP to be able to start constraining it.
   
10. Inflexibility – In product development we find high levels of specialization. Partly because we worship efficiency, partly because high tech solutions require expert knowledge and experience. This results in inflexibility which in turn, when we encounter variability, results in delays (more variability) which we then start to manage (reduce). 
11. Non-economic Flow Control – Most of development work is handled on a first-in-first-out (FIFO) sequence. Sometimes it gets a bit better when work gets prioritized, however, this is often based on ROI which is a one sided approach. Furthermore, when this is done in combination with fixed time schedules, pressure is building and higher utilization and variance make things even worse. We need to start thinking in terms of economical prioritization by using cost of delay and actually delay or cancel developments (or parts of them) based on that.
12. Centralized Control -Due to our worship of efficiency (over response time) or fear for chaos, we tend to centralize control. Examples are project management offices and centralized information systems. This results in delays and poor decisions based on secondhand information.