DevOps: Get better by practice, not by accident

Posted on: November 22, 2016 by

‘The more I practice, the luckier I get’* is a well-worn quote, but it’s well-worn for a reason. Chatting to one of the speakers at a conference recently, I was surprised to hear of the frequency they undertook a practice that they found hugely beneficial. Coming from the construction industry, the practice was essentially an Agile Sprint planning session whereby they would go through what they were trying to achieve, but the crux was to ensure that everybody was involved. By ensuring all the specialists were in the room, they could iron out any issues caused by assumptions and imperfect information, whilst also understanding why so they could gain empathy within the team and consider how they all delivered to make it as smooth and efficient as possible.

As she waxed lyrical about what a game changer it was I asked her how frequently the meetings were held, the reply: “Once every 6-9 months.” I followed up with the question, “How efficient are these meetings? To which the reply was, “Oh they are terrible, it takes us half a day to cover what should take an hour, they keep going off down rabbit holes.” I found this no surprise.

Frequency is a hard thing to get right. At worst people don’t turn up or at best just get frustrated and moan they are wasting too much time in meetings. When I said that we undertake a similar activity on Software product developments, only teams meet daily and then in more detail every fortnight her mouth dropped open. Once I explained how with practice a team gets their daily stand up down to 10-20 minutes, realising what is important to get across, she quickly saw why the frequency isn’t a problem.

DevOps has brought about a similar paradox around deployment risk. Conventional wisdom states that change is risky and thus the more frequently you introduce change, the more risky your activity. If we look back at the opening quote then we can see that this isn’t necessarily the case. In general, humans get better with repetition**, however it is the frequency of that repetition that is critical; little and often is better than the same amount delivered at less frequent intervals.

To use a sporting analogy, I would be better running 10 miles per day for 7 days than I would running 70 miles in one session and then spending a week to get over it. The same applies to software releases (see the ferry vs the bridge analogy here. If I am to release software updates several times a day or several times per week, then I need to get good at it and put structures in place to enable me to do it effectively – automated build, test and deployment, practices around what to do when something goes wrong, monitoring and how we resolve issues, and if going all the way then also proactively addressing issues through the introduction of stress to the system. Not only does this help us make our software more Anti-Fragile, but it enables us to exploit the most valuable characteristic of what we produce – the malleability of software.

This is how we use DevOps to delight our clients and their customers… but don’t be fooled it can happen overnight. Much like learning a new skill and using the skills within the group of people to create a winning team, it takes regular practice, a shared target outcome, empathy and true collaboration. So get in the habit, expect some teething issues, but believe the journey is worth it – the sooner one starts, the sooner mastery can occur.

* Attributed to Jerry Barber, but could go back to Confucius; read more here

** Repetition has it’s issues – repetition of a task, once mastered, can often end up in the person switching off mentally and making mistakes; repetition of a process or how we interact/ collaborate within the team generally brings about efficiency and ‘perfect practice’

Share this blog article