DevOps, building on quicksand?

The management decides they want DevOps and Continuous Delivery. It is faster, cheaper and there are less people needed for the same work. So now DevOps and CD are set as goal for the whole company to reach in the near future. So basically engineering practices are being set as strategy, top down.

DevOps is not something that stands on its own. To really benefit from the concept, the underlying dependencies need to be in order. It is not as simple as adding operation engineers in a Scrum team.

But the question remains: is DevOps without fully implementing the underlying aspects like building on quicksand?

It is the job of the business (0) to create a vision and a clear view on the business value that needs to be delivered and which goals need to be achieved. Agile processes (1) will support the definition of the input, the planning and the processes. This input is processed with Agile development practices. Manual Agile testing (3) and test automation testing (4) need to be in order to be able to work iterative. When test automation is in order you could start/include this in your continuous integration (5). The next step can be the automation of your software delivery (6). To fully handle both change (Dev) and run (Ops) DevOps teams are formed (7). (See the list at the end of this article for a more detailed description of each subject.)

Each step however independently delivers value to the whole.

There are (at least) two ways of getting there: DevOps as starting point or DevOps as the goal. You can follow the sequence of the image above or turn things around.

DevOps as the goal

My first instinct said that starting with the basics, and following the described sequence, was the best idea. It is a nice and clear plan which can be drawn in PowerPoint. It is structured and is easily to understand.

The risk lies in the fact that for some people it implies that if you follow the plan you will become agile and have a fully automated delivery pipeline. The only thing you’ll need to do is a selection of the needed tooling and set the company standard. If possible a one size fits all solution. It can be an invitation for management to push these changes into the teams.

But that is not how it works. In order to reach a certain level you need skilled, enthusiastic teams who will solve their problems along the way. Teams who will use their common knowledge and take ownership of the delivery pipeline and all underlying aspects. Not a management who chooses the best tools and frameworks.

DevOps as the starting point

Another way is to start with declaring DevOps and Continuous Delivery as the new way of working. Teams will have to organize their own integration of development and operations. Then they will have to set up their delivery pipeline. But in order to do that they need Continuous Integration. In order to do that they need automatic testing… well, you get the picture (just follow 7 to 1 in the image above). This implementation works as a pull mechanism (which correspondents pretty well with working agile).

For this pull mechanism teams need to learn to think outside the box. The most heard excuse for not doing something is “yeah, in our company that won’t work/is not possible…/Our company is so complex…/With our software we won’t be able to…”.

Here lies the responsibility for the management who “ordered” the transition to DevOps. Telling people to be self-steering is one thing. Helping them with taking up these new responsibilities and backing them up when they make choices is another.

Quicksand

So DevOps and Continuous Delivery without taking care of the underlying aspects one way or the other can truly be like building on quicksand. The risk of situations like automatic deployment of non-tested functionality with no known business value is high. To really benefit for the concept of DevOps the whole chain from input to output needs to be in order.

Because crap which is delivered automatically is still crap. You’ll just get it faster…

A more detailed description of each subject

* This list is non-exhaustive

(0) Business:
Product Vision, Roadmap/ Storymap, Product Backlog, Product Canvas, Product Ownership.

(1) Agile processes:
Sprintbacklog | Quality of Input | Multidisciplinary teams | Scrum | Xp

(2) Agile Development:
Versioning | Automatic builds | Pairing | User Stories

(3) Agile Testing:
Testdata Management | Scenario testing | Specification by example

(4) Automatic Testing:
TDD | | BDD | ATDD | Automate Scenario’s

(5) Continuous Integration:
Self-tested Build Automation | Frequent commits which are build

(6) Continuous Delivery:
Everything is code | Provisioning | Delivery

(7) DevOps:
Automation | Way of Working | Fast Lane | Performance Monitoring as input for the backlog