Keeping in touch and being cohesive as a distributed team is a challenge many face. Assigning stories from a product owner’s shared backlog helped a distributed team in doing non-stop delivery, as did giving all members of the team the authority to promote to production and back-out code at need. You need to give attention to the architecture to prevent creating similar or even duplicate micro-services at different locations.
Ola Chowning, a partner at Information Services Group, spoke about dealing with geographically distributed DevOps teams at DevOpsCon Berlin 2021.
Chowning presented a solution for teams to do non-stop delivery where they are distributed globally and across time-zones. The particular organization broke their DevOps team into "crews." Each crew was in a different time-zone and was "assigned" different stories (tasks/work) from the shared backlog.
The "real" product owner of the team was aligned to the crew within their natural time zone - the counter crew within the team had a "proxy product owner". This allowed the priority of work to continue to be set by a product owner or proxy out of a shared backlog, Chowning said.
A strong product owner was critical to making this approach work well, and the organization saw teams without effective product owners quickly diverged into separate teams overall, which was less productive and was confusing for the business constituents as well. In these instances, they had to quickly address the product owner role, Chowning mentioned. proxy product owners, on the other hand, needed to lead within their crew and yet recognize the limits of their authority for larger decisions that required the product owner’s input.
This organization was in two different countries that had a natural time zone overlap – without that, they would have needed to create some form of overlap for the crews to stay in sync and to share work. Chowning mentioned that their method of essentially assigning work to a specific crew actually worked well; they had to pay attention to their architecture and rampant "micro-service sprawl," as the different crews tended to create similar or even duplicate micro-services.
Each crew had their own work to do, but kept connected to the shared backlog and priority, shared releases and planning sessions. Chowning explained that crews made it a point to demand, and even schedule, crew sharing opportunities to make sure that the crews maintained some sense of togetherness, even as they worked on different tasks and in different time zones.
InfoQ interviewed Ola Chowning, about working in distributed teams.
InfoQ: What challenges do distributed teams face?
Ola Chowning: An important element of most DevOps teams is cultural integration; learning about and from each other, establishing the psychological safety within the team to fail in front of your peers, the proverbial finishing of each other’s sentences… it’s simply harder to establish this level of cultural cohesiveness when you are working in distributed teams.
Leaders are also challenged; how do they recognize when a team member needs help, needs to be prompted, or requires clearer direction without the body language cues or without any interaction at all, if they are in completely different time zones? As a leader, recognizing when to intervene, when to support, and when to engage is challenging when the team is delivering outside of view.
Trust becomes crucial between all team members. This particular organization is currently considering "time zone rotation" so that team members can establish working relationships and trust outside of their own normal working time group.
InfoQ: How did the crews feel about getting work assigned?
Chowning: They still used a product planning mind-set, and so bi-weekly they conducted a planning session where the crews were able to essentially volunteer for stories, tasks or work products. They also used these sessions to discuss how things were going, both within and between the crews.
This particular organization had some difficulty as one crew commonly had skills that the other did not (e.g., test automation), and so there was initially a bit of frustration that certain tasks always "went" to a specific crew. With their current trial of "time zone rotation", they are looking to promote better skill sharing, and are focusing on minimizing those skill differences.
They share that they are able to act autonomously and with agility within their crew, but still struggle a bit across the team as a whole. Taking the time to clearly articulate the stories (or even story-lines) within a feature or epic, and then assigning specific stories to a crew while still measuring the overall feature, has helped to minimize the feeling of separation.
InfoQ: How does the culture of inclusion and empowerment work when the team is spread across the world?
Chowning: The non-stop delivery method was very useful to promote both empowerment (the crews had the authority to release code to production at will), as well as inclusion (particularly with their crew members as they effectively shared time zones and could chat and collaborate at will). Organizations can strive for inclusion in a variety of ways, but I believe the most useful practices measure inclusion, focus on it, and continuously improve it as a core feature of the team.
InfoQ: What have you learned about supporting online collaboration in distributed teams?
Chowning: Don’t expect this to come naturally to teams - you need to focus on it, include the team members in your initial approach and in continuously improving your practices. Leaders need to be constantly checking in with team members, monitoring their participation, eliciting feedback and enabling changes.
Video fatigue is a real thing. Scheduling a meeting instead of sending an email or chat is a real thing. Recognize where practices may not be working well and involve the team to improve them.
InfoQ: What are your suggestions for creating highly collaborative and empowered teams in a global, distributed environment?
Chowning: The core attributes remain the same - empower the team to make decisions, foster collaboration and diversity as the key to team enablement, establish psychological safety as necessary in a test-and-learn environment. Using digital tools that attempt to mimic physical proximity are not enough to bridge the gaps of being globally distributed, although they are certainly important.
You also need leaders to monitor and foster inclusion, check in with team members, even force some of the interactions that would have been natural with physical proximity. Most importantly, involve the team members in creating the best environment that allows them to thrive as a cohesive team.
