Managing Offshore XP Teams: Organizational Models and Tools

The essence of Extreme Programming (XP) is making the customer a part of the team who works very closely with the developers, ideally communicating on a daily basis. However, what about a situation where your development team is offshore? Is it possible to have the best of both worlds, realizing the gains of offshoring without losing the benefits of XP? How do you keep the momentum and the communication flow going, at the same time ensuring seamless integration of the deliverables into the customer's production environment at the XP pace?

This article will cover four years of cooperation between StarSoft and one of its major customers, a leading computer chip manufacturer. In this period of time, StarSoft has delivered sixty-one successful projects to the customer, with five more currently in development, utilizing XP exclusively. We will discuss the organizational model, roles, and responsibilities used in this highly successful relationship, as well as the tools used to monitor and manage the projects daily.

Offshore XP: Why Even Do It?
The reasons to implement XP projects with an offshore team are the same as the reasons to use XP at all:

  • Lower risks. By implementing XP properly, you can truly control your development spend by getting daily estimations of how far your allocated budget will take you in terms of implementing the desired functionality. We will go into a little more detail on {sidebar id=1} that later when talking about management tools. In short, what you get is a "fixed price, variable scope" situation, with very close control over how every dollar is spent.
  • Scope prioritization and early release of the core functionality. These are as essential as they are self-explanatory.
  • Possibility to throw in changes as you go (as many as possible). It is the projects with highly fluid requirements that especially benefit from XP. The cost of change relative to project phase is linear here rather than exponential as in conventional projects. This is where such XP practices as "no design in advance" and "keep it simple" really add value.
  • Projects can be started with a minimal set of requirements. Of course, ideally you should have user stories, story tests and mockups, but this is not a must. Clients can kick off an XP project without the long preliminary phase of requirements preparation. We have had cases when all we had from the client at the start of the project was a single page with brief user stories, and we could still start working productively from that, while the client further defined its requirements iteratively.

Obviously, doing XP in an offshore situation presents a set of challenges. It is not possible to implement some of the XP practices in a distributed manner (for example, you can hardly imagine pair programming by one developer in Russia and another, say, in Ireland). However, by setting up a proper organization, you can still reap the benefits of XP even when working with a remote team.

StarSoft and its client use a clear organizational structure to run multiple offshore XP projects (see Figure 1).


              Figure 1: Offshore Agile Project Team                                    

source: StarSoft

Let's go over the roles and responsibilities on both sides.

Business Project Manager (BPM) and Business Analyst (BA):

  • Carry out business analysis and prepare prioritized user stories and story tests.
  • Allocate the project budget (BPM).
  • Answer business questions and update the documentation.
  • Provide early feedback for completed stories. Verify implemented stories.
  • Open, prioritize, and track change requests and defects.
  • Participate in release planning sessions, planning games, and daily Scrums.

The business team drives the story creation and prioritization. Stories and subsequent change requests are consolidated and channeled to the development team through the BPM. The business team's main task is to be responsive to the development team, answering questions early and often, thus enabling the development team to move quickly through the implementation of stories. As the development team delivers its daily builds, the business analysts also continuously verify that the functionality implemented by the developers is really what the business wanted.

Technical Integration Lead (TIL) Responsibilities:

  • Keep the balance between the development team and the customer (moderator


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.