• Time-boxed iterative development - We broke our delivery into six iterations, each six weeks long. These iterations contained requirements (typically one iteration ahead), design, development and testing activities. At the end of six weeks, the code was delivered into a user test environment. Our users were now able to play with the system and provide feedback as early as 4 months into the project. (This typically would not have happened until 10 months into the project.)  We had succeeded in moving things earlier in the lifecycle. We would have preferred shorter iterations. This was an adjustment we felt we had to make given the team's lack of experience and the distributed nature of our development. Even if we wanted to deploy iterations in production, we could not have done it since the first release of our software (being done by a separate team) wasn't ready to go live.
  
  
• Lean management, self contained and empowered teams - The team was split into three functional teams, with some onsite and offsite component. The onsite team provided requirements, training and management leadership while the offsite team provided design, development, and testing leadership. For the first time, offshore teams were now empowered to plan their own assignments. In the past, this typically was decided by an onsite manager. The three offsite functional teams reviewed the use case catalog and identified components to be designed / built / tested within iteration. Components that were not completed at the end of the iteration moved into the next iteration. The offshore team had greater control of their destiny, and was able to make necessary adjustments at the right time. This gave the team a feeling of having ‘skin in the game' and increased accountability.
  
  
• Scrums - Given our distributed delivery environment, we used two streams of Scrum. The first one focused on all onsite team members. We had two onsite centers: Columbus, Ohio and Santa Fe, New Mexico. For many months we held teleconference meetings every business day at 7:00 pm EST.  Our goal was to over communicate in the beginning and then tone down subsequently. The 15 minute teleconference call focused on "What issues are holding you back?", "What have you accomplished today" and "What are you planning to do tomorrow?" Respecting people's time, we stuck to our 15 minute commitment. The expectation was for the team members to hang-up after 15 minutes and that if we could not manage a 15 minute Scrum on a daily basis then how could we possibly manage six week iterations? We must say, except for handful of situations where we sought team's approval to extend the 15 minute meeting, by far a vast majority of our meetings got done in 15 minutes or less. The second Scrum stream focused on interaction between onsite and offsite members of functional teams. We were very ambitious in our thinking that these would be daily and structured, 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 a difference and an incredible team experience that years later some of us still have very fond memories of.
  
  
• Test driven development - Our development team was required to create unit test plans prior to starting development. This was a new concept to the team members, who would rather have jumped into coding. While the offsite development leads oversaw the process, the onsite team had visibility into the repository where all work products were saved. The developers reviewed the use cases/design and created unit test plans that were reviewed by their leads prior to starting development. This was especially beneficial for junior developers who had little business background.

Comments (0)

Write comment

Show/hide comment form