Disciplined Agile

The Guardrails During Release and Realization

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

Promise: Create psychological safety

Psychological safety is very important before and during release. If something is not right it is important for people to feel safe to speak up.

Promise: Accelerate value realization

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.

Promise: Collaborate proactively

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.

Promise: Make all work and workflow 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.

Promise: 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.

Promise: Keep workloads 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.

Promise: Improve Continuously

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.