Value Stream Management (VSM) began on production lines in the 20th century, with manufacturers using multiple, small increases in efficiency to reduce costs, tackle common problems, and increase profits. That increasing efficiency resulted from examining the processes involved in creating the product or service, figuring out the steps involved in each process, and then determining how to maximize the value of each step and each process.
These steps are known as a value stream. Examining a process in terms of its value to the organization—and value can have many meanings—allows a more holistic understanding of the process. VSM brings clarity and gives organizations the ability to improve the time to value at every stage of the process.
The application of VSM principles to DevOps has taken hold in the last few years, and is seeing widespread adoption across the software development world. But what does it mean, in practice, to use VSM in a DevOps process? How are developers applying these principles in the field doing so, and what benefits and challenges are they facing?
We spoke to Harbinder Kang, Global Head of Developer Operations at Finastra, about his experiences using VSM, He offered some clear insights into the process of implementing VSM and what it can achieve.
Using Value Stream Maps
“Value Stream Maps allow us to take a step back, forget the technology, the process, and the people for a second, and just map out what’s going on and discover what the set of constraints are that are actually affecting us, rather than anecdotally what we feel may be the case,” Harbinder says.
This discovery helps organizations understand where waste exists in the environment, and as Harbinder notes, “it may not necessarily be where stakeholders ask you to focus.”
Harbinder continues: “Creating a Value Stream Map also breaks a siloed approach to thinking because, by necessity, you are going to different stakeholders across the value stream and getting different versions of the value stream. You then put it all together into a consistent view,” he explains. “From there we get into, ‘This is where we are, what do we want to do?’”
Here’s what Harbinder and his team consider:
- Is this long-lived software? In these cases, we look to optimize margins and profitability and productivity, as there is no goal to change the software architecture investment. We are optimizing and the technical debt isn’t going to change.
- Or is it a new project? In these cases, the organization has aspirations for growth and wants Internet scale. We look to bring in ideation, continuous delivery, and aim to have the system available at all times.
- In the middle, you’ve got products that have been successful in one model, typically software that was sold in a licensing situation, and the client has an aspiration of moving it across into a managed service and that’s a really interesting challenge at that point.
“I’ve found using the VSM framework allows me to attack all three of these problems,” Harbinder says.
Setting Expectations for Everyone
For Harbinder, using VSM not only helps him work with his stakeholders to set expectations, it gives him insight into the mindset of those stakeholders, and allows him to be ready for the challenges and limitations of a project.
“In DevOps, there’s a set of constraints you need to be aware of, within what you need to do, and it’s not always in your hands in terms of the outcomes the business wants. For example, you can throw all the DevOps tooling and automation at a product, but if it’s a very lumpy, heavily customized product, there’s only so far you’re going to get in operational performance if you’re not looking at the cost of ownership: It may not be a profitable model. It’s a very nuanced conversation.”
Conclusion
Harbinder is using VSM to create conversations, clarify his team’s goals and parameters, and build understanding with his stakeholders. This dialogue, resulting from the value stream mapping his company undertook, helps to set expectations and increase the chances of a successful project, as it defines the scope and scale of the project before work begins and encourages constant evaluation of development throughout the project.
As Harbinder says: “The Value Stream is a great way to talk to the business—it takes the jargon out of the conversation, it doesn’t require you to understand the technicalities, it lets you have a very balanced conversation that is very easy to understand.”
