There’s nothing wrong with value stream management (VSM) in and of itself, but there’s a lot wrong with how it’s thought of and discussed by bloggers, industry marketers, and others, who frequently combine it with DevOps and Agile. It isn’t the same thing at all.
When you’re reading about value stream management, you need to be able to spot false information. Here are five things that are obscuring the truth about VSM—and what you should be paying attention to instead.
1. Misattribution, personification, and wishful thinking
There’s nothing wrong with value stream management (VSM) in and of itself, but there’s a lot wrong with how it’s thought of and discussed by bloggers, industry marketers, and others, who frequently combine it with DevOps and Agile. It isn’t the same thing at all.
When you’re reading about value stream management, you need to be able to spot false information. Here are five things that are obscuring the truth about VSM—and what you should be paying attention to instead.
“VSM empowers teams to remove waste,” you might hear. Oh, yes? How? Sure, we wish our VSM efforts had a positive impact on the team, but I wouldn’t say they have. Your VSM activities should, as the name implies, empower your team. They shouldn’t disempower your team, at the very least. However, claiming that VSM accomplishes this or that misrepresents VSM and creates ambiguity.
“VSM streamlines the flow of data.” How? VSM is a notion, but automating the availability of information is a positive thing. It doesn’t supply or do anything like a notion.
2. Excess specificity and limited scope for improvements
Some authors are overly precise about the advised improvement, the direction they should take, or the technique they should do. As a result, their perception of the potential for improvement is skewed. “The focus should be on the vital indicators of speed and quality,” or “Speed and quality are essential to profitability,” should be avoided.
These aphorisms may or may not be true. But what happens if they aren’t?
Lead/flow time, flow load, waste reduction, and quality are all essential markers of success for most software teams. But what if the operations that are critical to a company’s profitability aren’t measured in terms of speed and quality?
Predictability, innovation, and cost reduction are perhaps the most important factors to consider. Upper management must be willing to accept some sort of waste if it wants predictability or innovation.
For example, achieving predictability necessitates a certain amount of quality, but speed isn’t the priority. Speed and innovation normally go hand in hand, although quality requirements may differ. Teams may be led astray if they place too much emphasis on standard lean flow metrics.
If speed is a vital issue for your firm, you must accept extra capacity (slack) and/or restrictions on what is permitted into the system. Why? When a system’s load is too great, throughput drops and lead time increases. Firms can ensure a healthy load by limiting what is allowed into the system and pushing back or saying no to requests that exceed a predetermined threshold.
When individuals say they require speed, what they really mean is that they desire high throughput—the completion of a large batch of work in a short amount of time. If high throughput is the driving factor, you’ll need to think about other business goals and build a custom improvement program and VSM methodology.
Too many people attempting to lead the VSM conversation have a restricted (lean, DevOps, or IT-centric) understanding of how a value stream should work. They have a limited understanding of the elements that influence the design and optimization of an organization’s value stream.
3. Conflating working in the business with working on the business
The need to align software development efforts with business results is a recurring phrase I hear. That’s admirable, but it has little to do with VSM. Consider the “efforts” to be epics or stories. Epics and tales are fed into the value stream by-product management.
Business outcomes are things like product enhancements and corrections that are solved by the work that flows via the value stream—things like minimizing shopping cart abandonment, enhancing stickiness or retention, or making recruitment easier. The value stream’s outputs are the business outcomes.
You hope your epics and stories are in line with your company’s goals. They ought to be. You also hope that they bring about the required commercial results. That, however, is a product management issue, not a VSM issue. Only if there was a problem with the product management process would it become a VSM issue.
The process of product management process improvement, particularly the epic selection or story tracking process, must be focused on the process. It shouldn’t be — and can’t be — about the upcoming epics and storylines.
Product features or customer retention could be real business goals (the subject of product management). VSM, on the other hand, is concerned with challenges relating to people or processes that obstruct the capacity to generate those outcomes within the desired parameters.
Time to market, predictability, quality, innovation, and throughput are examples of parameters. Working on the value stream improves those variables.
4. Improve the correct things
This implies your company needs to figure out what’s wrong with its value stream and how to fix it. You might be having problems meeting your obligations to marketing, clients, training, or other teams, for example. They all want to know what’s going to happen next.
If this describes your company, you may need to strengthen your dependency breaking or dependency identification and management processes. It’s possible that you’ll need to increase throughput stability—not necessarily greater throughput, and certainly not throughput with more unpredictability.
Those, on the other hand, aren’t business outcomes. Those are enhancements to the organization. Working in the value stream is required when selecting stories (product management job). Working on the value stream, or VSM is improving the process for selecting those stories.
5. Equating VSM with agile
Some in the industry continue to demonize waterfall and extol agile as if it were VSM or a method for achieving VSM. However, agility isn’t the purpose.
What can businesses do if they already have pockets (or buckets) of a waterfall? Is it true that VSM does not apply to them? Is it true that they are not permitted to enter the club? Please, God, don’t allow it. These scenarios are value streams as well, and they must be handled. In some cases, a waterfall technique is appropriate. Attempting an agile change isn’t always worth the disruption.
A consequence of this is that the Project Management Institute’s lessons are applicable to VSM. Techniques from the project management body of knowledge are appropriate and even advised, to have in your toolbox. This makes it easier to manage both the work that flows through value streams and the work that is done on the value streams themselves.
What you should be talking about
I’m not sure where VSM will go next in the industry or how its definition will evolve over time. At the present, the definitions offered do not appear to be confined to lean, which is a good thing. In their VSM publications and webinars, however, many authors and speakers like to talk about lean, agile, and DevOps.
Here’s something I don’t hear or see discussed or written about nearly as much:
- VSM’s product management may be improved.
- ITSM procedures that have been honed over time as part of VSM Quality assurance or quality engineering best practices
- As part of value stream management, teach software craftsmanship or pair programming.
- Recognizing that effective value stream management may need concepts other than lean and agile, such as Teal organizations, management 3.0 (as outlined in this excellent book), the Product Management Body of Knowledge, autonomy/mastery/purpose, innovation, and empowerment.
Equally important, few actors in the software business discuss the human element and its significance in VSM. They fail to grasp that effective VSM isn’t achieved exclusively through the use of lean, agile, SAFe, DevOps, or a set of tools. It entails human interaction and a wide range of human activities.
See VSM for what it is
This may appear to be a broad approach, but it captures the importance of human interaction in VSM. So, let’s stop trying to sell VSM as something it isn’t. Let’s be clear: it isn’t a specific process, method, framework, or platform, and it doesn’t supply anything on its own.
Do it if you want to preach agile, DevOps, or whatever the next software excellence fad is. Just don’t mix these methods up or mistake them with VSM. Instead, let’s embrace the true nature of VSM, which includes the “necessary messiness” that humans bring to the table, and use it to create better organizations and value streams.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html