The notion of creating value streams to improve organizational efficiency and deliver higher-quality products certainly is resonating at the C-level and mid-management in large enterprises. Yet, uptake among development teams charged with creating those products has been slower to happen.

There are a couple of reasons for this. One is that value stream management (VSM) adds yet another tool that developers have to pay attention to. Another is fear that information about project progress and individual efforts will go beyond development managers to higher-level executives, and they may not be measuring the workers and their work against the correct metrics.

For developers, according to Eric Minick, program director, Continuous Delivery and Continuous Testing product management at IBM, this is scary — especially in an organization that is low-trust. “Are you in an organization that shoots the messenger, or are you in an organization that does blameless postmortems and things like that?” Minick said. “The term that we hear is psychological safety — can you say my team has a problem or not? I think there are organizational constraints on this.” 

RELATED CONTENT: What problem are we looking to solve with value stream management?

Another problem is the disconnect between management and development teams as to how things are going. For instance, Minick said, “if you pick any DevOps practice — do you do blameless postmortem, do you do continuous delivery, and you ask the CIO, you ask management and you ask the teams — you’ll see that 60% of CIOs say yes, 45% of middle management say yes, and about 35% of development teams say yes.

“You’ve got this kind of clear green shift,” he continued. “Part of the value of VSM is being honest about it, and saying, OK, we have some tools in place, but our delivery time from code to production is still 18 days. Is that continuous delivery or not? I don’t know, that’s an interpretation thing. But that becomes honest, in that it aligns in truth the development team and execs — but if the execs think you’re doing better than you are, that moment is a little scary. And so, it’s really incumbent upon the execs to send that right message and say, Look, we know there’s different levels of maturity, we’re not going to bring the hammer down on anyone here; what we just want to see is that the people are improving, and that should be done by looking at multiple metrics together. That’s really important to the teams. Are you going fast, or are you going fast with no quality. Are you going slow with quality? Which is better?”

So where does value stream pay off for developers? Very often, the reasons developers have slowdowns are because there are factors imposed on them from outside their team. Organizations will ask, ‘Why is the highest priority thing not getting worked on?” And the answer could well be, “Because I was working on some pet projects for my boss’ boss.” The result of that, according to Minick, could be fewer surprise demands from executives. Or, maybe that executive says that those projects WERE highest priority.

Having a value stream in place that shows where the work came from, and how it got delivered, and that in itself is very valuable. An example is code reviews, usually performed by the most senior developers on the team. And every time you scale the team, you break the team so that now code reviews linger for a week or more, and everyone is angry with each other, yet no one is talking — because they’re developers.

So what happens, Minick said, is this: “You get into retrospective, and here’s the data: Code reviews tend to take 5.6 days. Now, [with honest, blameless communication,] you can have a productive conversation that says which code changes can we have a junior developer do a review on? And now you don’t wait a week for your code review, and you get to market a week faster, and the senior developers get to write some code, and everybody’s happier and less pissed off. It’s those little moments that I think have a really big payoff for the development team, because they always have bottlenecks, and the bottlenecks move depending upon what’s changed, or what unexpected work is coming in from senior management, or what other teams are busy with their own stuff. So, the telemetry should be super-valuable to them in their day-to-day work. And if value stream is working well, it’s going to align them better to the business, so they’re going to be working on more important things, and being more impactful, and that feels really, really good.”

Want to learn more about value streams? Register for Virtual VSM DevCon, a free, one-day training event targeting development teams, to be held July 22, 2020.