In-Depth Analysis Of Software Value Stream Mapping
In the previous article we saw the foundations of the value stream for software engineering organizations. In this article we first focus on how to measure value streams. Then we look at benefits and drawbacks that value stream mapping (VSM) has. Finally, we analyze how they run parallel to the software delivery pipeline.
The importance of value streams is clear. They identify opportunities to streamline your software delivery pipeline. In case you haven’t read our previous article, here are some key takeaways:
- The definition of a value stream is all the activities or processes used to deliver value to the end customer. They deliver value to the end-user in two ways. Either directly or supporting other internal processes that deliver the value.
- Value stream mapping analyzes, designs and manages the flow of information and resources needed to deliver value.
If we come back to the idea of direct or indirect value streams, two interesting points arise:
- How are they actually measured?
- How do many value chains coexist inside a software development organization?
How is value created?
To understand how to measure value streams, we first need to look at how to create value in a software engineering organization. Many streams might arise leading to a monetization.
Let’s take Company X as an example.
Company X sells software to other companies for a fee. This is the first value creation; for both Company X and its customers. While Company X gets revenue, the customers get the benefit that the product is made for.
At the same time, Company X also offers customer support. This is also a value stream. Customers communicate issues. These then get solved by Company X. When releasing the solved issues, the Company X and the customer get value.
Finally, Company X also has an internal project to optimize how they work. They are currently restructuring their departments and workflows. This is another value stream. It gets their product to customers faster (e.g. through updates and bug fixes) by reducing lead time.
And to just touch a few, we can already say that there are many values streams in any company.
Multiple value streams within a software engineering organization
As we saw, there might be multiple value streams within a single software company at the same time. To put the previous example into a simpler context.
The engineering-oriented value stream would be: deploy good quality code at a faster rate to the end user by generating minimum waste.
The business-oriented value stream would be: grow the scope of the organization by converting potential customers into clients with the value being created.
This brings forward the concept of how to categorize value streams. There are two main categories which are both linked with one another:
- Operational value streams: Are people and processes that deliver value to end users. They use features, systems and infrastructure created by the development value stream. Basically, operational value streams are how the software engineering organization makes its revenue.
- Development value streams: Are people and processes that develop proposals or features. They develop new offerings, systems and infrastructure. Things which the operational value stream needs to deliver value to the end-user.
When combined these 2 value streams serve a single purpose. They help software engineering organizations to achieve targeted business outcomes by delivering value. But, their interconnectedness makes their interpretation complex and tedious. It is easy to miss out who is actually affected, what the impact is of a change on the value stream and how to optimize the value delivery.
How are value streams measured?
Focusing on software engineering organizations:
Each value stream should define criteria to measure the value/success it generates. This will allow you to adapt the ongoing investment of engineers and tools. We define these criteria as Key Performance Indicators (KPIs).
Each individual value stream will have a set of KPIs. These depend on the type of value stream at hand. Some examples:
- A product value stream could use KPIs such as: units sold, current market share or customer satisfaction.
- A software development value stream could use KPIs like: average feature lead time, release frequency, total code churn.
- The customer service value stream would have KPIs such as: mean time to resolve the request or time to respond to a request.
This highlights the complexity of value streams and the necessity to map them. But, software engineering organizations don’t only benefit from mapping. There are some common pitfalls that need attention to stop them from becoming a drawback for your organization. We look at them in the following section.
Benefits of value stream mapping (VSM)
We group the benefits into 3 main categories, they are as follows.
- Team stability: Instead of focusing on task completion, the team focuses on value creation. This makes a happier and more productive team, while making engineering more purposeful.
- Understanding: Your team will improve the communication, collaboration and culture with conscience. VSM also allows for faster learning due to the increased transparency in the process. Furthermore, teams disregard any personal opinions. This prioritizes processes based on the customer’s value perception.
- Lean development: VSM supports lean development by eliminating and discovering the root cause of waste. This is because you can see where bottlenecks arise in your software delivery pipeline. Allowing you to tackle them actively and resolve the problem. This streamlines the software delivery pipeline and reduces lead time.
Drawbacks of value stream mapping
The above listed benefits of VSM are tempting. But, there are some drawbacks to value stream mapping that need attention first:
- Effort: Value Stream Mapping can be complex. It takes time and effort to find the core processes of your engineering organization. And so, a balancing the reward-effort is important.
- Delayed ROI: VSM doesn’t translate into the direct improvement of your value stream. By changing a process at a time you will reduce waste, but this doesn’t mean that you will be optimizing the bottom line. You will need time, effort and discipline to unlock the benefits of VSM.
- Requirements: Needs action among the many departments in your software organization. If not, a skewed view of only one value stream will remain, when there might be many.
How Athenian can help you
When combined, the operational and development value stream of a software engineering organization run parallel to the software delivery pipeline. This is crucial to understand. A real-life example will make this idea easy to follow.
During our conversation with Paul Poppert, Head of Engineering at Faire, he told us that Athenian helps optimize the operations at Faire in many ways. One of them: to better understand the whole software delivery pipeline by tracking a software idea from concept to launch.
He says that with our software delivery dashboard he can properly map the value stream, which he argues: “is the key to empowering an engineering leader to make better decisions.”
One of those better decisions was to improve the review process by adding a second review phase. By having Athenian’s insight into these metrics, he concluded that the slight increase in review time ends up benefiting the value stream as well as other areas of shipping code.
The bottom line: With Athenian you have the tools to continuously and consciously optimize your value streams when optimizing the flow of your software delivery pipeline.
