Value stream management—a practice that helps align software development with business goals—is one of those concepts that is easy to talk about, but is often hard to implement.
After all, you don’t need an MBA to understand why assessing the business impact of software products is important. Virtually anyone who is involved in any way in modern software delivery can appreciate what businesses stand to gain by ensuring that the features they build actually lead to a better customer experience, as opposed to features that cost time and money to create, but don’t have a positive business impact.
But achieving this alignment between development activity and business outcomes is challenging, not least because it requires a variety of stakeholders—developers, IT ops engineers, business managers, and even marketers and salespeople—to get on the same page with regard to value stream management. That’s no small feat, given that most of these teams don’t typically speak the same language or interact closely with each other.
What can businesses do to square the circle of value stream management? How can they buy-in for the principles and practices of VSM from across the organization? Read on for four tips on making VSM a collective, business-wide effort.
1. Define Value Stream Management in a Way Everyone Can Understand
Although the idea at the core of value stream management—that software development should support business goals—is easy enough to understand, it can be hard for people who don’t have hands-on experience with the software development process to digest the concept.
Developers, IT engineers, and DevOps teams know what modern software development looks like. They know that there is an endless list of features that they could implement, and that it can be challenging to determine which features will have the greatest positive impact on customers.
But managers, salespeople, marketers, customer relations specialists, and other non-technical members of the organization don’t necessarily have visibility into the software delivery process. By extension, they may not fully understand the problem that VSM is supposed to solve. They may assume that software delivery teams have more insight into customer needs than they actually do, or fail to appreciate just how much pressure developers face today to plan and deliver features continuously.
Toward that end, a basic step toward achieving buy-in for VSM from across the organization is to define VSM in a way that everyone—not just technical stakeholders—can understand and appreciate. Avoid jargony terms like “continuous delivery” or “feature mapping.” Stick with easy-to-interpret definitions, such as “value stream mapping is the alignment of software functionality with business goals.”
2. Identify the Stakeholders in Value Stream Management
Another basic step toward achieving organization-wide support for value stream management is determining who, exactly, plays a role in VSM success.
Some stakeholders are obvious. You know that developers, IT engineers, and managers have a role to play in the process.
However, as noted above, people in roles like sales, marketing, and customer relations should also typically be plugged in to value stream management. Even though these groups don’t typically play a role in software development, they understand customer needs in ways that technical teams don’t. If you want your software to benefit customers, you’ll need help from the people who understand your customers best.
3. Define VSM Metrics That Everyone Can Understand
The best metrics for measuring the impact of value stream management are metrics that everyone can interpret—and that reflect the role played by all teams, technical and non-technical alike.
Don’t measure only technical data, like how many customer feature requests developers implement each month. Likewise, don’t measure only business-centric data, like the revenue generated per new feature. Instead, choose VSM metrics that reflect both technical activities and business impact, such as the revenue generated by each customer-requested feature implementation.
Holistic VSM metrics like these help highlight the role played by all stakeholders in the VSM process, ensuring that all teams feel included and that their efforts are measured and quantified.
4. Build a “Blameless” VSM Culture
Developers and IT engineers may be familiar with the concept of “blameless” culture, a concept that is sometimes used to help teams sort through technical issues without holding any one person or team responsible for failures.
The blameless technique can be extended into value stream management. In this context, a blameless culture means one in which VSM mistakes—such as the implementation of features that turn out not to have a positive business impact—are owned collectively by the organization instead of being blamed on specific people.
A blameless value stream management culture encourages transparency and openness. It also helps teams to experiment and take the bold steps necessary to deliver truly innovative products, rather than merely meeting a minimum threshold for customer satisfaction.
Conclusion: VSM Success Is Organizational Success
Not every employee or team plays an equal role in value stream mapping. Some aspects of the process need to be owned by the specific stakeholders who have the expertise and perspective necessary to fulfill them.
Nonetheless, VSM should ultimately be an organization-wide effort. By taking steps to involve all relevant stakeholders in VSM processes, tracing metrics that reflect their collective efforts, and embracing the concept of blameless VSM culture, businesses can maximize their transparency, agility, and ability to align technical activities with customer value.
Watch executives and other practitioners discuss how they pioneered value stream management at their organizations in our VSM Summit on Demand, or learn more about ValueOps from Broadcom, the software that makes it happen.
