Udemy courses up to 50% off


How to Overcome Challenges in Managing Remote Agile Teams
Medium and Dan Radigan, Atlassian 183 Times 134 People

The lack of skilled IT workers is hurting the deployment of emerging technology, according to a new survey from Gartner. In areas from cloud to cybersecurity, this crisis is expected to last for years to come.

Both, companies and employees will have to orient themselves to this new way of working and it is not going to be easy. Several challenges will have to be overcome especially in case of Agile teams.

In such a scenario, how does one manage remote Agile teams? Agile development was originally imagined for clustered teams, or teams physically located together in the same office.

In keeping with the idea that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation", early agile teams were meant to work together in close proximity.

In some companies that did change because of distributed development teams. But today, the Covid-19 pandemic is forcing full-time remote work for agile teams which is contrary to the principles of Agile.

The remote only environment presents challenges to the team leaders in managing the teams and the work.

Some of the challenges include:

  • Coordinating across time zones

  • Building rapport when everyone is not in the same office

  • Collaborating among different development cultures

  • Scheduling meetings or informal conversations when both teams are online at the same time for only a few hours (or less)

All these can be addressed and here are some tips and strategies.

How to structure global teams

Good software architecture dictates modular design, so structure your teams the same way.

Every office should be self-sufficient in developing a single piece of technology, which minimizes the amount of collaboration required with teams in other time zones and makes them generally autonomous.

When a project does require teams in different locations to pitch in, they can focus on their integration points and APIs.

Code reviews also play an important role. Since people are online at different times, distributing knowledge of the code between offices makes support and maintenance much easier.

If a production issue emerges when the team is not online, another office can easily step in to support and resolve the issue, thanks to the know-how they gained from cross-team or cross-location code reviews.

Communication is critical

Agile methodology recognizes face-to-face communication as the most efficient and effective means to share ideas. The benefits of sketching on cards or a whiteboard are two-fold — increasing the level of understanding and decreasing the time it takes to deliver the message.

Distributed teams must actively work to avoid falling into communication traps. Encouraging the same close communication expectations as co-located teams is the key to upholding Agile process on distributed teams.

Here are some communication strategies for remote agile teams:

1. Foster a culture of continuous integration when builds are constantly discussed and planned.

Creating a culture where continuous integration is the norm is especially valuable on projects with extended timelines or when managing remote teams.

In this structure, it’s easy to opt for dividing work for teams along technical boundaries.

These technical boundaries may be divided by frontend/backend work or even database and services layer/frontend.

Team bandwidth or security might drive the divisions. Resist maintenance of two source code repositories.

2. Commit to regular builds, so you don’t prioritize upholding the plan over agility.

It’s easy to produce a giant spec in lieu of communicating daily with the offshore development team or let distance become a reason to stay the course and avoid evolving the solution when challenges or barriers arise.

Building on a weekly schedule is good, daily is even better. Hold your team accountable to submit a change set to the source code control each time. Then, take advantage of your compiler as a stand-in team member to ensure your source code has reached or exceeded quality expectations. Adding smoke tests can move this dial even further.

3. Embrace the social process of developing custom software.

Most people assume custom software development is a purely technical process. While it’s true it is a social process first and relies on trust built between individuals.

Encourage knowledge sharing on every team. This is less about cataloging processes in a Wiki and more about cultivating this naturally in daily stand-ups or any time team members give updates.

Encourage your team to share beyond what pertains to that day’s work. If a team member anticipates something they are working on may impact another role the next day, call that out.

Once team members master the habit of sharing meaningful, forward-looking insights to their work, that’s when true knowledge sharing has been achieved.

4. Foster close communication between UX designers and business analysts to accelerate throughput by a factor of two.

Encouraging close collaboration between designers and business analysts, encouraging extra attention to the graphical interface. This may mean additional time is spent creating visual artifacts for the technical team to complement related user stories.

The reward? Less questions related to aesthetics and fewer iterations created as a result of the mismatched expectations.

5. Discuss even non-functional requirements.

For teams who are co-located, it’s easy to address questions around performance and scalability as they arise. Conceptualizing and documenting requirements with the appropriate level of detail serves as the link between the business and technical teams.

For distributed teams, understanding non-functional requirement detail plays an even larger role. Without explicit directions documented for the technical team, it might result in the creation of an architecture that makes assumptions about the non-functional requirements resulting in increased rework, time and spend later.

6. Managing a distributed team may mean documenting more.

While all Agile teams strive to write “just enough” requirements, managing a distributed team means accepting “just enough” may still mean documenting more than would be created for a co-located team.

Distributed team members can’t quickly sketch on a whiteboard to work through a complex concept. Rather than leaving your development and testing teams left guessing on the nuances that would otherwise be delivered verbally, document them and “give the answers” before the test.

By augmenting user stories with test or acceptance criteria you can set the technical team up for success without drastically expanding the narrative.

7. Choose a suite of communication tools for your team that allows for the natural escalation of communication needs.

When teams are co-located, the level of communication needed escalates naturally. It might begin with co-workers speaking one-to-one in the breakroom.

If clarifying details are needed, additional subject matter experts may be pulled into the conversation. Then, the conversation shifts from many-to-one or many-to-many, depending on the context.

Maintaining this escalation process is essential to create outlets for quick answers or more in-depth conversations despite any distance that may exist between team members.

What does it take to succeed with distributed Agile software teams?

No electronic tool or communication strategy can replace the perseverance of the leaders required to realize their potential. These leaders must believe Agile can work for distributed teams. If they do, it will.



Comments:(0)

Leave a Reply