Get out of the way

A basic principle of DevOps is for "Necessary Non-Value Work" to get out of the way of Value Work.
© Copyright canstockphoto.com

In the Require-to-Deploy value stream, this NNVW includes

  • security
  • architecture
  • project management
  • finance
  • testing
  • compliance
  • and of course change management

One of the primary ways to get out of the way is to

parallelise

(Is that even a word?) and/or incrementally iterate.

I saw an excellent example recently, where the Solutions Architect goes away for a multi-week design process, to create a Solution Architecture Document (SAD, ironic right?) which is brought down from the mountain to the development team to direct their design.

Instead the architecture will be developed in parallel with the Agile development, in interactive sessions with the build team. The first version of the Solutuon Architecture Document exists only as a photo of a whiteboard. The second version is bullet points. The third version is a document in draft. The SAD is not finished until the as-built documentation.

As another example, the security group are considering how security architecture and security review can be done in a similar parallel iterative fashion, instead of as single steps in series causing the entire value chain to wait.

Performance testing and tuning is another area which potentially can happen collaboratively in parallel instead of as a stage in series causing significant delay.

As well as parallelising process there are other ways we can

optimise controls

to get out of the way.

We can do this in several ways

  • eliminate them
  • shift them left: get someone further up the workflow doing them, and trust them to do it
  • reduce the level of ceremony
  • automate them: embed them in the workflow as self-service or fully automated steps
  • accept that they have to be there

More here.

If you aren't directly delivering value, your goal must always be to get out of the way of those who do.

Two final thoughts:

Getting those who own controls to modify them relies on reassurance, and reassurance only works with trust. That takes time and usually requires demonstrable success. So be patient and prove the changes.

Ultimately, changing the controls and governance is not a side issue to DevOps. It leads to changing the operating model of the organisation (product not project, incremental funding, new capex/opex models, integrated IT...), and it doesn't get any more profound than that.

Syndicate content