Managing Offshore XP Teams: Organizational Models and Tools

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.


Organization
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 role).
• Cannot be BPM or BA!
• Supervise the team staffing process.
• Track progress of the entire project.
• Make sure that all resources (environment, documentation, back-end access) are arranged and made available to the development team.
• Get external resources (e.g., a stress testing team), as necessary.
• Make sure that all questions are answered in timely manner and that the documentation is updated accordingly.
• Arrange and participate in release planning sessions, planning games, and daily Scrums.

The TIL deals strictly with the technical and organizational side of the project, leaving the issues related to the business logic to the BAs and the BPM. This is to ensure that the BPM is focused on getting the requirements right 100% of the time and does not have to be distracted from communicating with the development team for non-essential, administrative tasks.

Enabler Responsibilities:

• Participate in the project feasibility study preceding the project.
• Review user stories and creates technical stories.
• Provide proper interfaces and stubs to back-end systems.
• Review the source code daily and checks compliance with architecture standards and coding guidelines.
• Check product metrics (unit test coverage, automatic unit test coverage, cyclomatic complexity).
• Help the development team by answering difficult technical questions and suggesting better solutions.
• Participate in release planning sessions,planning games, and daily Scrums.

The enabler acts as the first filter on the customer side. He receives the daily build from the StarSoft team and deploys it in the client's integration environment (which emulates the production environment), since the offshore team is not allowed direct access to the client's highly sensitive environments. He also performs code reviews to make sure the team follows coding and architectural guidelines. In short, the enabler's responsibility is to ensure the code's consistency and to make sure the business analysts can proceed to test the system's functionality. More often than not, a separate Technical Data Analyst (TDA) is working alongside the enabler and takes care of the database side of things.

TDA Responsibilities (when present as a separate role):

• Create technical stories relating to databases.
• Provide the necessary schemas and data of back-end databases.
• Review DDL, DML, and query scripts.
• Perform load and stress testing, if necessary.
• Help the development team by answering the difficult technical questions and suggesting alternative solutions.

StarSoft has delivered projects to many internal customers within the client's organization in the UK, Ireland, Israel, USA, and Russia. Due to the global nature of the client's organization, the BMP, TIL, Enabler and the development team can be in different countries for the same project.

Project Manager's responsibilities:

• Put the team together from the available resource pool, based on the requirements of the project at hand. Serve as the central communication point to the client.
• Sort out everything that can potentially decrease the team's velocity.
• Arrange and participate in release planning sessions, planning games, and daily Scrums. Write and circulate minutes.
• Participate in estimations; track status.
• Gather questions and forward them to the client, receive answers, and discuss them with the team.
• Arrange standup meetings, and make sure that everyone has his/her daily tasks assigned and that the tasks are clear.

The project manager staffs the development team and acts as the central communication conduit to the customer. On a daily basis, he or she runs the morning standup meeting to kick off the daily "mini project." Right after that, the PM proceeds to collect the questions from his team, answering the easier ones and consolidating the rest into the daily email to the client's analyst team.

In the middle of the day, the project manager holds the daily Scrum telephone call with the customer. Normally, we funnel the communication between developers and the customer through the PM: if each team member communicated with the customer directly, the customer could be flooded by duplicate questions or by questions that can be easily answered by the PM. However, team members may also take part in the Scrum. For example, in the case of a complex technical problem, StarSoft's Tech Lead will speak directly to the Enabler on the customer side. Immediately after the Scrum, the PM holds the second stand-up meeting for the day, passing back the answers he received during the Scrum call.

Tools: XP Matrix

 Figure 2: Screenshot from StarSoft's XP Matrix

One of the things that stands out about StarSoft's XP projects is the universal use of the tool we have termed XP Matrix (see Figure 2). This Excel-based tool was born from joint efforts of StarSoft's engineers and the customer. It is used for tracking the project on the level of iterations, user stories, and tasks. The tool also keeps track of the team's velocity and load factor, and provides daily extrapolations based on the accumulated data. The stories' completeness is tracked on the daily basis, and color coding of stories and tasks gives the manager a clear at-a-glance view of how far along his or her project is.

On the screenshot above you can see the Iteration Track (bottom left) where the iteration is tracked based on Work Complete (the magenta line), Work Left (blue line), and Instant Team Velocity (green line). The point where the magenta line and the blue line separate indicated the moment when a change request was introduced (little yellow square on the burndown chart, bottom right). The horizontal axis on the track chart represents planned effort. The magenta line (Track Upon Work Complete) running above the axis means that the team exceeded the amount of work initially planned for the iteration. The blue line (Track Upon Work Left) hitting zero at the end of the graph means that the team completed an additional change request without moving the original deadline.

In the recent months, a group of our engineers has been working on the implementation of a standalone tool that contains all the functionality of the Excel tool and improves on it, such as adding data validation, providing greater usability and advanced budgeting functionality, and shortening the learning curve for new managers

Summary: Key Take-aways 

1. Face to face communication is important. Over time, we have moved to holding planning games on the phone rather than face to face, for economic reasons: it can be expensive to send a team of three to five managers from Ireland or the UK to Russia for up to four days. Although phone planning games are cheaper, it is still advisable to hold at least the first planning game face-to-face with the client. It's less likely that questions will be asked during telephone planning games than in face-to-face meetings, which can result in more errors, more bug fixing down the line, and ultimately more expensive projects. Another reason why a face-to-face meeting is important (at least once per client - we work with multiple groups and departments within the client company) is because the personal connection made at the first meeting makes subsequent communication much more effective. So in the long run, face-to-face planning games may still make economic sense.
2. Separation of roles. Having the Enabler, TIL, and BPM/BA as separate roles really helps with the focus and the efficiency of communication. This requires a certain degree of dedication from the client. In our case, since we have no direct access to the client's integration and production environments, there really was no other way but to work through an enabler. The separation of the TIL and BPM roles is really helpful in focusing people's energies on the right things.
3. The right tools will help tremendously. Tools provide the much needed daily visibility into the project for the management on the client side, enabling them to truly harness the power of XP. This is especially critical if the development team is located offshore.