The Guardrails During Release and Realization

< During the Planning Event     ToC     Part VII: Topics In Depth – Value Stream Wide >

Release and realization is more than a development or ops endeavor. Customer support, marketing and other non-development parts of the organization are involved.

Work on items that will realize the greatest amount of Business value across the enterprise

Ops and support are areas notorious for being overloaded. This agreement works both ways. It means that groups being supported by ops must recognize that ops will work in the order that creates the most value. It also means that ops must not allow interruptions to their work for things of lesser value.

Development teams need to be prepared to assist in this last step of release and realization. This is much of the focus of DevOps but must extend to other non-development activities.

Collaborate with each other in order to maximize the realization of Business value across the enterprise

Collaboration implies a common goal. Without this clarity different parts of the organization will be working at cross-purposes without realizing it. Again, this is a two-way street, but typically puts more of the onus on those making requests of ops. Collaboration doesn’t just mean to work with each other but to work in a way that works for both sides. The quote at the start of this chapter “Customer collaboration over contract negotiation” is intended to remind us that while the development group is the customer of ops they cannot just throw it over the fence to ops and say “your job is to deploy this.” In the Agile space they need to collaborate with ops. This is the heart of DevOps.

Ensure that all work will be made visible

Development groups must make the work heading to ops and other support groups visible. But these groups must make what they need from development clear as well. In order to work on the most important things in a collaborative way all work must be visible. This means both the value, effort and relative importance of the work coming to ops.  Ops also needs to have transparency to those they serve letting them know when they (ops) are overloaded or having challenges so that they (development)  be prepared for that.

Take the necessary steps to sustain or increase predictability

The last couple of inches, so to speak, is often where significant delays are. These must be considered just as important as delays anywhere else within the value stream.  Downstream teams must inform any upstream groups of the challenges they may be causing. Ops cannot take short cuts. If they do bottlenecks to release will occur and these will impact the entire system.

Keep the work throughout the value stream within capacity

It is not acceptable for development to focus on their workload if it will overload downstream groups. The work that ops has to do must be within their capacity. This can be achieved by improving their efficiency (eliminating waste), by adding capacity, or by having them be loaded less. If this doesn’t happen it will adversely affect development and enter the entire organization into a downward cycle.

Encourage everyone to strive for continuous improvement

Most of the challenges organizations have are when work goes between different groups. Improving this interaction is key. The heart of Agile is learning and improving. This is more so for ops than most anywhere else. Keeping these guardrail agreements go a long way towards this. But it goes beyond them as well. Ops needs to take a proactive attitude with development – guiding them in how they can improve.

< During the Planning Event     ToC     Part VII: Topics In Depth – Value Stream Wide >

 


Note

Two online FLEX courses are now being offered – FLEX for SAFe, and Adopting FLEX (the first course in becoming a FLEX trainer).

If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway.