How Value Stream Maps Prompt Us to Ask More Questions, Part 4

I said earlier in this series that no one cares about how “agile” your team is. Or the kind of “agile” your team professess to be.

Managers do care about agility: the ability to respond quickly to a changing or changed environment. And that depends on where your team has delays. That's why value stream maps can offer so much value to see a team's agility.

But the map is just the first step. The next step is the questions the team and the managers choose to ask about the value stream map.

The above value stream map is the one I started with in Part 1, for the expert-focused team. You might be tempted to ask questions about what each person did during their work time. But, the wait time is an order of magnitude greater than the work time.

Instead of asking questions about the people, ask questions about the wait time, the system of work.

Context-Free Questions to Consider About the Wait Times

Look for the longest duration wait times. Here, it's mostly 48 hours. (The 60 hours is the weekend time. And the team got there because they had mostly 48 hours between people's availability for this story.)

If this team had just one long wait time, as in Unearthing Your Project’s Delays, start there. (That post does not have a value stream map, but you can see the long delays and bottlenecks with the wait for the UI people, and then UAT, and then deployment.)

When you consider your questions, see if you can avoid the “why” questions. Why too often sounds like blame instead of curiosity. (I wrote about this in the context-free question part of Manage It! as well as other books.)

Instead, consider context-free questions about the delays themselves:

What problems does this delay solve elsewhere in the organization?
What problems does this delay create, not just in this project, but across the organization?

These questions can help clarify why this team had a relatively consistent 48 hours of delay in the work time. (In this case, people had other projects to do. They were not focused on this project alone.)

Objective Data for Wait Times

Now, dig a little deeper: When the work waits for the next person, what is that next person doing during those two days? Here are some possible questions:

What were people working on during this item's wait times? Sometimes, it's “their” own story, but it could be production support, other critical fixes, decks for presentations, and more. Worse is when people work on other projects, too.
What was the relative ranking of that work compared to this story? Maybe this story deserved no one on it. Maybe the other work did not deserve anyone working on it. (This question explains why I like to rank work in all of the backlog, roadmap, and portfolio. Prioritization is not sufficient. Only ranking can tell you which work is more important and valuable.)

I am sure you can think of more questions that are relevant for your team.

In addition, you might consider a Force Field Analysis, connection circles, or build a causal loop diagram, as with the flow metrics. Any systems thinking approach will help you ask and answer questions.

Subjective Data for Wait Times

Then, there's the data about how people feel during those wait times. That's subjective and quite important.

For example, people might fill out the satisfaction scale as in A Simple Way to Measure Work Satisfaction and See Trends for both the days they work on other things and the days they wait for the next person to work on this item.

I was surprised once when people said they were more satisfied on the days they waited for the next expert. Why? Because they could “catch up” on their other work. The multitasking in that organization was so high I did not understand how they shipped anything.

If the team conducts a kaizen or a retro on their value stream maps, many of the retro exercises can offer subjective insights.

Avoid Blaming Questions

Too often, managers jump to conclusions. In this map, they might say, “Alice takes so long to do anything! She must not be very good.”

Whenever I've seen an expert-focused value stream, the people doing the work are all excellent. It's the managers who have not ranked the portfolio. Or they pushed the “team” into taking more work than the team could complete in an iteration. Or, making it impossible to collaborate as a team.

Or, someone, such as a Scrum Master, told everyone to start their own story, in the hopes of finishing all the work by the end of the sprint.

Value stream maps help people see the effects of their previous decisions. In addition, these maps can help people see why resource efficiency thinking is so deadly if you want agility.

Value Stream Maps Can Expose Resource Efficiency Thinking

Managers do this because they either believe in resource efficiency or do not know about flow efficiency thinking. Sometimes, the managers are not able to overcome HR's addiction to resource efficiency thinking. (Resource efficiency thinking makes it easy to assign blame to the “worst” people and allocate money to the “best” people. That's easy. And totally wrong. Because, as Lewin's equation says, a person's behavior is a factor of the system they are in.)

Do you want organizational agility? Then, focus your organization on flow efficiency. Look for delays in the flow of work through the team and the organization. Consider all the ways every team, including management teams, can collaborate to finish work without significant wait time delays.

The longer the delays, the longer the time between effective planning. That means the less agility at any level. Faster finishing means you can create more options for more decisions, the foundation of continual planning.

Remember: collaboration over solo work. That will get you far.

The Series:

P.S. I'll be doing a webinar on April 8 about this topic. Register here.