There's nothing wrong with value stream management (VSM) itself, but there's plenty wrong with how it's being considered and discussed by bloggers, industry marketing types, and others, who often conflate it with DevOps and Agile. It's not the same thing.
When you read about value stream management, you need to be able to recognize bogus information when you see it. Here's are five things obfuscating the truth about VSM—and what you should be focusing on instead.
1. Misattribution, personification, and wishful thinking
The first problem relates to the many unsubstantiated claims about the benefits VSM can provide. Beware of statements that start with phrases such as "VSM provides visibility into … " or "VSM provides control over …"
VSM doesn't provide visibility or control. Sure, you want it to, but VSM isn't a specific process, method, framework, tool, or platform. It's just a concept, and you're on your own to figure out how to use it.
You may hear that "VSM empowers teams to remove waste." Oh yeah? How? Sure, we wish our VSM efforts empowered the team, but I wouldn't say that they do. It's appropriate to say that your VSM efforts should empower your team. Or, at least, they shouldn't disempower your team. But to say that VSM does this or that misrepresents VSM and sows confusion.
"VSM automates the flow of information." How? Automating the availability of information is a good thing, but, again, VSM is a concept. As a concept, it doesn't provide or do anything.
2. Excess specificity and limited scope for improvements
Some writers are too specific about what the recommended improvement should be, which direction they should go, or what technique should be used. This leaves them with a limited view of the potential for improvement. Be wary of phrases such as "The focus should be on the critical indicators of speed and quality," or "Speed and quality are essential to profitability."
Sometimes, these aphorisms may be true. But what about when they are not?
Most software teams consider lead/flow time, flow load, waste reduction, and quality as key indicators of success. But what if the activities essential to the profitability of a given business aren't benchmarked by speed and quality?
Sometimes, predictability, innovation, or cost reduction are the essential measures. If upper management needs predictability or innovation, it must be willing to accept some types of waste.
For example, to achieve predictability, a certain level of quality is important, but speed isn't the focus. With innovation, speed usually goes hand in hand, but quality needs may differ. A blind focus on traditional lean flow measures may lead teams astray.
If speed—lead time or time to market—is a critical factor for your business, you must accept excess capacity (slack) and/or constraints on what is allowed into the system. Why? Throughput plummets and lead time soars when a system's load goes too high. When firms place constraints on what is allowed into the system, pushing back or saying no to requests that exceed a predetermined level, they can ensure a healthy load.
At other times, when people say they need speed, what they really mean is they want high throughput—accelerated completion of a big batch of work. If high throughput is the driver, then you must consider other business goals and develop an improvement program and VSM approach tailored to that need.
Too many people who are trying to lead the discussion of VSM have a limited (lean-, DevOps-, or IT-centric) view of how a value stream should operate. They have a narrow perspective on the factors that contribute to how an organization's value stream should be designed and optimized.
3. Conflating working in the business with working on the business
A common refrain I hear is that you need to align software development efforts with business outcomes. That's noble, but it doesn't have much to do with VSM. Think of the "efforts" as epics and stories. Product management feeds epics and stories into the value stream.
Business outcomes are like product enhancements and fixes—things such as reducing shopping cart abandonment, improving stickiness or retention, or easing recruitment—that are solved by the work that flows through the value stream. Business outcomes are what comes out of the value stream.
You hope that your epics and stories are aligned with business outcomes. They should be. You also hope they produce the desired business outcomes. But that's a product management concern, not a VSM issue. It would only become a VSM concern if there were some problem with the product management process.
Product management process improvement must be about the process, particularly the epic selection or story tracking process. It shouldn't—and can't—be about the specific epics and stories in the pipeline.
Real business outcomes (the subject for product management) might be about product features or customer retention. In contrast, VSM is about people or process issues that hinder the ability to produce those outcomes within the desired parameters.
Parameters refer to elements such as time to market, predictability, quality, innovation, and throughput. Those variables are improved by working on the value stream.
4. Improve the correct things
This means your organization must identify its value stream problem and its improvement goal. For example, you might be having trouble meeting your commitments, whether to marketing, customers, training, or other teams. They all crave predictability.
If that describes your organization, you may need improvements related to breaking dependencies or dependency identification and management. You may need to improve the stability of throughput—not necessarily more throughput, and especially not throughput with more variability.
However, those aren't business outcomes. Those are organizational improvements. Choosing stories (product management work) involves working in the value stream. Improving the process for choosing those stories is working on the value stream, i.e., VSM.
5. Equating VSM with agile
Some people in the industry continue to lambaste waterfall and praise agile as if it were VSM or a way to perform VSM. But agile isn't the point.
What can companies with existing pockets (or even buckets) of waterfall do? Does VSM not apply to them? Are they not allowed into the club? Heaven forbid. These scenarios are also value streams, and they also need to be managed. Waterfall is an appropriate process in certain situations. Sometimes it isn't worth the disruption to attempt an agile transformation.
A corollary to this is that lessons from the Project Management Institute are useful in VSM. It is appropriate, and even recommended, to have techniques from the project management body of knowledge in your toolbox. Doing so facilitates managing the work flowing through value streams as well as the work on the value streams themselves.
What you should be talking about
I don't know where the industry will take VSM next or how its definition will change over time. At the moment, the definitions put forth don't seem to be limited to lean, and that's good. But many authors and speakers like to talk about lean, agile, and DevOps in their VSM articles and webinars.
Here's what I don't hear people talking about or writing about as much:
- Improving the product management side of VSM
- Good ITSM techniques as part of VSM
- Quality assurance or quality engineering best practices that have been honed over the years
- Instilling software craftsmanship or pair programming as part of value stream management
- Acknowledging that effectively managing your value streams might involve concepts beyond lean and agile, such as Teal organizations, management 3.0 as described in this excellent book, the Product Management Body of Knowledge, autonomy/mastery/purpose, innovation, and empowerment
Equally important, not many players in the software industry are talking about the human element and its importance in VSM. They don't recognize that effective VSM isn't achieved solely by applying lean or agile or SAFe or DevOps or some specific tools. It involves human engagement, and a diverse array of human activities.
See VSM for what it is
This may sound like a "broad strokes" approach, but it encapsulates the value of human involvement in VSM. So let's quit presenting VSM as something it isn't. Let's acknowledge that it isn't a specific process, method, framework, or platform and that by itself it doesn't provide anything.
If you want to preach agile, DevOps, or the current software excellence flavor of the month, do it. Just don't commingle or confuse these approaches with VSM. Instead, let's embrace the true nature of VSM, including the "necessary messiness" that humans bring to the equation, and leverage it to produce better organizations and value streams.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
