Customer collaboration over contract negotiation
SAFe does a pretty good job with DevOps, or at least highlighting the need for it. Given there is much already written about DevOps we’re not going to go into that much here. The thing to keep in mind, however, is that there is no value until it is realized. Release and realization are just as important a part of product and service development as software development is.
This is another aspect that must be included in MBIs – what will it take to release and realize value for a work being developed. This means that up-front we need to attend to this issue. This alone can stop a lot of problems in ops.
There are four general areas of ops to attend to:
These two aspects are intimately tied together and is where the guardrails are quite useful:
Let’s go through each of these and see how they relate to ops, marketing and support.
Realize the Greatest Amount of Business Value
Ops and support are areas notorious for being overloaded. This agreement works both ways. It means that groups being supported by op 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.
Collaborate With Each Other
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 all work is visible
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.
Sustain or increase predictability
Ops cannot take short cuts. If they do bottlenecks to release will occur and these will impact the entire system.
Keep work within capacity
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.
Strive for continuous improvement
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.
Working With Development
Keeping the guardrail agreements listed above will 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.
Include all aspects required for value realization
This is one area where MBIs are so important. Right up front we look to see what it will take for value realization for something being built. This includes ops, marketing, support and whatever else is needed.
Enabling Continuous Integration and Deployment
Without the ability to do CICD ops becomes a bottleneck of sorts. This is another area that ops can help dev (again DevOps) in that developers often need advanced environments to get their work done.