Guardrails Are Essential for Any Distributed Agile Team
Teams need guard rails
Teams need guard rails. These guardrails are the difference between team members moving quickly and successfully in a rapid Agile environment, and people accidentally running off a cliff (e.g. deleting code in production without a backup).
The guardrail concept is a universal truth for all Agile teams, whether they be face-to-face in an office or working remotely in a distributed environment. This truth crosses companies, languages, and cultural boundaries.
The objective of any Agile leader is to facilitate the definition and building of these guardrails so teams can be successful. This definition is the foundation of high-performing teams. And the more robust the foundation, the stronger the teams.
Here are some of the guardrails that I’ve set-up to ensure the success of teams a distributed Agile company. These are all grounded in a people-first culture that promotes helping each other through teamwork.
Establish baseline practices
The base activities done by both remote and co-located teams should be the same. For example, co-located teams will start a project with a kickoff. This kickoff helps the team rapidly gain a shared understanding of the vision, direction, users, and work to be done. The objective is to achieve a shared understanding.
This is no different for distributed teams. They still need to understand vision, direction, and goals. They need to know what they are trying to achieve and how they will reach these goals. The only difference is the tools used to facilitate the activity are digital rather than physical.
Good digital toolsets support conversations about the flow work from beginning to end of the SDLC; included in the conversation are folks in both business and technology teams. Practices need to be predictable, consistent, clear, and continuous to alleviate any gaps caused by misunderstandings created in the gaps between interactions.
Understanding how to work together is a guardrail.
Build team alignment but give the autonomy to execute
One of my favorite explanations of the importance of following a plan comes from Spotify’s engineering culture “alignment vs. autonomy” diagram.
Teams need to have high alignment on goals and be given the autonomy to decide how to execute these goals. This is especially critical in distributed Agile teams where people go for hours without communicating with each other due to time zone differences.
Teams without direction (lower right-hand quadrant) will create their own path because they want to feel useful and busy, and the course defined by the team won’t always tie into larger company goals.
Conversely, teams that are given direction and micromanaged along the path (upper left-hand quadrant) will become demoralized and unmotivated. Work takes longer to do as the weight of demoralization occupies brain space and prevents the team from doing their best work.
As you can imagine, an environment with no-autonomy and no-direction (lower left-hand quadrant) creates confusion while demoralizing people at the same time. Teamwork is lost as individuals set their own goals and work to achieve these goals.
The best scenario (upper right-hand quadrant) is to give teams clear, value-based direction rooted-in corporate goals, and empower those teams to figure out how to get there. For example, the organizational goal of the Ocean Cleanup Project is to clean up 90% of ocean plastic pollution. One team within that organization was tasked with using the recovered plastic waste to generate revenue.
They weren’t told how to generate revenue but were given the objective. The team set out to figure out how — and understood that this revenue would be reinvested back into the organization to fund more ocean cleanup initiatives.
For distributed teams, if everyone understands team goals, then they can work towards those goals when other team members are offline. During overlap hours, the objective is to transfer knowledge, share context, and alleviate gaps in understanding. This communication leverages the full power of distributed teams that work in multiple time zones.
Having shared directional objectives and trusting teams to do what they do best is a guardrail.
Everyone must understand that teamwork does not stop when a call is over
In order to maintain continuity on a distributed team, there is a need to overcommunicate. Communication and knowledge sharing become the foundation that prevents misunderstandings that erode at the success of a project. Because of this, no one member of the team should work in isolation for days.
If anything, the need for teamwork is critical on distributed Agile teams because the need for clarification increases with distance.
It’s essential to understand the different types of tools available for the different forms of communication: what you communicate over Slack is different from what you communicate over video or email. Slack messages are meant for quick information sharing, while contextual understanding should be done over video. This is especially true when emotion is present. It is much harder to effectively convey emotion with emojis in Slack versus a video where the emotional cues can be seen.
Team practices and tool choices should be designed around rapid communication. This includes the tools used for spreading information about program goals, progress, and history. These should be traceable meaning a person can refer back to a previous decision easily without worrying about the loss of information over time and the need for repeated questioning.
Communication, knowledge sharing, and teamwork are actions that spread the burden of software development across teams, products, and programs. These are guardrails, and they form the foundation of a company.
Leveraging diversity from connections
As mentioned above, the universal truth about Agile teams is that they need guardrails to work effectively and safely. This is true whether you are on the ground working together or working in a remote, distributed team.
But, there is one subtle guardrail that forms from distributed work.
When you work in distributed teams, you start to pull together a community of people from various cities, cultures, mindsets, and experiences. As these people grow together, the experiences that they bring to the table make stronger teams.
This forms the foundation of a diverse and inclusive company because people have to work continuously to form a collective, cross-cultural dialogue. And, knowledge on how to leverage this dialogue is much harder to find in co-located companies.
This guardrail is priceless.
Sharlene McKinnon’s multifaceted IT career includes time at ThoughtWorks, Google, Nook, Ticketmaster, and Warner Bros.
