but then weeks into the project, given the time zone differences they morphed into 2-4 meetings a week and became more detailed information exchange sessions. We were successful in applying the Scrum concept to distributed onsite teams but these took a different shape for the onsite and offsite team interaction.
Detailed velocity measurement – In the spirit of trust but verify the project leveraged detailed development velocity metrics to report progress. This metric was updated weekly and reported on actual development progress versus planned progress. The metric used iteration plans created by offshore team and reported progress and calculated schedule deviation on a weekly basis. Using a fast paced iterative / incremental approach put a higher onus on control metrics. The rigor applied in planning and reporting was much deeper and, contrary to conventional wisdom, more rigorous than traditional waterfall development tracking. Not only did we track features developed, tested, delivered, and components developed, tested, delivered, but we also were constantly juggling resources to maximize iteration throughput. This focus on delivering maximum functionality each iteration helped the team stay on top of their game right from the very beginning versus the old waterfall approach where things often start slow and then pick up as phase deadlines near.
Continuous Integration and Automated Regression Testing – This practice probably provided us the biggest bang for our buck. Code that was developed from multiple locations was checked into a single repository and a build was generated every night. We used a rookie (fresh graduate with no business background) to develop automated regression testing scripts. We started slowly (as iterations progressed), creating a suite of test scripts that validated key functionality to ensure that the build was functional. This practice saved us from putting bad broken code in front of the client and helped develop trust! We truly started living up to their expectations.
Paired Programming – While financially it's a lot easier to implement paired programming offshore than onsite, we did not do this all the time. We cherry-picked assignments that were more complex and had higher impact and assigned paired teams. We particularly remember one complex component where we were able to develop with very high quality in 1/3 of the scheduled time. This had never happened before. Over a period of time this turned out to be a great blessing as the job market in India was sizzling hot. Developers acquired good skills and then flipped jobs for a 25% pay raise. Our paired programming approach helped retain some of our background and experience. If we had to do this over, we probably would have had a higher percentage of paired programming (but still not do the whole project that way). Our experience is that not all team members are crazy about this approach, this is a team sport and ‘super stars' and ‘MVPs' do not fit well.
Retrospectives from iteration – Given the newness of the approach; we periodically sought input during iterations and again at the end of the iterations to collect and apply lessons learned.It helped us identify not only micro level process and resource adjustment opportunities but also macro level dynamics and motivators that then helped influence a new delivery culture. Moving things early in the lifecycle forced issues and failures earlier on and helped us fine-tune and adapt while we still had time to recover. Our lessons learned ranged from: identifying true productivity rates, getting a much better feel for our resource capabilities, understanding our bottlenecks, etc. Perhaps the best thing it did was to provide the team a sense of purpose, an opportunity to make