This post is from the VSM blog and has not been updated since the original publish date.
Why VSM Is an Indispensable Addition to Agile & DevOps
Value Stream Mapping and Management (VSM) is a great opportunity for companies of any size to understand their processes — from planning to release — and from this data place a real value on each phase of the process. With that visibility and ability to measure value, you can make the best use of time, budget allocation, speed releases, and have enough information to predict and plan next steps.
The results of a good and solid VSM practice are: continuous visibility, work becomes easier to prioritize, and time becomes an ally for those who decide to enable their teams to this type of process.
Much like Agile, SAFe, CI/CD and DevOps, VSM is a practice or methodology overlaying the development process. Certain applications enable you to extend your use of Agile and DevOps and by adding VSM capabilities, so you can build value stream maps and conduct value stream management. What I have noticed is that companies aren’t applying VSM practices fully. That means there is still value that is hard to see left hidden behind the scenes.
As a DevOps Coach I have been helping companies enable VSM for their development processes and each one has a different need, a different process. Yet I see a few things in their approach they all have in common — which, if fixed, would let them access that hidden value.
During the VSM enabling process they start to micro-manage. Even strong teams and good managers tend to do this. This goes against the principles of Agile and DevOps, which are about letting the team members have ownership of their tasks. Another thing I’ve noticed is that these customers didn’t have an idea of what or where their bottlenecks or gaps were. Yet despite all this, many were tool shopping and sometimes tools overlapped roles inside their DevOps.
Those three issues reveal that strong VSM, Agile and DevOps have not been established, so workflows and lifecycles are not visible and transparent from end to end. Therefore, the fallback is to try to gain visibility and lead using a more disconnected hands-on approach that ends up being micromanagement. That defeats the purpose of Agile and DevOps by introducing inflexibility for change management and expansion, which means the full potential of Agile and DevOps is not attained.
Micro-managing, not knowing bottlenecks, and throwing more tools at the situation are an indication of incomplete planning and training.
To avoid that, a lot of work must happen behind the scenes when establishing value streams. When VSM is mastered along with Agile and DevOps, it provides the visibility managers need as well as the freedom the team members need. That is why I suggest customers understand the core aspects of VSM that need to be established well in order to avoid the problems I discussed:
During the VSM enabling process you must use good tools to map and define the development phases. Your packages will travel during these phases from planning to release and you need to be able to watch them travel, seeing and monitoring everything that is happening with your packages.
There are only a few solutions in the market that can be used to define these phases and help the creation and management of value streams. Therefore, an enterprise VSM application needs to be capable of integrating with your development tools. That integration needs to support data and orchestration as we’ll see.
This is one of the first major steps on your VSM journey. The continuous result of this flexible integration gives your DevOps teams all the capabilities needed to expand and projects to become more manageable from start to finish.
Through VSM we enable DevOps or Development Teams to have a major orchestration layer. VSM has to be closely focused on your orchestration no matter what type of CI or CD tools you are using (Jenkins, Ansible or Urban Code Deploy). VSM will collect that data in order to understand how long your orchestration takes to deploy a build.
For example, what I like to suggest to our customers is let VSM take some actions with the orchestration and be responsible to trigger from a commit a build and keep following this build until it gets deployed.
As you already see, VSM brings a lot value through Integration and Orchestration, which drive us to the Centralization of Things. Once you have VSM well defined, integrated and included as part of your orchestration, you now have a single place or dashboard where you can see in real time what is happening with your DevOps or Development process. Now, you can track rogue commits, failure builds, inconclusive deploys, unautomated tests and have a very good report for everything.
Finally, the hidden gold is revealed.
As I said in the beginning, VSM will reveal types of data used to enhance, promote and empower your process.
This is a value that is most sought by PM’s, PO’s, Stack Holders etc.
There is also a real value that is defined on the level of DevOps Engineers, Developers, QA’s and Team Leaders.
This is what I call Harmony phase, it is when those two things come together because you have your entire process so well defined that from a developer commit to a PM plan, you will be able to not just understand but manage the entire lifecycle. The data from setting up the entire lifecycle with VSM will help you see connections you might have missed when you didn’t have a complete end-to-end view.
Now that we have covered the importance of Value Stream Mapping and Management from a DevOps perspective, stay tuned as we explore the individual topics of quality, velocity and efficiency at a deeper level in subsequent articles.