If you haven’t read Resource Efficiency vs. Flow Efficiency, Part 1: Seeing the System, I explain there about optimizing for a given person’s work vs. optimizing for features. Some people (including managers) new to agile have questions about working in flow vs. optimizing for a person.
The managers ask:
- How do I know the work won’t take longer if we move to flow efficiency?
- How do I do performance management if a single person isn’t responsible for his/her work? (What’s the accountability, etc.?)
This post is about the length of the work and how people feel when they can’t finish work.
When you have experts, as in resource efficiency, the work queues up behind the expert. Let’s say you have three senior people with these separate expertise areas:
- Cindy has deep knowledge of the internals of the database and how to make things fast. (I think of this as the platform.)
- Brian has deep knowledge of the transaction layer and how to move data from one place to another in the product. (I think of this as the middleware.)
- Abe has deep knowledge of how to present data to the customers and how to create a great customer experience. (I think of this as the UI layer.)
You want Features 1 and 2, which have significant UI impact. Abe is a master at iterating with all the necessary people to get the UI just right. In the meantime, Cindy and Brian go on to Features 3, 4, and 5 because they aren’t needed (yet) on Features 1 and 2.
If you measured cumulative flow, you would see that all five features are open for a while, because these three people have started on them and not finished anything.
Abe encounters a problem with the UI. The customer doesn’t respond or the product management people are not available. Something impedes his progress. So, he starts Feature 9, which is the next feature with significant UI design.
Notice that he doesn’t start the next ranked feature. He starts the next one he can work on.
Cindy and Brian also encounter delays because the test automation isn’t there, or the build takes too long (or something). Choose whatever happened to you last week as an impediment.
They need to stay busy, so they see that Feature 6 needs them both. They start on it. They realize there is a need for UI work. They ask Abe if he is available. No, Abe is working on Feature 9, not Feature 6. Now, Cindy and Brian have another feature in progress.
If this sounds like your project, you are not alone. This is a result of resource efficiency.
The human effect of resource efficiency is multitasking, a feeling of impending pressure because you can see the deadline but you’re not getting closer. You wonder if you will ever finish the work.
Instead, imagine if Cindy, Brian, and Abe along with a tester took Feature 1. They might prepare their platform and middleware parts of the work. They might help Brian with the prototype generation and iteration. They might be able to bang on doors if Abe needs to concentrate on something specific. “I’ll be done with this in a couple of hours. Can you reserve a conference room and ask the product manager to be there? She always gives me a hard time on the UI. I want to know what she thinks of it now.” Or, “Can you call Customer A and get ready for a walkthrough in a couple of hours?”
You might think of this reserve-a-room or call-people work as something a project manager should do. In reality, these actions are servant leadership actions. Anyone can do them.
We often have lead-time for some parts of development. Even if we want to work in flow, we might need other people to finish.
Even if Cindy and Brian can’t directly help with the UI, they can make it easier for Abe to succeed. And, if the tester is involved at the beginning, the tester can create automated tests that don’t depend on the GUI. Maybe the developers not working on product code can help with an automated test framework. (I find that testers new to data-driven or automated testing don’t always know how to start. Developers might be able to help.)
Imagine if Cindy, Brian, and Abe are not the only people on their team. They are the most senior, and there are two or three other developers on the team. What happens when those more junior developers have a question? Cindy, Abe, and Brian have to stop working on their stories to work with the other people. Or, maybe they don’t and the other people are stuck. I see this in teams all the time. I bet you do, too.
When we optimize for resource efficiency, we have people with unfinished, open work. The more work they have not done, the more they have new work queuing up behind them. They work hard all day and don’t feel as if they accomplish anything, because nothing gets to done.
When we optimize for flow efficiency, people finish things, together. They have less work in progress. They feel a sense of accomplishment because they can point to what they have completed.
I can’t guarantee a team can finish faster in flow because I am not an academic. However, you’ve heard, “Many hands make light work.” That’s the idea. When we help each other move a chunk of work to done, we all succeed faster.
Part 3 will talk about what managers perceive as performance management.
| Reference: | Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People from our JCG partner Johanna Rothman at the Managing Product Development blog. |
