Why we want to focus on Flow while using Lean and Agile

While the Agile community is finally starting to embrace Lean it’s still behind the curve. The real target is flow via business agility – the quick realization of value sustainably, predictably and with high quality.

Even this is no longer cutting edge. Donald Reinertsen’s Principles of Product Development Flow is over a decade old. Agile’s recent adoption of Lean is good but it still is a bottom-up approach. Thinking in terms of flow creates a better context and will put you years ahead of current, common thinking.

Continue reading “Why we want to focus on Flow while using Lean and Agile”

Multi-tasking is not the problem; it is a symptom of bigger problems

The bigger problem are delays in workflow and in getting feedback. It’s also useful to realize that you are task-switching not multi-tasking.

The primary causes of task switching are interruptions and not having the capabilities you need. Either of these require you to switch to another task.

Continue reading “Multi-tasking is not the problem; it is a symptom of bigger problems”

Side affects of frameworks that focus on their practices and not your flow

Most of the behavior we get comes from the system in place. This means how the people are organized and the agreements (or not) they make with each other. When adopting frameworks, you are creating a new system. There are particular patterns of behavior driven by frameworks that focus on their practices more than on the flow thinking that is needed: Continue reading “Side affects of frameworks that focus on their practices and not your flow”

What role does Flow play in your approach?

Don Reinertsen says “A flow-based process delivers information on a regular cadence in small batches. In fact, cadence helps lower transaction costs and makes small batches more economically feasible.” He also suggests the best measure for flow is reducing the cost of delay – that is, what delays in value realized cost in terms of lower revenues, opportunities lost and higher risk.

Achieving this requires reducing handoffs, managing queues and having a focus on small batches of work that deliver high value.

But all of this is akin to “buy low sell high.” Is your approach limited to providing you a set of practices to guide you or does it also provide you with an understanding of Flow so that you can tune its practices to your situation?

For example, forming trains when teams are well-formed is not difficult. But does your approach provide the principles of Flow so that handoffs and delays can be avoided even when the teams within the train are not cross-functional? Doing so can shorten the delivery (and planning) time considerably.

If there are delays in your workflow what tools does your approach provide for you to lower them other than the advice of a consultant?


this is one in a series of blogs. You can see the entire series at