How to optimize the productivity of a DevOps team

Last Updated on May 8, 2023

The following blog post was written in collaboration with DevOps experts at Zenhub. Try Zenhub for free.

DevOps is the backbone of any successful business, ensuring seamless operations, addressing security threats, and coming to the rescue in times of need. As a key driver of productivity and innovation, it’s vital that DevOps teams are efficient and effective. The DevOps model, which seamlessly integrates software development and operations, was created with this goal in mind – to foster close collaboration and drive success for the entire company. 

According to Asser Ghorab, Director of DevOps at Zenhub, “In theory, a DevOps team shouldn’t be a DevOps team. It should be a way of working the whole development team is applying.” But, nowadays, it’s changing more than ever: “Given that the landscape of tools is more complicated, DevOps as a way of working is more untenable. This has resulted in the rise of platform teams or SRE teams – specialized DevOps teams that focus on facilitating and enabling the work of development teams,” says Asser. 

With the model of DevOps changing so significantly and team sizes and structures growing or changing, it’s critical for teams to reflect on best practices and look at how they can continue running DevOps teams efficiently. In this article, we’ll cover some best practices for optimizing the productivity of DevOps teams, with insights from Asser Ghorab from Zenhub. 

Mixing agile practices with DevOps practices

When it comes to optimizing productivity, agile methodology is the bread and butter for most software development teams. But with DevOps, which is often both used as a methodology and a defined role or department in a company, agile-inspired practices (if they use them) can look very different, yet familiar.  

Yes, many traditional DevOps methodology overlaps with the agile practices you’ll find on most software development teams. So, where is the convergence between DevOps and agile? “There’s hardly any consensus on this,” says Asser. And a quick Google search will tell you just that – there seems to be no consensus from the DevOps community. 

For DevOps teams, this is because a lot of work involves putting out fires and responding to urgent requests. “We do use a lot of scrum practices, but a lot of work is unplanned. Using Scrum for unplanned work doesn’t really work,” says Asser. 

How to plan for the unplanned

The fix? A carefully curated mix of agile and other project planning methods. “Our DevOps team is more on the Kanban side of things, but we use Zenhub both for planned and unplanned work.”

Like most DevOps teams, the one at Zenhub subscribes to the DevOps notion of the “3 ways.” These are: 

• System thinking
• Amplifying feedback loops
• Continuous implementation

For Zenhub’s DevOps team, these translate to monitoring, having a proper understanding of where everything goes, and having reliability and resiliency built into the system to break things for testing purposes and recover gracefully. “So the planned portion of our work, more or less, works in a scrum manner. We still use Zenhub for unplanned work to understand how we spend our time, report on our resources, and see our bottlenecks. It’s more of a Scrum/Kanban hybrid,” reflects Asser. 

Agile for reporting and resource management

When it comes to managing unplanned work, the key here that Asser mentioned is tracking. Having this historical data on hand – which can tell you approximately how much unplanned work typically comes up in a week – can help your team create enough capacity for ad hoc tasks.

Agile reporting can help deal with these unpredictabilities – tools like velocity tracking allow you to see the team’s average capacity per sprint, so you can get a rough idea of how much planned work can be completed that week. “We use velocity reporting to say these are the things we want to do and how much time we need for it, to help with budgeting, and to ensure there are no urgent requests we don’t have time for,” says Asser.

Don’t over-flesh out your roadmap

When teams want to be more productive, there’s often an inclination to over-plan work. This, according to Ghorab, can reduce a team’s ability to be nimble and even their ability to innovate. 

“The key thing I find that has been helpful for giving teams a sense of direction, ownership, and productivity was the progressively vague roadmap,” recalls Asser. “If we’re planning a roadmap 3-4 months out, this is the technology that we know, priorities that we know, and it [the roadmap] is fleshed out fairly well. The farther we plan, the roadmap starts to get vaguer.” 

Over-fleshing out roadmaps can cause the team to work on or waste time thinking about how to create products that, in the future, may be more efficiently created with new technologies: “Whatever tech we would use now might be irrelevant 6 months from now. A progressively vague roadmap is more directional rather than specific. It keeps the team open-minded, with their eyes peeled for new technologies,” says Asser.

In addition to keeping the roadmap as a living document that is progressively vague, Asser suggests having a refinement meeting at the beginning of every sprint to reprioritize planned backlog items. If the team has extra time (i.e., time not spent on non-planned, urgent work), then they try to tackle technical debt. Priority shifts (like those urgent requests) are usually communicated in daily standups, off-hand huddles, or Slack. 

Breaking down silos

Silos are something we often don’t think of when we think of productivity, but they can really hold a team back from being as efficient and innovative as possible. Zenhub’s DevOps team uses Roadmaps and partnered work to help break down their silos. 

Roadmaps

The Zenhub DevOps team merges its roadmap with the rest of development to break down silos. Asser explains, “What I love about how Zenhub works is that we have the whole team’s roadmap. This allows the DevOps team to see how everything they do directly contributes to, enables, or unblocks one of the big goals for the whole development team.” For DevOps teams, it’s not always obvious how their work applies to and enables the wider team’s work. Seeing what work it impacts allows the team to think about problems holistically and understand their value to the wider organization. 

Roadmaps help teams understand the why behind the work – which is usually the same for multiple teams – so connecting teams on a roadmap can help leaders drive the “why” home. “As the leadership team, really defining the why is important – the team will figure out the what and the how. When you explain the why well, the team will usually figure something out better than you could – they know the technologies better than us,” says Asser. 

Not pigeonholing team members

It’s common on development teams for devs to get pigeonholed into being the go-to person for a single type of task due to their experience in that area. This can impact productivity as, if this team member ever leaves or is unavailable, you now have a whole team of people inexperienced in a critical department. To avoid this, Asser suggests pairing the person with the most amount of knowledge with the person with the least experience to help create more well-rounded developers on the team. 

Conclusion

While the DevOps model was built for efficiency, there are plenty of ways to improve your DevOps team’s productivity further. Planning for the unplanned through agile tracking and reporting, mixing agile and Kanban practices can help keep things running smoothly, even in times of uncertainty. Not over-fleshing out your roadmap can prevent wasted time on unnecessary work and processes while keeping the team more in tune with new technologies. And breaking down silos – wherever they may come up in your organization, can help your team understand the why behind their work and learn more from their peers. 

At the same time, companies shouldn’t forget to implement security into their productivity plan. With backup software like GitProtect.io, you can back up your company’s data so that it’s quickly accessible in the event of a catastrophe, ensuring business continuity and productivity even in the toughest of times.