Offshore Agile Maintenance
Following is an experience report summary that I have submitted for Agile 2006 Conference.
Intent
The intent of this session is to share my experience working as a tech lead and a part time Iteration Manager on an offshore agile team maintaining and enhancing a business critical application for a client in New York from Bangalore.
Summary
Predominantly the Agile literature covers applying the values and practices to a green field project using a co located team. However, offshore/distributed development is the reality of the software industry. Offshore organizations have started with maintenance of non critical business applications and moved over to green field development of business critical applications in a distributed fashion. Maintaining and enhancing business critical applications is the key to an organization‘s success.
The existing literature states the following as challenges with distributed/offshore team:
1. Decrease in communication bandwidth
2. Lack of visibility into project status
3. Configuration management
4. Art of Command and Control structure
5. Cultural difference
But based on my experience the above points are byproduct of something more important. The root causes according to me are the following:
1. Lack of trust
2. Loss of context, both business and technical
3. Offshore team/s not getting equal stakeholder status
4. Abstraction of business and technical problems and decision
In this discussion I would like to explain how we address the above issues and turned a failing project into a success story. I would also like to present some tweaking that we did to the standard XP practices to embrace change.
Intended Audience
Any one who is interested in offshoring their projects. Though the discussion will be focused on maintaining and enhancing business critical application using Agile values, I‘m sure some of these values and practices can help other distributed team.
Project background
The project was developed by our US counter part in 2001 to 2003 for a pay per view cable company. This was an EAI project for a back office data validation and billing system. It also had components of the J2EE stack for presentation. During the initial development of the project some XP practices were used on the projects. After this phase, the US office maintained the application for a few months and then on the client decided to maintain the application themselves. A year later, the client got back to our company asking us to maintain the application. But they did not have budget for a two to three member team working from US. Hence it was decided to offshore the project to India. We had a new team of two developers, a QA and an Iteration Manager on the project. We also had an Account Manager in the US. The team spent 3 months in US for knowledge transfer and then started working from India. From the client side we had three people, one QA, one DBA and a PM in New York. This was a one year maintenance contract.
The project itself
During the maintenance phase, the team applied most of the XP practices. Following are the list of practices used:
1. Planning game : 2 week iterations, story cards, Iteration Planning Meetings
2. Small releases : 2 weeks to customer and 2 to 3 months into production
3. Refactoring [40 to 50%]
4. Pairing Programming
5. Collective code ownership
6. Continuous integration/Automated Release
7. Test Driven Development [40 to 50%]
8. 40 hour week / sustainable peace
9. Standup meetings
What we did not have or could not do yet were:
1. Onsite Customer
2. Metaphor
3. Simple Design
4. Coding standards
5. 100% Automated testing
My observations on the project
1. Lack of trust is the most important challenge. Working with a team, sitting on the other side of the globe, with whom you have never worked before, leads to this challenge. If the client and the development team could trust each other, then communication and visibility would not be such a big issue. Also having a trusted self organized team can eliminate the need for command and control structure. Building trust takes time, but should be the highest priority for the team.
2. Loss of context is the second most important challenge. People think waterfall is the best model for distributed maintenance teams. This is based on the classical misconception that staging-out the development process will yield better control and visibility. But stating leads to loss of context. If one does not understand what business problem they are really trying to solve, it can be very difficult to deliver the right solution. Most often in a distributed project all the decisions are taken onsite and the offsite teams are ordered to implement the solution given to them. Implementing the solution without the technical and business context is a big red flag. This can lead to over engineering or under engineering based on time frames available to the team.
3. Not considering offsite teams as equal stakeholders in the project is a recipe for disaster. One of the biggest misconceptions is that offsite team members only care about their pay cheques. Based on my experience I can tell, they care, if not more, at least as much as the onsite team about successful delivery of quality software solution.
4. Classically people try to address the communication and visibility problem by having one point of contact and building a tower of hierarchy. With experience on agile teams, it is clear that you need a team of motivated people communicating all the time.
Learning
The project was setup for failure and we could not continue in the same fashion. Some of the things we tried on the project, which helped are:
1. Retrospectives created a nice platform for the team to vent out their feelings. After expressing their frustrations, the team could think constructively. Involving the client in retrospectives gave them greater visibility.
2. Giving a lot of freebies to the client. Initially to build the trust, we did go out of our way to help and please them.
3. Building a personal rapport with the client helped us understand them better.
4. Acceptance testing with FIT gave us a nice unambiguous automated tool to communicate with the client.
5. Dev and QA pairing and QA smoke tests on developer machines helped in faster feedback.
6. Fully self organized team talking to the customer directly gave all the team members a better perspective of the project
7. Client driven demos on the developer machines every day was a great way to win client‘s trust and get feedback.
8. Involving the client: Daily status mails, Project Wiki in client environment, IM conversations, IPM and lots of informal communication. People on the team used to rotate on these tasks. This helped everyone on the team feel special.
9. Lots of outings, parties, icecreams, food, etc. Life is worth enjoying it. This helped us address the stressful nature of fluctuating workload
10. Pairing and SCube [Seek, Speak and Share] session to spread domain knowledge.
11. Refactoring fest to mercilessly refactor the legacy code base
12. Constantly monitoring the unit, functional and regression test count as a measure of progress
