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:
If we come back to the idea of direct or indirect value streams, two interesting points arise:
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.
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:
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.
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:
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.
We group the benefits into 3 main categories, they are as follows.
The above listed benefits of VSM are tempting. But, there are some drawbacks to value stream mapping that need attention first:
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.