We know by now that DevOps requires more than the right tools and methodologies to succeed. It’s a mindset and cultural shift – and it’s not easy. Pair this with the fact that more IT work is being done by remote teams, and the culture challenges begin to pile up.
In a recent article, Mark Runyon, principal consultant for Improving, made the connection between these two issues clear when he noted that one way to assess the health of your DevOps culture is to look at how spread out teams members are.
“In an ideal world, the whole scrum team is occupying the same space,” Runyon wrote. “The same space doesn’t just mean they work in the same building or are spread across separate floors or departmental cubicle farms. The same space means the team is within arm’s reach of one another.”
Runyon makes a compelling case for co-located DevOps teams: “Being co-located allows the team to easily call an impromptu meeting to discuss a problem that has arisen. It allows select members of the team to quickly break off to whiteboard a solution for a feature that is failing to gel. In addition to removing blockers in real time, working in a dynamic environment like this builds bonds between employees that can be difficult to replicate when the team is working remotely or simply spread across different cities, buildings, or floors within the organization,” he wrote.
[ How can automation free up more staff time for innovation? Get the free Ebook: Managing IT with Automation. ]
Remote work is a growing trend
As Runyon notes in his article, the remote work trend isn’t going anywhere – teams just have to work harder to shorten the distance and build culture on dispersed teams if they want to succeed with DevOps.
This can be especially tricky for large organizations, says Helen Beal, DevOpsologist at Ranger4. “While it is the ideal to have the teams colocated, this often just isn’t practical or even possible, particularly for organizations that are transitioning from a siloed, waterfall culture to one of small, autonomous squads,” she says.
“When organizations are very large, with tens of thousands of people in technology teams, even if they are in the same country they will be across multiple locations, potentially hundreds or thousands of miles apart,” says Beal. “Additionally, many organizations have models where they outsource parts of the value stream like development, testing, and operations, frequently to different countries. The cost of changing these models is huge, incredibly disruptive and likely causes a lot of headaches for HR because of employee rights. Most people can’t or don’t want to move to another city or country, and they shouldn’t be expected to.”
Where remote DevOps teams excel long-term
It’s worth it to overcome the barriers created by dispersed teams. Doing so can help cement a culture that can survive more difficult DevOps challenges down the road, says Hina Popal, senior agile practitioner and Scrum Master at Red Hat.
"There is a bigger up front cost when forming a remote team, but through this process people learn to become experts at collaboration and flexibility,” says Popal. “It’s much harder to get the team to find their rhythm. You can’t see people who are sleep deprived at the water cooler, you don’t really understand that people are sacrificing their work-life balance when trying to find a timezone that works when you are distributed over more than one continent, and overall it’s hard to learn others quirks from just having meetings via video call or chatting on a messaging app.”
“That being said,” she continues, “when teams work through all of these difficult problems, they have already faced some of their hardest challenges. That means they can handle many things as a team because they went through these experiences up front.”
In fact, avoiding the challenges of remote work can create its own problems. For instance, learning how to communicate with team members effectively is critical for all teams – whether they are in the same room or not.
"Remote Agile/DevOps work is not just possible; it works,” says Robert Reeves, CTO of Datical. “I’ve seen developers in the same room use Slack to communicate. I have also seen impromptu Slack calls across continents. So the argument to keep the team within arm’s reach for the sake of having impromptu meetings doesn’t fly. In fact, that can be a negative.”
“Having the team in arm’s reach also perpetuates a DevOps anti-pattern: enforcing the need for face time with the boss,” Reeves adds. “As a manager, if you feel the need to physically see your team in order to see their progress, your ability to gauge productivity via KPIs is really bad. You should either fix that or consider not being a manager."
How to manage remote DevOps teams with a healthy culture
Below are five ways to tackle the challenges of remote DevOps work head on and succeed, experts say:
1. Get teams together periodically
“Remote working is of great benefit to employers and employees both in terms of cost, productivity, and quality of life. What I have found to be very effective is to get the members of the team together for a few days a quarter or so; just a small amount of face time with people helps build the relationships in a way that sticks, and the remote working works even better when the human feels they know the other human, no matter where in the world they may be," says Beal.
2. Invest in the right tools
“Many of our agile and DevOps teams include full-time or part-time remote team members including product managers, software engineers, scientists, and more. Remote work does require careful execution and special techniques compared to co-located teams, however. We use gobs of tech tools to support our remote workers. We make extensive use of G-Suite, Zoom web conferencing, GitHub, Google Jamboards, Slack, virtual Miro brainstorming boards, Owl video conferencing, and anything else we can get our hands on to make remote work more productive and enjoyable,” says Matt Poepsel, senior vice president for The Predictive Index.
3. Over-communicate
"CircleCI has always embraced remote work. As a company comprised of engineers working to solve problems for other engineers around the world, we believe that being distributed allows for 24/7 support for our users. Given our distribution, we’ve been very intentional and deliberate about how to succeed as a team from the start, and there are plenty of things we learned along the way. One of the intentions we explicitly agreed upon was over-communicating, and it has proven to be extremely useful. Starting out as a widely-distributed team of mostly folks who had never met in person, we hoped over-communication would help us at least avoid not communicating enough, and, at best, figure out what communication level we need,” says Rob Zuber, CTO at CircleCI.
4. Make meetings intentional
“We teach our meeting leaders to think about the nature of their meeting prior to kickoff. Is it a brainstorming meeting? How can we use a virtual whiteboard? Do we need to make a decision? How will we gather critical inputs from remote team members? If one person is remote, we try to make sure every person in the meeting is visible on camera. We always give the speaking right-of-way to remote workers before those in the room,” says Poepsel.
5. Explore new ways of working
“We’ve seen success with a collaboration process called ‘ping-pong’ pairing, which is similar in principle to traditional pair-programming, but asynchronous. Rather than navigating/commenting on code the other person is writing in real-time and switching driver/navigator roles often, we let our respective daily schedules dictate the rhythm. This still retains the usual pair-programming benefit of knowledge sharing, while actually allowing more than two people to participate in the process,” says Zuber.
The work that Zuber’s team has put into learning how to work effectively as a dispersed DevOps team has paid off. “During an in-person offsite a few months ago, one of our teams asked: ‘If we had a choice, would we choose to be a remote team distributed across distant time zones, or would we rather be at least closer together?’ The answer was: ‘We wouldn’t want to change a thing,’” he said.
[ What do great agile leaders do differently? Read How to be a stronger DevOps leader: 9 tips. ]
