I've been working with a number of people who want to work in a more agile way. These nice folks have one stumbling block: resource efficiency vs. flow efficiency. This is partly because of how they see the system of work.
If you ever used phases or a waterfall approach, you might have tried to optimize resource efficiency:
In this image, you see that the work flows from one person to another. What this picture does not show is the fact that there are delays in the workflow.
Each person is a specialist. That means they—and only they—can do their work. The more senior and the more specialized they are, the more they need to do the work and the less capable other people are (for that work). Think of a UI designer or a database admin. I often see teams who don't have those necessary-for-them roles.
With resource efficiency, you optimize for each person along the way. You get the feature when you get it. Each person is “fully utilized.” This leads to a cost of delay. (See Diving for Hidden Treasures to see more costs of delay.) It also leads to problems such as:
- “It takes forever to bring people up to speed around here.”
- “Only Fred can work on that. He's the only one who knows that code (or whatever).
- “You can't take a vacation. That's just before we want to ship and you're the only one who knows that part of the product.”
- Many features are partly done and too few are complete. (The work in progress is quite high.
Contrast that with flow efficiency:
In flow efficiency, the team takes the feature. The team might specialize in that feature area (I see this a lot on programs). If anyone needs to be away from work for a day or a week or two, the team can continue to do the work without that one person. Yes, the team might be a little slower, but they can still release features.
In flow efficiency, it doesn't matter what each person “knows.” The team optimizes its work to get features done. You can see this when teams limit the backlog coming into an iteration, when they pair, swarm, or mob to finish features. If the team uses kanban and they keep to their work in progress limits, they can see flow efficiency also.
Resource efficiency is about optimizing at the level of the individual. Flow efficiency is about optimizing for the feature.
If you are transitioning to agile, ask this question, “How do we optimize for features? It doesn't matter if we keep everyone busy. We need to release features.” This is a mindset change and can challenge many people.
Here's why you should ask this question: Your customers buy features. They don't buy your busy-ness.
When I tell managers about resource vs. flow efficiency, they often react, “Yes. But how do we know the features won't take more time?” and “How will we know how to do performance management?” I'll address that in parts 2 and 3.
Update: All the posts in this series:
-
- Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System
- Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People
- Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance
- Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability
- Resource Efficiency vs. Flow Efficiency, Part 5: How Flow Changes Everything
Pingback: New PM Articles for the Week of September 14 – 20 - The Practicing IT Project Manager
A good article grazing across complex topics that Reinertsen enumerates in “Principles of Product Development Flow”. We are fundamentally flawed in our thinking of “resource efficiency” without systemic and queue considerations. Simple example: If you are watching a relay team the efficiency of the runners is only 25%. Watch the baton, not the runners!
Peter, thanks for the mention of Reinertsen. Yes, he heavily influences my thinking.
Pingback: Professional Development – 2017 – Week 7 – Geoff Mazeroff
Johanna, Great piece! A smart way to think about product development. Concept-wise a little bit like the Kaizen principle of making sure people are cross-trained and work in groups to improve productivity. See for example https://www.kaizen.com/blog/post/2010/02/08/reducing-delays-through-cross-training.html Thank you!
Ron, yes the cross-training is one of the (many) Costs of Delay Jutta and I wrote about that we collected in Diving for Hidden Treasures. I summarized my series here: Cost of Delay: Why You Should Care, Part 6. (Jutta wrote the one about experts and work queueing behind them.) I have several posts that talk about why experts should never work alone.
Pingback: Trillion-Dollar Teamwork: Goal-Setting With OKRs – 1
Pingback: Individual Contributor vs. Team Member – 1
Pingback: When OKRs Become MBOs and Accountability (Part 1) – 1