Getting more out of DevOps – A Q&A with Edward Butler

Next Gen Insights | Edward Butler |
17 July 2019

The popularity of DevOps is continuing to increase, and for good reasons. When done right, it has the ability to help your business become more engaging, more responsive and more efficient. That being said, DevOps can mean different things to different people. The focus can be split between tools or people and process. Thanks to its rapid growth, DevOps can appear to be an unstructured (and sometimes mystical) approach.

We decided to sit down with our VP of DevOps Transformation, Edward Butler, following on from his presentation ‘Does change mean downtime?’ at a TechFlow event held in Chisinau, and ask him a few burning questions and get a couple of tips about how to successfully start using DevOps today.

1. Why is there so much hype around DevOps, and why should we not ignore it?

In the past, it was the big companies that ate the small companies, today, that has changed – it’s the fast companies who are ‘eating’ the slow ones. Most markets are facing some kind of disruption and companies need to react, and the faster they are able to do that, the better. This means that the ‘business’ and ‘IT’ have to break down traditional silos to become closer and create a feedback loop between themselves and their customers – having this feedback loop enables faster iteration cycles, meaning they can respond to their customer needs more immediately and therefore become more successful – failure is where success is born.

Initially, Agile ways of working allowed us to put bundles of value on the shelf much faster. With the advent of the Cloud and engineering pursuits like Continuous Delivery, we are now in the age whereby we can also ship and maintain these bundles of value with the same speed (or faster!) – using modern techniques to automate the mundane, increase quality and reduce the risk of deployments.

Achieving this requires a true cross-functional team that works in harmony and unison – who are always questioning how they can improve and challenging their definition of what ‘good’ looks like. Therefore, if you believe that there is no them, only us and want to use your skills to make a real impact, you are ready to start making the most of what DevOps has to offer.

2. How did you discover DevOps for yourself and has your attitude towards it changed over time?

Many years ago, I came from an infrastructure background, building platforms and services for ‘other’ people to run workloads on. I’ve always had a passion for making things as efficient as possible but found it frustrating when the platform I had built needed to change for ‘other’ people’s workloads to run on them.

I was stuck in a typical silo, where everybody’s concern was their own task rather than focusing on a clear and shared goal. A great example of a clear and shared goal was Nasa’s mission statement for the Apollo programme, which was simply to ‘put a man on the moon’ – not design a suit, or build a rocket etc.

What I realised quite quickly was that it was the silo I was frustrated with, rather than the fact that ‘my’ platform had to change. In order to fulfil my passion for efficiency, I had to step out of my comfort zone and seek out the shared goal and determine how I could make a difference and a worthy contribution.

Specifically, thanks to the fact that I had some programming experience, I was initially led towards infrastructure automation, but as I got further away from my comfort zone, I discovered that the way in which we think about code, testing and architecture also needed to adapt in order to truly achieve the goals that had been set for us.

To this day, it is this same curiosity which drives me to seek out true efficiency and answer the perpetual question ‘why’? As the systems we build become more complex, meeting people and asking questions has never failed to uncover something new for me – I have learned that the key to becoming a true team player is to show empathy and share in both the successes and the failures with others.

3. What are your top tips for getting started with DevOps? It is more than just merging the Dev and Ops teams, right?

a) Start with a real-world tangible high-level vision that people can relate to:

The ultimate goal of DevOps and Agile ways of working is that the whole team feels accountable for the product they ship – you build it, you run it. To achieve this, giving the team something that relates directly to the business’ core goals will empower them to take responsibility and pride in both the quality and sophistication of their product.

Arbitrary metrics that are abstractions of productivity can serve to frustrate, as they never give the whole picture – and at worst, risk becoming gamified. Remember, if your goal is to put a man on the moon, it’s not just to write a certain number of lines of code per sprint.

b) Find a project that represents value:

Couple with a real-world vision, when embarking on a DevOps transformation, everyone needs to have a stake in its success. If the project or initiative does not represent any value, then it will become easy to disregard or deprioritise. Transformation can only work when there is both top-down and bottom-up enthusiasm, and since it is not an easy journey, everyone needs to care about it to maintain motivation.

c) Understand where the current problems and bottlenecks are:

Executing a DevOps transformation is to challenge potentially years of process and ways of working. Essentially, we are changing people’s instincts and habits, asking them instead to question why something has to be done in a particular way; and evaluate with new technologies how incremental improvements can be achieved – as they will all add up in the end.

To do this often requires measurement, especially around cycle-time, to ensure there’s an indicator of where a delay occurs. This is a continual process to improve flow, so if we’re not reducing a chronic blockage, then we’re not really making an impact.

d) Ensure there is a culture of psychological safety

Failure is often a lonely place and focussing blame on one element (or person) risks missing the real root cause of an issue. Instead, businesses need to recognise that success lies within failure and that boldness and inventiveness should be rewarded. To be truly Agile is to experiment with the unknown - which by its very nature is to embrace failure as a way of learning and becoming successful. You could argue that when issues occur, someone has uncovered a flaw in a process or system that may otherwise have gone unnoticed – which is, more often than not, a good thing!

Following the Toyota Kata principle, at the first sign of a problem workers would pull the ‘Andon Cord’ to stop the production line and inspect the cause in more detail – and ultimately mitigate it happening again. The same can apply in the world of IT; giving teams the opportunity to balance their technical debt and to mitigate risks is in itself a recognition of ingenuity and assertiveness. This freedom encourages more daring and confident solutions that better achieve the business outcomes bestowed upon them.

e) Get the easy things right

Good communication solves most problems – this can be as simple as a face-to-face conversation or ensuring there is a common vernacular across teams to avoid misinterpretation. Also, we are often proud of what we achieve and want to share our achievements with others. Even though those more naturally inclined may go the extra mile to communicate with others, even outside of the working day, those less-inclined (or less confident) may not embrace such opportunities to share their experiences.

Build an open and transparent community by co-locating teams and creating a timetable of events which will improve communication as well as lift team spirits, allowing people to enjoy both success and failure together, inviting contribution and increasing empathy to build a workplace that people value being a part of.

4. There has been a lot of talk recently about DevSecOps, is it fundamentally different from traditional DevOps?

No, but there is an emphasis, quite rightly so, on ensuring that security professionals are included within a cross-functional capability - to drive security awareness within the product team.

When security is viewed as a checklist item, it is too easy to worry about it later - maybe during a hardening sprint or awaiting pen-test activity etc. This is problematic, as with all other principles of a pipeline, the longer you wait for feedback, the more expensive it is to rectify any issues you uncover.

Sure, we can have security standards in the same way we have coding best practices, but the industry has seen huge benefits from the cross-collaboration of traditional Ops in the product team (faster and consistent environments, deployment risks minimised etc) and the same is true for traditional security professionals.

Adding a DevSecOps label is an invitation to treat security as the journey it actually is - not a destination, chore or checklist, but a valuable attribute of the product itself.

Edward Butler

VP DevOps Transformation

Edward has two decades of experience in infrastructure, application management, cloud and DevOps. He works with our clients to help them unlock the benefits of continuous delivery and is passionate about the 'human' side of IT, especially the way that multidisciplinary teams with a shared goal can go above and beyond the expectations of their business. Edward enjoys sharing his knowledge at events and has even co-authored scientific papers. In his free time, he enjoys playing music and sports involving a board – specifically surfing and snowboarding. But not paddleboarding, that's a bit too sedate for Ed.

All Categories

From This Author

21 April 2020

7 tips for successfully transitioning to a fully remote team