Principles of Distributed Agile

With ever changing business requirements, Agile methods are widely used among organizations to pursue their project goals. In last decade, agile has produced favorable results for software development and testing. Agile has also been adopted by large software projects located in multiple geographies. Under such distributed environments, where project teams are not co-located and/or come under different reporting lines of the organization, distributed environment comes as a challenge.

In this article, I am going to capture the approach and management required to deliver superior software quality even when teams are located in different regions and time zones.

Before we go into the details lets quickly recap on reasons why agile is adopted for a project:

  • Ever changing requirements
  • Respond quickly to changes
  • Rapid delivery of working software

The primary assumption in agile approach is that all team members are co-located. In real world, this is not always possible considering operational costs, talent concentration or resource availability. This poses a threat to agile philosophy of building trust and rapid interactions by creating mis-communication, loss of information, delay in trust building and incomplete handovers. So how should management take up these challenges.

Process or steps to be identified before the project inception:

Step 1: Identify the additional cost/time of distributed environment

Cost in a software development team is directly related to the time put in by every team member. In a co-located environment major portion of this cost is development efforts. In case of distributed environments equal amount of cost is shared by development efforts along with communication and integration efforts. 20-30% of more time is required for team meetings or other meetings to keep all the teams cohesive as co-located. You may also need additional tools and training on those tools for technical overlap between the teams or may be even for instant communication between the teams.

Step 2: Create a sense feedback loop within the teams

One of the key challenges found with distributed teams is loss of information or inability to create a feedback loop. This may be due over-reliance on specifications defined at the project inception level. Team should be encouraged more to interact internally and with product owner to define specifications at the iteration level. This will avoid a false sense of security and encourage them to interact internally.

Step 3: Create an overlap between the teams

Office hours overlap should be created between teams located in different geographies. I have been a member of a team covering USA, Canada, Australia and India. It was a major challenge to cover office hours however not impossible. You can delegate responsibilities depending on the scope and nature of project of each team.

Creating a cultural awareness is also important in a team coming from different backgrounds. Team members from different regions may have varying levels of skills, expertise and communication in common language, failure to do which causes class system that hinders collaboration.

Step 4: Technical view points

Teams coming from different regions or working on different part of product may have different preferences  for technologies. They should be aligned during the initial phase of the project through a central decision making on the choice of technologies to enhance collaboration

Step 5: Visibility and Transparency

In co-located teams, visibility and transparency is brought forward through daily stand ups, white boards or charts. However in distributed teams Real-time online tracking tools, Online process dashboards should be used to replace above artifacts.

Steps necessary during the execution of projects in distributed environments:

1. Create multiple communication channels

This will enable redundancy within the communication however will ensure minimum loss of information or mis-communication. For eg. Status Updates and Task commitments can be handled via one channel with Scrum Master whereas design and technical communication can be handled through other channel with the technical leads.

2. Disciplined communication plan

The overall communication plan should be robust, to avoid finger pointing or creating false assumptions. Also this plan should be followed in a very disciplined fashion. Eg. Sending out emails after reaching every conclusive point is a robust communication plan. Sending out in a properly formatted template is a discipline that team needs to follow to avoid mis-communication.

3. Strict definition of done

Definition of done should be defined in more details compared to one defined for co-located team. This will ensure the teams will not need to receive late night/early morning confirmation calls.

4. Shared electronic work spaces:

Personalized SharePoint site and project dashboard can be set up for all the updates about work and teams, contact information, status updates, announcements, discussions and documents. Mutual calendars can be established so that everyone is aware of all the local and offshore deadlines. A common IT infrastructure can be established to make use of the shared work space.

Some of the tools for your reference are:

  1. Wiki : MASE, PMWiki, MediaWiki. (Utilizes web technology to publish, manage, integrate and distribute agile planning information.)
  2. Web Based Application: Sharepoint, Rally, VersionOne, Scrum Works, XPPlanner, Mingle
  3. Board Based Application: AgilePlanner, MS TFS, Danube, CardMeeting (Uses visual representations adopted by agile methodologies)

5. Continuous Integration

Importance of continuous integration increases with the size of projects. Teams should be groomed to focus on building scenarios rather than components. This will help in creating a better sense of ownership. Have working software tagging as “Draft Version” vis-a-vis “Release Version” to set expectations and enable early feedback  after integration. Simplify change management process. Teams are already in a hyper-excited mode and a complicated change management process increases the chances of errors.

6. Work distribution

The major challenge with distributed teams is work synchronization. So work should be distributed between teams based on scenario or feature rather than discipline like QA/Testing, Management, Development.

To conclude, Agile development processes in a distributed environment depends on having the right blend of people, right skills, & right roles. With these and leveraging the proven agile tools and techniques, distributed projects can obtain incredible benefits in terms of cost and time management, productivity, risk minimization, improved quality. Agile methods can prove to be of great competitive advantage by simplifying communication, reducing the time-to-market by facilitating the business, as it can respond quickly to the changing requirements by changing the software.


1 Responses on Principles of Distributed Agile"

Leave a Message


March 2015
« Sep