How to Overcome Challenges in Managing Remote Agile Teams
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.
Share your comments on this Article:(0)
Leave a Reply
