Rawpixel.com - stock.adobe.com
The current state of the economy demands that organizations better align DevOps with business goals and customer requirements, putting greater cost pressures on DevOps practices than ever.
As enterprises enter ever-tightening budget cycles, bringing together DevOps and value stream management (VSM) offers development projects a new management and reporting layer to resolve issues. Even cherry-picking some VSM best practices to close gaps in your current DevOps practices can lower costs and improve efficiency.
Understanding the relationship between VSM and DevOps
VSM is a software development approach that can augment traditional DevOps practices by optimizing the end-to-end software delivery process. Potential benefits of VSM include identifying and eliminating waste, reducing lead time for new features, and improving the value flow to customers.
VSM has a lot of potential for organizations with DevOps practices already in place. Like DevOps, VSM aims to bring together people, processes and technologies to visualize and manage the software delivery pipeline and support continuous improvement. And even if you don't want to adopt a full-on VSM framework, you can still learn from VSM practices to improve your DevOps workflows.
Mapping out DevOps value streams
DevOps and business teams must collaborate when identifying value streams in the software delivery lifecycle.
The first step is to map the organization's entire DevOps process, from planning through delivery. You might already have such documentation on hand. Otherwise, start with a visual collaboration tool such as Miro or Mural to do this initial, essential work.
You don't want to create this map in a silo. Factor in the time for collaboration and iteration -- and the possibility that your DevOps process might not work as documented. If so, consider whether any areas need renewed consideration to realign with your organization's intended goals.
A value stream map should identify the various stages of your organization's DevOps process, such as the following:
- Deliverables and exit criteria.
- Handoffs between teams.
Today's CI/CD toolchains hold volumes of data about an organization's development projects, including lead time, cycle time and throughput. Once everyone involved analyzes and agrees on this data, move to VSM tools such as CloudBees Flow and Plutora for more detailed analysis work.
Analyzing pipeline data can identify process inefficiencies. This information arms your IT and business teams with actionable data for meaningful engagement and delivers on the promise of data-driven DevOps.
Engaging with stakeholders is just as crucial in VSM as in DevOps. Pipeline data produces valuable insights, but you still must interact with your customers, internal stakeholders and developers on a regular basis.
In these conversations, identify areas where your DevOps efforts are delivering value and where they're falling short. Bringing your analysis of pipeline data to stakeholder conversations sets up your teams to prioritize the most needed improvements and deliver value to your end customers.
Positive effects of VSM on DevOps practices
VSM can bring transparency and visibility into the data that the tools across your DevOps pipeline generate daily. With the new level of visualization that VSM offers, your DevOps teams can better identify inefficiencies and bottlenecks.
VSM also brings the positive effects of improved collaboration and communications to DevOps practices. Implementing VSM with a collaborative plan enables teams to identify and remediate issues earlier in the DevOps process because of improved tooling and data reporting.
There's always room for continuous improvement with VSM tools and data, helping knock down any last silos you might have. For example, if you have a remaining silo between DevOps and compliance teams, VSM can pinpoint new learning areas that might have remained hidden in a traditional DevOps model.
Potential drawbacks of VSM in DevOps
Some argue that VSM is stuck in the past because the approach fails to address the nature of modern software development -- specifically, that products are often large and unfocused, and thus require a large and unfocused organization to deliver them. There's undoubtedly some truth here, and it doesn't help if executives can't shake legacy Six Sigma processes that are no longer relevant.
Anticipate potential problems when adopting VSM
When planning a move to VSM, avoid an overly prescriptive command-and-control approach. When an internal organization outside IT pushes to implement VSM without the input and buy-in of DevOps teams, it can hinder the progress of the organization's DevOps journey. Implementing VSM as a rigid process increases dependence on one team and impedes the DevOps team's ability to experiment and innovate.
Putting metrics over collaboration is another warning sign. VSM isn't only about tracking development project metrics; it's also important to foster better collaboration between IT and the business using engagement and metrics. Overdependence on metrics can put developers in an unfair position, forcing them to explain why they couldn't meet metrics arbitrarily set by individuals not perceived as contributing to the project.