One problem that many managers, engineering leadership, and even engineers themselves have are figuring out how to measure engineering value. It's not like in sales where there are numbers and KPI's to give you an idea about if you're on track or not. With a CICD pipeline, there is no measurement of value. You can't measure how many times it passed or failed because those numbers have nothing to do with providing value.
The best way that everyone on an engineering team, including management/leadership, can see the value gained is by using Value Stream Management (VSM).
In this blog post, you'll learn what VSM is, why it's important, and a few tools to take a look at.
What is VSM
Let's think of a few things that engineers do (this is by all means not an exhaustive list. I'm just using these as an example):
- Work on tickets via some Kanban board like Jira
- Run CICD pipelines
- Commit and push code to source control repositories
- Lots of troubleshooting
Here's the problem with the list above - there's really no way to measure value in any of those. For example, you can't track how many tickets an engineer completes in Jira and say that they're providing more value than other engineers because a lot of factors go into tickets; one ticket may be harder than another, someone may be new to the team or new to engineering, and it becomes very micro-manager-ish.
More importantly, showing how many tickets someone worked on, how many code pushes someone did, or how many CICD pipelines were run doesn't show technical business value. It doesn't show the CTO or the CIO how an application is coming along. They just see green checkmarks for passed pipelines or red X's for failed pipelines, which is way too black and white, meaning, there isn't enough data by looking at stuff like that.
Value Stream Management (VSM) aims to fix that issue in several different ways, but how?
In today's technologically-driven world, management and leadership care more about software innovation and delivery than ever before. It's at the top of most of their priority lists because quite frankly, software is the primary reason almost all businesses are able to stay in business today. Because of that, management and leadership teams want to see the value provided by the team, just like they want to see sales numbers from the sales team.
VSM, by definition, is a business practice that helps management and leadership teams determine the value of software development and CICD efforts for the organization. The way that they can determine that value is by using VSM platforms and software (more on that later).
Why is VSM Important
Engineering leadership and management have been micro-managers for years. Assuming that they all don't enjoy it (and I really hope they don't), there's a reason for them being that way. That reason is because it's ridiculously hard to measure value in say, someone testing and troubleshooting one CICD pipeline. For example, an engineer could spend the entire day working on a pipeline. Troubleshooting dependencies that are missing in some Python code, figuring out why builds aren't passing, working with development teams to troubleshoot, spinning up and spinning down test environments, writing and pushing code, all for one pipeline. When a manager who isn't technical or forgot that engineering takes time may look at this and say how is it possible that it's taking this long? I thought these pipelines were supposed to make us go faster and be more agile (insert more buzz words here).
If someone, for example, had a VSM tool, they could see what was happening:
- How many code pushes were done for the dependencies in the Python code
- The pipeline analytics
- The tickets being worked on, how long they took, and what was done
The ability to see the analytics of the work vs just seeing one pipeline being worked on for 8 hours at a 50 ft view is critically different.
VSM Products
Below are a list of VSM products that you can take a look at it to get started on your journey.
Top comments (0)