High-Performing DevOps Teams by Nick Barton

Software Development has changed over the years. DevOps has taken the Technology Industry by storm, moving beyond the buzzword and becoming an integral part of every high functioning IT teams strategy. But are companies really using DevOps to their advantage and getting the best out of their teams?

One of our lead engineers, Nick Barton, talks about his extensive experience in DevOps and how to ensure you have a motivated and productive team.

Having been involved in managing DevOps teams for a number of the 60+ Cloud automation projects AL have undertaken, I often get asked; what major problems do we frequently encounter along the way?

Being an Engineer myself, people expect answers like, ‘adapting to a constantly changing Azure API’, or that ‘ARM templates are not really suitable for proper automation’. Whilst these kinds of things can and do cause problems. The common theme I’ve found is that the hardest problems we encounter do not have a technical solution; they are to do with people and process.

In this series of blogs, I’m going to look at some examples of people and process issues encountered and offer some insight into how you can solve these problems to better achieve your end goals. Starting with how to beat your team into delivering more…

Team Motivation

So, your expensive DevOps team’s output seems lacking? Their User Stories are moving from one sprint to the next, no one is picking up new work and they are skipping standups and generally not communicating? The standard management response to this is: We’re going to need a bigger stick.

I’d like to draw on an example from studying parenting techniques over the years… behavioural problems with less than angelic kids can often be traced back quite easily to the parents. For example, Kids that are fussy eaters. They are generally not made to eat what’s in front of them but are given snacks between meals.

So, what I’m really saying is, if you are a manager of a poorly performing team, you need to give your management style a long hard look… or at least try doing things differently.

In my experience, it is very rare to come across an engineer that doesn’t want to actually get on and get something done, deliver some quality output and feel like they are adding value to the process.

Engineers get job satisfaction from collaborating to learn new things and delivering in an environment of trust. It is almost unheard of to find an engineer in a good environment who is trying to do as little as they possibly can. I have probably come across only a few individuals over the last 25 years of running teams. They are relatively easy to spot and even easier to manage out of the team.

When assessing a team’s performance I generally start with a list of the symptoms being experienced, perhaps track a list of points raised in retrospectives (you are doing them, right?), and all the times where something has needed escalation. Look at long-running tickets and perform an analysis of the workflow. Are tickets getting blocked? Is the team always waiting for responses from key individuals? It’s important at this stage not to jump straight to resolving these symptoms, because as the name suggests they are just symptomatic of underlying issues. Look for common themes and try to understand what the root causes could be.

Some areas to look at are; How is the work coming into your team, is there a clearly defined process? Do the team understand the overall importance of what they are doing? Do they even understand the aims of the programme or project they are working on?

If engineers are not following good agile processes, do they understand the benefit of the ceremonies being performed? What is the point of a daily stand up, or sprint planning? Are you, as a manager, constantly bypassing the agile process by consistently changing priorities, adding work into a sprint or distracting the team with non-essential, non-sprint related work?

In summary, your engineers are the most important resources you have to achieve your project’s goals. To be an engineer, they are going to have curiosity, a desire to learn; let them explore and try things out in a safe environment. Really pay attention to the output of retrospectives, make sure firm actions are taken away and always progressed. Listen to how the team want to work, don’t impose a particular way of working, but make sure you are gathering metrics, so the team can experiment and make decisions based on real data. You will find very quickly that the team starts to buy into the work that needs doing, and that sense of ownership will go along way to transforming them into a high performing team.

If any of this sounds familiar, you’re not alone. There are many companies facing these struggles on a daily basis. The best thing you can do for your team and company goals is to tackle them. If you think you need help, get in touch with us at info@www.automationlogic.com to inquire about our free DevOps Assessment which leaves you with a prioritised roadmap of your next best steps, specific to you and your team.

Want to read some more relatable content? Click here.