Seven Changes To Improve Flow In Your Software Development Process

Seven Changes To Improve Flow In Your Software Development Process

Many folks drinking the Lean coolade seem to believe that removing waste is at the heart of the Lean approach. I beg to differ. I’d say that improving flow is the heart of Lean.

Here’s seven ways in which your team or, preferably, your organisation as a whole, might go about improving flow:

  1. Adopt a small thing as the universal unit of work. And by universal, I mean some unit of work that everyone across the whole organisation can recognise and adopt. This could be Use Cases, User Stories, or something else. Just keep the “small thing” small (never more than a couple of days work for a couple of people). cf Heijunka, FlowChain.
  2. Make flow visible. In particular, make e.g. queues, queuing times, and end-to-end cycles times visible for all to see.
  3. Know your WIP (work in progress) and work to reduce (limit) it. Cf. Little’s Law.
  4. Use demand to “pull” units of work through the system (as opposed to “pushing” work through).
  5. Eliminate – or at least minimise – hand-offs. That is, having work pass from one specialist to another. Each hand-off typically introduces another queue, with the inevitable costs and delays. One way to do this involves multi-disciplinary teams, or better still, up-skilling individuals so each person can competently take on a variety of specialist tasks.
  6. Identify the goal; understand demand (by various means – for example follow individual “demands” through the system, end-to-end;) identify the constraint; and apply the Five Focussing Steps (repeatedly). Cf. Theory of Constraints
  7. Experiment continually: trial possible improvements to flow, one by one, to assess their actual efficacy, in isolation from one another. Cf. PDCA a.k.a. the Shewhart Cycle.

And of course, none of the above suggestions will do much good, or even get acted on, unless and until the folks doing the work internalise a basic appreciation of the very notion of flow. And that’s unlikely to happen unless and until the work environment supports and nurtures folks’ curiosity and innate desire to do a good job.

Further Reading

The Principles of Product Development Flow ~ Donald G. Reinertsen
Seven Changes To Remove Waste From Your Software Development Process ~ Cecil Dijoux
Product Development Flow ~ FlowchainSensei
LondonCD Talk based on this post ~ Video
Getting People to Limit Their Work In Progress ~ Ben Linders

2 comments
  1. Great advice though I’d suggest one tiny edit,

    “…the LEADERSHIP AND folks doing the work internalise a basic appreciation of the very notion of flow.”

    Until leaders value flow (effectiveness) over utilization (efficiency) don’t expect much to change.

Leave a comment