Agile for Geographically Distributed Teams

Agile is really become a standard approach for most companies, yet few if any have great success when distributed teams are involved (which is also a standard for any mid size or larger company).   One of the core foundation techniques that Agile employs is that in software development project teams collaborate across all disciplines of experience.   This collaboration is particularly important when we consider the practice of iterative planning and development.   For distributed teams this calls to question the effectiveness of the communications used to support the team’s collaboration, and tracking.   Documentation is not the strength of many (noticed I did avoid saying “Any”) organizations.  Additionally most Agile training and best practices include the use of things like “Scrum” meetings, often better facilitated in co-located facilities, and daily stand-up meetings, which all support the continuous integration of team efforts which place geographically distributed teams at a disadvantage.

So how can an organization that has realized the potential of collaborative, agile techniques maintain those benefits when the team becomes distributed?

 

In part this answer is done within the structure of the Agile approach itself.   In that the work for Software development projects are structured, and collaborative, with some use of tools to support collaboration, documentation, which may need to be an added specialization as part of the team, and development of collaborative culture across the distributed team as a primary goal.  This collaborative team culture, team consistency, and management of shared work products become focus areas.

How to foster a collaborative team culture?

This can be partially answered by some of the pointers I’ve done in a previous blog on my personal site in managing a distributed project team.  But in summary the culture needs to maintain parity for team member locally to the management of the team.    This means if there is a team event like out for a dinner, or recognition of members that these extra motivational events always include the remote / distributed team members.   additionally consider the use of tools to aid communications, things like a collaboration site, video conferencing, IM, all improve communication.   Make sure project documentation and communication plans are detailed beyone the typical project expectation.  Things like holiday schedule for (remote site’s need to include multi national and cultural holidays)   additionally things phone numbers which include instruction for making international phone calls should also be included.    I have an additional whitepaper on this subject directly and can be reached at 219.629.0662 should you need assistance locating this.

 

Maintaining consistency on approach and deliver with a collaborative team and culture of highly effective communications is the next challenge.   The value of the “Individual” and interactions of Individuals over the processes and tools is very important for Agile teams.   Defining processes, and frameworks, along with training and review’s which identify and teach greatly enable individuals and interactions for distributed teams.   RUP provides a process framework of software development, a basic standard notation with UML, and an approach to communicating the process practices to all team members.   Training along with review and demonstration based on the reviews in a positive re enforcement manner is always highly desired for this.    The use of assigned mentors is also another positive mechanism I’ve seen be extremely effective here.

 

But, how to Manage the development of shared work products?  Although a defined process with a common language and approach can assist determining the activities of a distributed team the volume and complexity of work to be performed can still be overwhelming.   This is complicated by the fact it’s almost impossible to have real-time collaboration on deliverable shared across the distributed team.  Focus efforts that ensure all outputs from any team member are accessible by any other team member at any given point in time.  One of the simplest methods of doing this is a simple repository of the central common files, documents, guides, plans, and code.  With simple governance structure on identification on when, who, what, for each item.   Just be sure to accommodate the budget need to publish, govern and track items in the repository for the project team.   This simple miss in terms of estimation will begin to result in people short cutting the process which is critical to the overall team effectiveness.