Get in Front with DevOps

Go faster, deliver better value, achieve higher quality, collaborate better

This is the 3rd article in a series following on from: I fell in love with Mabl (How to become DevOps compliant), and DevOops, some common anti-patterns

I saw a bio on Twitter:

“I solve more problems than I cause”

Simple, but effective, and captures some of the essence of DevOps.

This person could be knee deep in fixing problems — or they could be a developer who sees the big picture — relating to the importance of production, team player, not afraid to roll their sleeves up, higher state of awareness with technical debt, doing what they can to make the long term better, focused on quality as well as flow.

This is the winning developer (or product engineer) in the emerging digital economy. They have more space for creating new things, and a winning CV. Combining passion, open-mindedness, and energy, these are the DevOps-minded engineers we need on our teams. So how do we get there.

First — I’m not going to write about the Three Ways. As Gene Kim said this is summed up excellently by Tim Hunter (an old post but relevant as ever, no need to cover again). Nor is this about the great detail behind DevOps practices (you can go to The DevOps Handbook and other sources for that). And if you’ve not yet seen it, you should watch Chef Style DevOps Kungfu.

Nor will I cover here the approach to Digital and IT Transformation that DevOps has to be part of (hard to do that justice in one post).

But what I will cover is an approach to super-charging your DevOps practices, and I’ll break that down into two main headings: get your organisation in shape, and work harder (sic). So the first thing:

Photo by Ayo Ogunseinde on Unsplash

Get your organisation in shape. I’ll write about brownfield organisations. For greenfield you have the opportunity to be DevOps native from the start. The harder thing is approaching this from large, established, siloed organisations, with lots of legacy and history, and governance and compliance issues. For me, basically there are three things here:

1. Your organisation already knows

Firstly, you will have lots to work with. There will be so much nascent talent and potential in the organisation, there will be high performing teams, pockets of excellence — in addition, the teams within your organisation will know the issues. Where flow is stunted, where rework happens, where things are manual, where walls exist, where there are quality or value issues, where software and systems go back and forth over the wall, where deployments take ages and are risky, where expensive interventions are required, where people are unhappy. Where it is not agile, not DevOps.

With DevOps you can focus on the gain (faster value delivery, higher quality, lower cost — I’ll do a separate post on the cost benefit) — but it’s worth also focusing on the loss. A development team will tell you what their pains are, live services and ops folk will do the same — you have so much to work with. With the gain and the loss, which your organisation will know, or a good coach can bring out, you will have the desire to get from where you are (all the losses) to where you’d prefer to be (all the gains).

2. Identify and build the talent

Look across the organisation. There will be so many people that are hungry to be part of this movement. Find them, and connect them. Others will have talent and potential but need help to see the light. I’ve seen some ‘successful’ firefighters and manual/scripting heroes switch on to the new world, and become ambassadors for better ways of working and automation. Across the IT organisation all the teams play a role and can be brought together.

Then build through recruitment to complement your teams. I’ve been lucky with the people I’ve hired. I’ve hired more developers than ops and service people — but I’ve needed both for multi-disciplined teams, and I’ve integrated the engineers whatever ilk into a single engineering team or team of teams. Some of the developers came already with the mindset. Others showed the attitude that they wanted to lean into it. Watching some it was amazing to watch them evolve with the feedback loops from production.

I’ve been lucky to work with some of the best developers, operations staff and DevOps platform engineers (for want of a better title) in the field. The latter were key hires (and internal development opportunities for some), which helped foster the culture, then the tools, and in turn reinforcing the culture. Inducting all new starters with a week or two in a platform team is a good trick, as it’s a good vantage point to see the end to end process. Ultimately though, the platform engineers are development-enablement, and should help foster CICD standards and improvements, supporting multiple product teams to be as autonomous as possible.

In all this — complementary skills and view points is key. Diversity is essential not just because it’s right but because it creates the best chance of having multi disciplinary and balanced teams. Great technical skills are obviously needed, but more than anything attitude and a customer success mindset are what you’re looking for.

3. Help the organisation by breaking down the barriers.

This starts from bottom up, top down, and from the middle — and should align with your Digital and IT/Engineering Transformation effort. But my starting point, is not a separate engineering and service operations organisation.

Bring them together — but it needs the right (servant) leaders at the top to collaborate, or ideally a single person, but they have to be as passionate about service excellence as they are delivery. Then the teams need to come together, and this is what you need: (Raj Fowler describes some of this and more in his #AStoryofDevOps articles):

• Product delivery lead — focused on flow (scrum, kanban, lean or CD)
• Product technical lead — focused on quality
• Product engineers — focused on sustainability and delivery in equal measure (good sustain=more delivery)
• Product analyst /owner — the key to map and draw out business and user requirements and translate to what can be delivered (epics, stories, fixes, product roadmaps).

Then in my experience supported by horizontal enablement for standards, service excellence, and those roles that can be leveraged across an organisation to reduce cost, but in a service (one team) culture, not in silos.

Across the organisation, I believe in wrapping roles around people rather than an operating model you plug people into. Complementary teams, playing to people’s strengths.

I’m not saying development and operations will live happily ever after, but this gives you a better chance of them not having a rocky relationship.

Back to breaking down the barriers and organisational change. While most will lean into this naturally, or with coaching, some won’t make the journey. Business change and recognising the change curve — helping people and being kind to people is essential for me — but some won’t make the journey, and you have to break a few eggs along the way. Usually this can be close to zero.

After that, it’s time to..

Photo by Jordan Whitfield on Unsplash

Work Harder — This is not working longer hours, working weekends — that’s sometimes necessary — but in the knowledge and emerging economy we are increasingly paid for our brains, and they’re best when they’re fresh. What I mean is, work harder at working smarter, and work harder at enjoying your work, and helping others. This applies to many things, but particularly applies to DevOps and Agile.

Work harder at working smarter

I enjoy Jonathan Smart’s writing on this. He is someone I only became aware recently reading the 100 DevOps leaders, enthusiasts and experts — an impressive list, all the more considering every FTSE100, 250, Fortune 500, every Government department, etc, needs at least one DevOps leader in its organisation. Jonathan’s headings of Quality, Flow, Value, Happiness work perfectly for this section.

Quality — This is smart working. Not cutting corners. Doing the things now that avoid issues down the line. Problem solving is good, problem avoidance is even better. You have to prioritise quality — reliability, performance, and usually scalability, capacity, and areas that support those things such as monitoring, and recoverability. These are key aspects of most systems or products. And all the things that support this: designing and building with supportability in mind, and QA throughout. As my friend and fellow DevOps evangelist Raj Fowler said, “Service is King, Change is Queen”. Meaning to me, they are equally important, there is no hierarchy. But you have to get service right to create more space for change. The future (present for many) for this is automating and reducing toil — I’ll cover Site Reliability Engineering in an upcoming post, but for those new to toil read Mathias Lafeldt’s Toil: A word every engineer should know.

Flow — Most start with Scrum, and with discipline maybe progress to Kanban, Lean, and hopefully Continual Delivery. Sometimes Scrum is just going through the motions, mechanistic in terms of velocity, story points — but the highest performing teams have flow (and soul) in the process. A great Product Delivery Lead (or Scrum Master), maybe supported by an Agile Coach, but definitely by a product team that is empowered and takes ownership — can achieve great flow. This is the part of DevOps where tools can play a strong part — in three words, automate automate automate. For a new product, the delivery/CICD pipeline, should be the first thing you do. For a legacy product, look for payback (such as reducing deployment times) — and in almost every case I guarantee there will be some.

Value — The most important thing, ultimately what every IT organisation is here for. Create value to your organisation and its customers by supporting the value chain and getting products (including services) to market faster. In the digital, rapidly disrupted, software based world, this is everything — relates closely to flow and quality — and is ultimately why we need DevOps, because it’s just too slow and expensive to deliver value with a wall between Dev (or Engineering) and Ops (or live Services).

Happiness — A happy team gives you a better chance of success. Many measures don’t give you a warning sign of problems to come, but an unhappy team indicates issues that might not be there yet but likely coming soon — if you measure anything, measure this. Work with a smile, every day is an opportunity to learn (even more so when things are going wrong). This brings me on to the last aspect..

Work harder at enjoying your work, and helping others

Work is a big part of life and we spend so much time at work, so if you’re not working with a smile, or not enjoying it, you should look closely at what’s going wrong, either a state of mind, or in the wrong place. Obviously there are high pressured jobs, or low paid manual jobs, but sometimes the pressured ambulance driver or the low paid cleaner having to stack the dishwasher for the office workers are some of the most gregarious people, despite the conditions.

Whatever your role or team, think about other teams, other people, particularly adjacent to your team. We’re stronger from being broader based and seeing the bigger picture. Having a global mindset — development and production. Find out the issues of other teams close to you, this is a two way process, and work out ways you can reduce pain and manual effort or rework between teams. Ultimately the philosophy of DevOps and breaking down barriers in the organisation can help with this, but start it from the ground up, from the middle, and from the top.

Respect everyone. Help the others. Work to make work more enjoyable for yourself and those around you whatever their role. If there are issues, don’t complain, get involved, and be part of the solution. When this happens, good things happen.

Know this never ends. You don’t arrive at a maturity score of 4 or 5 and then you’re done. You don’t complete this move and become steady state. In the new world of fast moving change and multiple forces acting upon you, you need to deliver and improve non stop, ongoing. Inspect, adapt, throughout. Don’t accept poor or even good rather than great — challenge and make the improvement happen. These things won’t guarantee success, but they will give you the best chance of success. This for me, is the philosophy of DevOps (and not a Jenkins, Chef, Openshift, or Mabl in sight — as great as those tools are).

Gary Watts

Photo by Aziz Acharki on Unsplash

If you liked this article hit clap a few times.

You can follow me at hackernoon.com/@gary.sa.watts and twitter.com/@garysawatts

And here are some more articles from me:

What’s getting Agile down?_A productivity conundrum_hackernoon.com

Time to say farewell to Scrum?_Continual Delivery could blow it away_hackernoon.com

Mabl taught me how to become DevOps compliant_The moves sweeping the IT industry are fascinating to watch — DevOps, Site Reliability Engineering, Serverless, NoOps —…_hackernoon.com

DevOops, some common anti-patterns_Failing to bust those silos_hackernoon.com