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 61 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
Advertisement
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
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.
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.
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.
About the Author Peter Vaihansky is the Vice President of StarSoft Development Labs. With headquarters in Cambridge, MA and development centers in Eastern Europe, StarSoft provides software development outsourcing management expertise and services to global US and European companies including: Computer Sciences Corporation (CSC), T-Mobile, IBM, Fellowes, Contex, ScriptLogic, WebSideStory, and others. StarSoft specializes in applying Agile methodologies (XP and Scrum) to distributed, offshore software development projects.
Error, missing joomlaboard config file!
Comments (2)
vaihansky: ...
Vikas,
Thanks for the comment. This is the response from one of our engineers:
The team structure stated in the article is not a must. It greatly depends on the project size, project context and the level of access to internal processes and resources given by the customer to the outsourcing company (the level of integration).
Commonly in our projects all the software stakeholders can be divided into three levels:
1. The customer. Generally this is the business that will benefit from the applications delivered. This level was not depicted in figure 1. 2. The customer software team. This is the left part in figure 1. This team is the customer for the outsourcing development team. 3. The outsourcing development software team. This is the right part in figure 1.
This segregation influences:
1. The communication between the business and the customer software team being territorially integrated (the face to face meetings can be arranged as frequent ass necessary and at low cost). 2. The communication between the software customer team and the outsourcing development team being experienced in software development (talking the same language).
For this model, it seems reasonable to have the OPM as the representative of outsourcing team and being responsible for development, and to have the TIL (sometimes this role is called “Delivery Manager”) as the representative of overall integrated team reporting the progress to the business. Keeping in mind that the TIL and OPM works in different companies, being granted different security levels of access and having different ways of “getting extra resources if necessary” there are no duplication of responsibilities.
The status tracked by OPM and TIL differs in the time scale. The OPM reports the status to TIL on a daily basis. And the TIL reports to business at the end of each iteration (by presenting demonstrations of the growing system) or by delivering the system by the deadline and within the budget planned.
Generally the project context dictates the necessity of having the Enabler role (sometimes this role is called “Technical Project Manager”). This can be the case when the project really is a subproject of a bigger one. In this case there are several applications developed concurrently. They all may share the single domain model and depend of the same set of back-end systems. For this situation the Enabler participates in the project to subprojects decomposition and tracks the system integration from its parts. Also he tracks that all the components follow the same standards of coding and architecture guidelines.
In other situations there can be security restrictions that protect the outsourcing company accessing the back-end data sources. In this case Enabler is responsible to provide scrambled data to developers.
Taking into account stated above, the Enabler and Technical Leader responsibilities are different in “system integration” scale (like OPM and TIL responsibilities are different in “time” scale).
The reason that the OPM assigns tasks for team members is the necessity for tracking that the XP principles and values are followed. Especially the economics and mutual benefit principles as well as feedback value. He/she supervises that choice of tasks for development takes into account the interests of all project stakeholders (customers, developers, testers).
The diagram in figure 1 is a “common” one. This means that some roles can be omitted for specific projects. E.g., there is no need of BPM for a small project or the TIL and Enabler for low-touch outsourcing or internal projects.
In our projects we try to follow the Miller rule (7±2) for the development team size (right part in the diagram). If the project requires bigger team, we try to split it into two smaller but more manageable subprojects.
1
February 16, 2007
Vikas Hazrati: ...
Peter this is a good article, I had some comments / observations
Somehow the process that you mention seems to be too process heavy. There seems to be too much duplication of responsibilities.
1. I see TIL supervising the staffing process and the offshore PM(OPM) getting the team together on the basis of resouce pool available.
2. Both OPM and TIL track the status of the project. I do not see why both the roles are required, not one.
3. The Enabler (E) does the product metrics, this should be done by the developmeht team and should not be something which is done at a different location from where the development is happening. This is something which can be easily done by the Tech lead and most of this can be automated.Comments?
4. Again creation of technical stories is being done by the E, but this should be done by the team working on the story.Comments?
5. I see the OPM assiging tasks to the development team members, this does not look right, why dont the team members pick up tasks on their own from the pool of tasks?
6. There seems to be a lot of hierarchy in the diagram, is it for depiction of roles or is it hard implented?
7.What is the general development team size for your project?
Articles 
