Best Practices for Distributed Agile Development:

Introduction:
Software development in a distributed environment is not new and has been in practice in
the IT industry since the 80s and 90s when IT offshoring became prevalent. Due to global
market competition and realization of economical workforce offshore resulted in enormous
cost arbitration to global IT companies.
Traditional approaches to offshore development are based on plan-driven methodologies
with big-bang deliveries. In Agile development, this needs to be adjusted to support faster
delivery cycles and enable highly collaborative environment for multi-site, multi-vendor
development teams.
This article analyses and recommends best practices for globally distributed agile teams
based on Brillios experience of working with large financial, Products and Technology
companies in implementing their business critical projects through distributed teams
working from multiple time zones and locations.
Distributed Scrum Teams:

In The 2013 State of Agile Development survey, conducted by VersionOne, 76% of

respondents stated that their teams were distributed. This being the state of the
industry, distributed agile software development is here to stay.

Distributed scrum teams go through the following stages of evolution:

1. Isolated Scrum Teams
Teams are isolated across geographies. Distributed teams may not be using common
processes or tools
2. Distributed Scrum of Scrums
Scrum teams are isolated across geographies and are integrated by a scrum of scrum
which meets regularly or has conference calls regularly
3. Totally Integrated Scrums
Scrum teams are cross-functional with members distributed across geographies and
there is common processes and tools usage. Frequently there is rotation of team
members across the teams

Challenges in Creating Integrated Scrums:

Following are the challenges our teams implementing distributed development have
experienced during their implementation and the resolution techniques they have adopted.

Customer Collaboration and understanding business priorities

When development teams are collocated with the customer, it is easier to
participate with the customer in backlog grooming and understand the business
priorities. When the teams are distributed understanding the business priorities of
the customer and ensuring that the teams pick up the right stories for development
and synchronizing the dependencies among multiple teams is a big challenge. In
one of our projects for a large financial industry customer we mitigated this
challenge through having a technical architect and business analyst at each location
to understand the requirements and priorities from customer and represent and
translate the same to local teams through discussions. Having this proxy team
represent as local Product Owner helped clarifications to teams and enhancing the
bandwidth of customer Product owner.

Organization of the teams

While organizing teams and distributing work, it is important to form teams based
on functionality and not as component teams. Forming component based teams
leads to isolated teams and brings in localization of skills. This builds a dependency
bottleneck sometimes.
For example, in a project for developing a health information system for a global
medical company, we had segregated the teams based on components/modules.
This was leading to delay of releases as all the teams had to wait for one of the
teams which worked on the server side business objects to complete their
implementation to be even able to make a meaningful release. This created a

bottleneck. Later, we reorganized the team to be structured based on functionality

and this helped building cross functional skills and alleviating this dependency. If
any one of the team was delayed, other teams could help in completion of the work
as skills required were now not localized and multiple teams were having these
skills.

Cultural differences
It is very important to understand difference in behavior of team members
belonging to different cultures when we are working in a distributed agile
environment. Some cultures are inherently adapted to hierarchy and command
control environments where people are often discouraged from asking questions or
bringing out issues, talking about impossible deadlines or saying No when
something cannot be done. To effectively be agile, this kind of attitude should be
overcome and a culture of openness, and trust needs to be built. This needs a good
amount of team building and travel to be planned. We have been able to address
this through rotation of team members through various locations and teams. This
helps them become ambassadors of teams and helps in developing working
relations across geographies and building cohesive teams
Communication across Distributed teams:
In a distributed environment, importance of constant communication and
collaboration cannot be underestimated. Sufficient budget need to be invested in
building the backbone for communication and usage of wiki, group chats, frequent
calls, desktop sharing and application lifecycle management tools like TFS, JIRA,
VersionOne should be encouraged.
In one of our engagements, we co-invested with customer in setting up a state-ofthe-art Video conferencing environment dedicated in their ODC (Offshore
development center). This helped the team in getting a virtual feel of collocation to
discusses issues face to face and deliver faster
Knowledge Sharing and collaboration:
In agile development, in the rigor of sprints and work completion, knowledge
sharing across teams sometimes suffers. To ensure this does not happen, daily
synchronization calls between the teams need to be religiously followed. Daily
scrum of scrums should become a constant practice, this helps in working around
dependencies and ensuring that the teams are not blocked. A blocker tracker needs
to be maintained which daily gets discussed during the scrum of scrum meeting and
resolved.
Integration of work done (Continuous Integration)
As multiple teams are working sometimes on the same code base it is imperative
that a version control system and continuous integration environment be set up for
the teams before the start of development sprints. Continuous integration is not
only about setting up an environment for continuous integration but also to

cultivate the sense of urgency to resolve issues on build failures. Many times we
have seen that teams set up a continuous integration environment but do not really
give the necessary focus to fix build issues on priority. This attitude needs to be
changed by constant tracking of the cycle time for build issue resolution and
reporting it back to the team. Continuous integration is the discipline of ensuring
that all the teams are working on a deployable codebase every day. This helps
moving towards continuous deployment and devops best practices.

Best Practice Lessons Learned:

Conduct proper due-diligence to understand the overall scope, domain and product
Plan for a Sprint-0 (Preparation sprint) before the delivery sprints start.
Separate teams by functionality and not on activity or components. This helps
creating self-organizing and self-sustaining teams in case of attrition and other team
organization changes
Ensure Development and System testing environment are setup and ready for use
before start of delivery sprints
Develop anchor stories and categories to classify High, Medium and Low complexity
stories to have a rigorous size estimation practice in the team
Use continuous integration practices to minimize integration issues later in the
project lifecycle
Project manager and Scrum master to work with Product owner to crystallize release
plans for at least two cycles before the commencement of sprint-1
Plan travel for teams to send ambassadors from each team on rotation across to all
geographic locations. This helps in understanding problems/issues first hand at each
site and in building trust and collaboration among teams
Use regular builds to get feedback and integrate work among multiple teams if a
continuous delivery strategy cannot be worked out
Use test cases to understand the requirements upfront. Bring in a Test driven
development culture
Ensure transparency to customer through periodic reporting and monthly governance
calls
Strengthen retrospective, continuous learning and innovation

Summary:
Distributed Agile Development is here to stay. Organizations have to develop capabilities in
effectively leveraging this model for effective Software delivery. There are challenges in
creating integrated scrum teams and the root cause for all these challenges point towards
the basic tenets of strengthening the Communication, Knowledge sharing, understanding
the culture differences and building cohesive High Performance Teams which are key to
success in the continuously evolving technology and software engineering world.