Professional Documents
Culture Documents
Today businesses are shifting to emerging economies (Russia, China, India, the
Philippines, etc.) due to reduced business operations cost and an easily available
workforce. If I put it more precisely, tomorrow's business will be more virtual and
distributed, with "distributed" as its key element. Thus the need for better managing
such teams, using the right tools and processes, is becoming increasingly critical for
any enterprise company.
Here are some reasons for the shift and need for having distributed Agile teams:
They can reach the market more quickly with a "follow the sun" model.
Collaboration tools -- improved tools for distributed communications and serverbased, multiuser tools for product development -- are removing barriers, and more
teams view distributed collaboration as an alternative.
Agile can't fix every problem, but it can bring them out into the open, where the team
can evaluate and correct them. Agile puts challenges under a magnifying glass. As the
images under the glass grow larger, they scream for attention, and your team's
performance will improve after it addresses the challenges and corrects dysfunctions.
The key challenging areas that need to be addressed for distributed team management
are as follows:
Different time zones and conflicting working hours impact communication and
collaboration.
Three XP practices that are particularly valuable: TDD, CI, and test automation
Scheduling differences at the team level for various activities becomes more
challenging with increasing levels of distribution.
Not providing access to calls, not set up for telephone calls in meetings,
difficulty identifying an unseen speaker, need to encourage participants, limiting
the conversation using round-robin technique, importance of mute, checking for
any agreement or disagreement
How Agile helps address these challenges within all the Scrum ceremonies
Single backlog for multiple teams: Different skill sets in the team
are needed to deliver user stories that are available across each
distributed location.
Release planning: The number of sprints to map out and use with a
"look-ahead planning technique" will depend on sprint length,
dependencies, and the needs of the teams involved.
Manage dependencies within the teams: Agile teams will not try to
account for every possible dependency at the start of the project but will
look ahead two or three sprints to ensure that teams are ready to deal
with dependencies, using the INVEST model.
Risks: During the release plan, the PO will want to identify the risks
associated with the project and teams, and, when possible, the
mitigation plan for each of them.
Coordinating Agile and non-Agile teams: Making sure the nonAgile team is aware of the priorities of the Agile teams and keeping
dependencies visible can help to prevent blockers between the teams.
First level of sprint planning: The PO and SM will use a screensharing tool to display the vision, sprint goal, user story, the estimates
the team provided, and the acceptance conditions for the user story.
Sprint Planning
helps the team to take a guess at how much work they can do within the
sprint.
Identifying tasks: The PO gives the team time to think about the
tasks needed to complete the work items during the sprint planning
meeting. Teams run planning meeting discussion among all the
stakeholders to get maximum clarity on the tasks.
Distributed
Daily Scrum
Meetings
Keeping the team engaged: Possibly the best way to stay engaged
and to make sure that others on the team stay engaged is: awareness.
Build awareness of what the team is working on.
o
o
Taking daily Scrum notes: This helps the distributed team members
overcome language problems, plan, and learn. Chat Tools and Wiki help
distributed teams do daily Scrums.
Collaboration
within a Sprint
Continuous integration: This is the key to delivering stable, highquality code consistently and quickly, which results in reducing time to
Report any build failures to the team: Allows the distributed team
to know the current state of the code in the integration branch of the
source control system, generating a notification email for build success
or failure.
End-of-Sprint
Reviews
Scheduling for teams with overlapping work hours: Make sure all
team members of the distributed team, regardless of the time zone, can
complete their work and prepare for the demo within overlapping work
hours.
Retrospectives
meeting productive.
Conclusion
Distributed teams need to go for mandatory training to run into full-fledged Agile teams,
so that they can better understand the potential impact of making the change. Although
the project teams learn from adjusting to distributed Agile teams, it becomes more
important for them to understand and adhere to Scrum, rather than immediately thinking
that Scrum needs to be changed.
I believe that collaboration becomes highly important in distributed teams as they are
collectively responsible for delivering on their commitments. One important key to
success in managing distributed teams is to have a high commitment level from all team
members, and the best way to get that is to give them ownership over how they will
work.
Another key to embracing a self-managed distributed team is valuing the entire team
and not having an "us versus them" atmosphere between different Scrum teams on the
project. The best ways to build relationships within teams is to find ways to share the
pain of being a distributed team; to get to know each other as people; and to foster
frequent, quality communications between team members.
Another way to introspect distributed team management is to use sprint retrospectives
to see what the teams are doing and whether their methods of communicating are
working for them. When they need to adjust, they should do so as quickly as possible.
I must say the teams with members distributed across sites can enhance code
ownership and improve the autonomy essential to team self-organization. Automated
communication of product and sprint backlogs throughout the organization, combined
with upward reporting of teams' status to management, can tightly align and knit the
distributed teams together. - See more at:
https://www.scrumalliance.org/community/articles/2013/july/managing-distributedteams.aspx#sthash.Ee4lMaQq.dpuf
Distributed Teams
There are many different experiences and pieces of advice with regard to distributed
teams, and most deal with how to get the communication to work in the best possible
way within the given parameters. Active use of electronic aids such as Skype,
Communicator, SharePoint, etc., are often recommended to ensure good
communication across borders and time zones, and to remove some of the
disadvantages associated with having a distributed team.
There is a common perception that the co-located team is better positioned to ensure
good communication and deliver more efficiently than distributed teams. But in a world
where global collaboration becomes increasingly common, teams often consists of
people from different parts of the world working together as distributed teams. And with
this, it is interesting to note that while there are some clear challenges with having a
distributed team, there can also be some advantages.
A distributed team can be cost-effective. This can be manifested in the form of reduced
travel costs and the use of resources from countries with lower labor costs. Traveling
can be replaced with efficient work, and the reduced travel load in itself can be a
motivating factor for many.
A distributed team can also provide access to higher skills, because you do not have to
limit your resource search to a specific area.
In some cases, having a distributed team also enables some team members to sit
together with customers in multiple locations. Some also claim that distributed teams
are more focused on information sharing within the team -- but then again it can also
make the communication more formal, with the advantages and disadvantages this may
cause.
But there are obviously some definite challenges with having distributed teams. One of
the most important lessons is to not manage a distributed team as if it were co-located.
It is crucial to be aware of this and to address the obstacles that the team will have to
deal with in terms of communication and cooperation.
Many development practices (e.g., from Extreme Programming) stipulate rules for
teamwork, and it is important not to ignore such practices just because we have a
distributed team. If your current situation makes it impossible to follow a defined
practice, you should either modify or replace it with something that works better within
the given situation. The key is to make sure that you are aware of the purpose of the
practice, and make sure that an alternative or replacement provides the same benefit.
For example, pair programming can be replaced or simulated by performing code
reviews. User stories can be written out in even greater detail to make up for some of
what you'll be missing if you cannot have the same degree of conversation within the
team during a planning session. Dont get me wrong -- I would never state that this is a
good substitute for conversation, but I use this example to show that, even in cases
where we can't follow the very core beliefs of the Agile Manifesto (interactions over
tools), we should still make some effort to improve the situation.
Another challenge with distributed teams is that we often fall for the convenience of
assigning tasks based on the team's spread. This can result in specializations within the
geographic locations, and so we create dependencies between these locations. This
could greatly reduce the team's ability to complete a function within an iteration.
Actually, studies show that such negative effects increase with the size of the team. 1
Some would argue that it can be impossible to avoid such situations. Sometimes all the
experts within a specific field are in just one of the locations, and therefore it's not
appropriate to allocate this expertise to the other locations. Such discussions will always
be based on the different experiences of different people, which may not be directly
comparable.
A person who claims that ensuring competence distribution across locations makes
sense probably is quite right in the circumstances he or she experiences. Maybe much
was to be gained from having a cross-functional team just because in the given case
there were many dependencies across tasks. Or because the duration of the delivery
was so far out that investment in training and transferring skills was actually quite
reasonable.
A person who claims the opposite, who simply does not see the point in having a crossfunctional team, will also have experiences that support this. Maybe it was a short
enough delivery duration that it didn't pay to drive knowledge transfer. Maybe there were
more people at a given location with the same skills and therefore they were not so
dependent on one individual. Perhaps the dependencies across tasks were so small
that it worked just fine to have different expertise in various locations.
Most people, regardless of experience, will agree that there will always be an advantage
to having a cross-functional team. The intention behind this principle of Scrum is that
you should avoid dependencies on individuals and make good decisions based on
discussions among several people who have expertise in an area.
But ultimately it must be taken case by case, and you must observe and evaluate what
makes the most sense in the given situation.
In a global setting, language itself is another challenge within distributed teams, as are
different working hours (time zones) and especially cultural differences. In Scandinavia,
many people believe that we are more practiced at enhancing collaboration and that our
style is more inclusive compared with, for example, the U.S. Meanwhile, a leader in the
U.S. might find it easier to confront employees whose performance is inadequate, which
many executives in, for instance, Norway are reluctant to do. In Asia you are keen not to
lose face; in Saudi Arabia, it is disrespectful to sit with legs crossed and show the soles
of the feet; in Russia, an inclusive leadership style is perceived as a weak leadership
style.
There are countless examples of cultural differences, but what does this mean in the
context of securing communication within a distributed team?
Despite all these cultural differences, we humans are very similar when it comes to
relationships with others. It's primarily about building trust by respecting others, with
words and actions that are in relation to each other.
All functional teams should be based on these principles and, therefore, establishing
these principles is perhaps the most important thing one can do to ensure that team
members have the opportunity to build this basic trust in each other.
This is in no way an attempt to argue that the Scrum itself is the solution, but the
principles that the framework is built on will help keep a focus on the key factors that, as
experience shows, are important for efficient distributed teams. Again, back to the
eternal mantra that should form the basis for all Agile development: Understand the
intent of the framework and established practices, base them in reality, and make
adjustments so that one can achieve the intention.
Conclusion
In distributed teams with different nationalities, it is wise to be aware that people have
experiences and expectations based on other traditions. Generally speaking, it is often
also wise to be open to other ways of doing things. But the basic expectations of trust
and cooperation are largely the same, regardless of borders and frontiers. A very good
rule of thumb is to always have more questions than we have answers. Acquire more
information while avoiding coming across as arrogant and as having all the answers.
The information you'll gain will support broader and more informed decisions and assist
everyone in making the right decisions.
When it comes to having a distributed team, then, it's primarily about building trust and
having mutual respect for each other, along with a common focus on communication
and as close a collaboration as possible.
It's difficult to give one-size-fits-all advice, but I hope the areas discussed form good
suggestions as to what can and should be focused on when working with distributed
teams. In practice, the world is such that no project or team is equal, and you have to do
assessments and make decisions based on the assumptions that apply to the
appropriate team. In its simplest form, it's about communicating, observing, and
reacting.
Resources
1
Craig Larman and Bas Vodde, Scaling Lean & Agile Development. Addison-Wesley
Professional, 2008.
2
Dr. Niki Panteli, lecturer in Information Systems, School of Management, University of
Bath. (Link to survey: http://www.ariadne.ac.uk/issue43/panteli)
- See more at: https://www.scrumalliance.org/community/articles/2013/august/distributedteams#sthash.cwLlNA7M.dpuf
frequent code reviews with peers and other subject matter experts, and
facilitate live demos during the sprint review. Distributed development
teams should also carve out time after each sprint or some other
consistent cadence to review communication practices, tool usage, and
other project protocol. It is important that all teams do this, but even
more so for distributed teams.