The idea of “flow” in manufacturing is widely know, even if maybe not so widely implemented. The world of software and product development is not much like manufacturing, but we can repurpose some of the ideas and concepts. Flow is one such concept we might choose to repurpose.
I guess most people involved in software and product development can intuit the idea of “flow”, but maybe not articulate it clearly or be able to cite the potential benefits of a flow approach.
10. Improves morale. Employees want to do good work. They want to see progress. They want be involved. Implementing flow brings these things together.
9. Reduces inventory. With improved flow, work in process (WIP) is reduced.
8. Makes continuous, incremental improvement (kaizen) easier. Flow is hard since it invites reductions in WIP (work in process), queues and buffers. Thus, flow exposes problems (blockers) that may have otherwise gone unnoticed, and invites us to deal with them, lest development stalls.
7. Improves visibility. Flow, by reducing the amount of WIP, lets people see more clearly what is being worked on, and what is going on more generally. This in turn reduces confusion.
6. More joined-up organisations. Implementing flow in the middle of the product development value stream – i.e. in software development: analysis, design, coding – provides opportunities to better integrate those functions. And moreover, opportunities for integrating the upstream (fuzzy-front-end) and downstream (testing, ops, production) functions too.
5. Improves productivity. Many of the wastes so inherent to batch and queue working (a.k.a. “Waterfall”) are greatly reduced when we focus on and organise for flow. As a result, productivity increases.
4. Improves flexibility. With improved flow, we have smaller, more manageable units of development (a.k.a. batch size) equipment and this allows us to respond more quickly to changes in priorities.
3. Better due-date performance. By reducing the size of queues and buffers, cycle times are reduced and due-date performance becomes more regular and predictable.
2. Builds in quality. When batch sizes reduce, defects are detected earlier (closer in time to when they happened) and less rework is necessary, with an encouragement to fix defects as soon as they happen.
Your benefits list reminds me of similar lists distributed by management at the much-hyped start of any new “initiative” designed to improve efficiency. The issue I have with benefits lists is that they’re always asserted as unconditional. No bullet is ever qualified with a “may” or “should”. It’s as if every benefit item is guaranteed as a slam dunk.
Reblogged this on Healthcare Quality Improvement.