Value Stream Management or VSM is garnering a lot of attention these days, especially in the IT world. Many people that I have spoken to are asking if this is just “another new fad” in IT. In this blog post, I want to share my personal view on VSM and why it matters to software delivery.
What is Value Stream Management or VSM?
VSM is an approach for organizational transformation.
In contrast with many other organizational transformation approaches, VSM has a relentless focus on the customer and the flow of work across the organization to deliver the value, which is what the customer expects when they approached the organization in the first place.
If we can imagine that a business or organization as a black box that takes a request from the customer at one end and delivers the service or product at the other end, VSM is about evaluating the high-level components within that black box, the flow that request takes through those components, resulting in the delivery of the service or the product at the other end to the customer.
Using a technique called Value Stream Mapping, an organization maps out the flow of work across the value stream. Value stream maps use notations that represent the various types of activities, systems and information flows. In addition, specific measures are taken to uncover how much time is spent in an activity, outside of the activity waiting, the quality of the deliverable of that activity, the availability and more.
The key point here is that VSM is about visibility, and what better way to show visibility than through a diagrammatic representation of the flow?
The diagram below shows an example of a Value Stream Map.
With the Value Stream Map, businesses and organizations can now see where the potential issues are and start to uncover the root cause(s) to poor performance and more importantly, where and how to transform and improve.
VSM is not a new methodology. For a long time, it was mainly used in the manufacturing domain where the value stream is typically on the manufacturing floor of a plant.
Organizational transformation gurus like Karen Martin and Mike Osterling in the early part of 2010’s propelled VSM and the practice of Value Stream Mapping into the office and services industry with their highly successful book “Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation”.
It showed the world that VSM was not only applicable in the manufacturing of physical goods but also in the office environment, because value is what a customer seeks from an organization and all organizations have a system to deliver that value – whether that is on a manufacturing floor of a plant or the multiple departments in an office.
Organizational performance is tied to how well that system (or value stream) works to deliver the products and/or services that either results in losing the customer for good, or having customers returning for more.
How can VSM be used in Software Delivery?
Most of us have heard of the phrase “software is eating the world” and it is mostly referred to in the context of today’s business environment, and how every business needs software, because technology has permeated almost all facets of our lives.
This has led to businesses increasingly being focused on innovations on the digital front – either via the rollout of online services that increase customer engagement or backend services that optimize the supply-chain or analytics that provide the business with real-time information for quick decision-making.
In many situations, the only difference between the victor and the loser is how quickly the business can adapt to changes, and its ability to rollout software changes quicker and in higher quality than its competitors.
Underpinning this ability to adapt, are the practices of Agile and DevOps that has seen growing adoption since the early 2000’s.
This approach has led to the formation of cross-functional teams within IT that are built and focused on products that IT delivers to its customers, which in most cases, is the business. These ‘product’ teams now manage work from request to delivery and the operations of those products in Production.
If we relate this to VSM, we can draw direct comparisons between each product team and a value stream.
This is of course, a very simplistic view because as we know, there will be interdependencies between multiple product teams. It is quite rare to find products within IT that can exist solely on its own.
It is more likely to find a Product/Service (let’s call it Product/Service A) will require some features and functionalities of Product/Service B which itself may have some interdependencies on Product/Service C.
Depending on the type of request coming from the business (or the customer), the flow of work, can either be fulfilled by a single team, or multiple teams.
The point here is that to do VSM effectively in Software Delivery, being able to look at the value stream at different levels of granularity and different types of requests being made to IT is extremely important.
How to optimize Software Delivery with VSM?
As mentioned earlier, VSM works because it brings into visibility the metrics such as amount of time, effort, rework between the handoffs from one activity to the next.
In the original VSM in the manufacturing world, these metrics are captured by doing the “Gemba Walk” which is physically going onto the factory floor to observe and measure every step of the activities that make up the value stream.
In the world of software delivery, it might not make sense to do the “Gemba Walk”. In fact, things might be simpler.
Software delivery teams today use a myriad of tools to deliver their work.
For example, for planning and tracking, teams use project planning and tracking tools like Atlassian JIRA or Broadcom Rally amongst many others. To manage parallel development, teams use Source Configuration Management (SCM) tools like Git or the enterprise versions of it like GitHub or Bitbucket. For testing, teams use Test Management and automated testing tools to execute tests, manage defects.
Each one of these tools essentially, is a system of record of the work flowing across the software delivery value stream. So instead of doing a physical “Gemba Walk”, we can achieve the same objective by getting the data from the tools.
The only issue… Each tool only has records of the activities where those tools are used.
This means disjointed data sitting in various repositories across the value stream.
What is needed for end-to-end visibility is a capability to pull together all the disparate pieces of information from across these tools, into a single, end-to-end view that ultimately relates back to the original request from the customer.
For example, here is a screenshot from HCL Accelerate, a VSM solution for software delivery.
On this view, each dot represents a request from the customer. The colour of the dots represent different priorities or it could represent different types of request.
The dots are “pulled in” from different tools like ServiceNOW, JIRA, TFS, HCL Compass amongst others and they flow from left to right across the different bubbles and columns that represent the various process steps or activities in the value stream.
As the dot progresses across the value stream, a VSM tool like HCL Accelerate “accumulates” data from the other tools such as Code repositories like Github, Bitbucket, HCL VersionVault and these are linked back to the actual request from the customer.
Here is a view of a request (a technical issue) that has made it all the way from Backlog to Production.
As evident in the image above, the VSM solution automatically stitches together the different pieces of disparate data from the disparate tools into a single, end-to-end flow of that request, at each stage capturing the details such as time spent in the process step or activity.
Because HCL Accelerate can also work with security scanning and testing tools, it can also pull in related data on code quality and security.
While it is good to get end-to-end visibility on a single work item like the above, what is more valuable is the ability to observe and analyse the hundreds or thousands of requests flowing across the value stream in order to generate insights into the flow as well as trends for continuous improvement.
And here below are some examples of these metrics and insights.
If a business can identify the opportunity cost that is lost by a single day of delay of a particular request, the ability to compare lead time (time from ideation to production) against cycle time (time from code commit to production) provided by VSM tools like HCL Accelerate can easily highlight the cost of leaving a high priority item in the queue.
By being able to observe the number of planned vs. unplanned work in an activity in the value stream, and how the unplanned work is the cause of the delay (for example, creating too much Work in Process or WIP), IT can communicate back to the business the reasons why work needs to be planned.
The idea here is that visibility provided by VSM can serve as an avenue for improvements based on facts and eliminates blame game. The focus is also on the optimization of the flow and not a step in the flow.
In this article, we explored the methodology or technique of VSM, a proven approach for organizational transformation. While VSM originated from the world of manufacturing, it is equally powerful and effective in today’s world driven by software. While the techniques may be the similar, applying VSM in software delivery could mean approaching some activities differently. For example, instead of capturing metrics via the Gemba Walk, VSM in software delivery must capture the metrics from the tools that software delivery teams use.
HCL Accelerate is a VSM solution from HCLSoftware that is built from the ground up for just such a requirement.