In the introduction to this series, we discussed the concept of change and how it applies to DevOps environments and release managers. 

In a world of constant changes in our surroundings and user demands, DevOps has to maintain hundreds of moving pieces across large organizations of people who, by nature, are adverse to change. This requires release managers to delegate power, transition from a centralized commander to an enabler, understand different value streams and constantly experiment. 

In this section, we’ll cover some of the ways and types of experiments DevOps organizations can conduct to improve their release management procedures and meet their objectives using DevOps principles.

Value Stream Mapping

Value stream mapping is a series of steps used by organizations to provide products or services their customers want or need. In the traditional sense, the release and deployment process can seem tedious, especially if teams must communicate with a release management team to schedule release slots on a calendar.

Despite its advantages, value stream mapping has a few drawbacks. It requires a lot of people and it can be difficult to coordinate and sparsely repeated.  

Value stream management platforms can extract the four key DevOps metrics for teams to inspect and adjust in real-time. However, there are some shortcomings with using the four metrics:

• Lead time is characterized as time from code commit to live; however, in value stream management, we also consider the time it takes for an idea or customer request to reach value realization.
• Deployment frequency becomes interesting when teams deploy sporadically but are still improving, but when teams attain the ability to release on demand, other metrics become more helpful.

As a result, teams must alter metrics over time to match team ability. This is why it’s critical to empower value stream teams to discover and measure their own metrics. Another factor is that people are more likely to change when doing it for themselves rather than having it done to them.

Lessen Batch Size

Reduced batch size lowers risk and reduces the time an activity waits in a queue. When changes are minimal, they may be implemented quickly and with less danger of causing disruption, thereby making the distinction between the phases less significant.

While some key metrics may be accessed through specific tools such as backlog or release automation, without a value stream management platform, it’s more difficult to gain insights into overall queueing time.

The value stream map is automated when all aspects of the DevOps toolchain are combined, resulting in a unified system from idea through the realization that allows teams to understand their cycle time and value flow efficiency and observe how changes improve work.

Evolving Architecture From Monolith to Microservices

Most organizations have monolithic, tightly coupled applications because that was the best software design approach available in the past. However, as the industry evolves, release managers become increasingly conscious of the limitations of this architectural approach:

• Large batches of work are required to build, test and deploy.
• Dependencies must be managed, including people and systems.
• Dependencies cause fragility.
• Fragility causes bureaucracy (e.g., CABs).
• Bureaucracy and handoffs hinder flow.

Rearchitecting applications to microservices, like changing human behaviors in a system, does not happen overnight, and there are frequent bottlenecks along the way. This is often a “change or die” conversation. If the application does not become more capable of change, market disruptors will provide new experiences to consumers, and customers will jump ship for these competitors.

A value stream management platform can reveal where restrictions, delays, and dependencies occur and how they might be reduced. As a tenet of DevOps says, “Don’t manage dependencies; break them.”

For many companies, however, the road to systemic autonomy, or loosely coupled systems, is lengthy with many incremental steps of improvement. This method is recommended by the strangler pattern: chipping away at the monolith one bit of functionality at a time.

During the application architecture change, we need to support value stream teams, so they don’t waste time on unexpected work caused by unknown dependencies. We also need them to see and appreciate the improvements they’ve made with the support of a value stream management platform.

Part of the release manager’s job is to identify value stream success stories and share them with the other value streams so that local improvements can become global ones.

Transfer the Release Management Role to the Value Stream Team

When teams work independently on small changes, they can release them as soon as they are ready. However, moving from one state to another takes time to transition to that stage of the journey.

In a traditional method of working, the release process is likely to be coordinated by a release manager or a team of release managers. The release manager role can be transferred to the value stream team, with the team providing access to systems that provide visibility into current releases to the release manager.

Transparency into operations across value streams provides traditional release managers with great comfort during this transition, relieving them of the administrative strain. It allows individuals to learn new skills and refine the meaning and purpose they derive from their work.

By taking an end-to-end and cross-value stream approach to change and improvement and ensuring blame becomes accountability, release managers can be key to the success of these improvements. Platforms for value stream management give the data needed to support the conversations that will lead to this cultural and behavioral shift.

In this series’s third and final part, we will cover more types of experiments and DevOps best practices for achieving change and driving results.