Agile Offshoring
Agile by concept is co-locating all the three legs of the IT organization the business, IT and QA. However with more and more organizations doing offshoring to optimize cost and getting the best talent across the globe it has become a challenging transition from traditional enterprise development processes into an Agile methodology along with geographically split teams with various time zones. Traditional approaches to offshore development are based on plan-driven methodologies and doing agile is definitely challenging. Because agile development works best with close communication and an open culture, agilists working offshore feel the pain much more than those using plan-driven approaches.
Locations
We have implemented Agile Offshoring for both development and QA teams spread across Reston(VA), Kansas(KS), Bangalore (India) and Gurgaon (India) for a major communication client.
Methodology
We follow SCRUM Agile process with two week sprints and a production release atleast after two sprints. We do not do any new development/stories seven days before the release date to accomodate 5 days of regression test and 2 days of code lock. This helped us to have stable releases to production.
Setup
Initial set up was challenging more from ramping up the teams with the business domain knowledge as well as application design. One of our team members spent about three weeks in Bangalore with precise daily schedule for knowledge transition and also travelled the technical lead from Bangalore to Reston. Meeting people in real life helps to know each others working style and it eases the virtual communication downstream.
Velocity
It took us some time to measure the velocity of the new distributed team as during the transition it was low however we strived to keep up with the velocity. Once the team members returned to their original locations and team ramped up decently on the functionality the velocity picked up. Initially we started with low priority work and bug fixes to get team moving on understanding the code. I would say we are operating at about 80% of the velocity compared to when the entire team was colocated in Reston.
The most critical element of this is the feedback loop. We used to change something or experiement it and find out how it went than learn from it and again change something else. We used to keep the feedback loop as short as possible mostly an iteration so that the process can be adapted quickly.
Communication
One major question was how to integrate the two development teams together for the design sessions. We started a daily stand up call within the development teams to allocate tasks and get on to the same page as to what is delivered or being worked on for the next day using microphone and live meetings. Once the initial design has been completed the developers used to get it reviewed in the morning meeting by doing a code touch point walkthrough including what he/she is planning to change. However instead of 15 minutes these meetings run about 30 minutes to an hour depending on what is being discussed on the call.
QA
To bring the testers also on to the same page with the daily changes, we used to update the notes section of the Stories with the properties/parameters which the tester need to know for doing the data preparation. We also used to have an automated mail sent to all stake holders whenever there were changes to the stories after certain point in the iteration. We used Version1 to manage our Stories.
Knowledge Base
We used Wikis to document and store the knowledge of the module design after the coding is complete. Created videos of the ramp up by module so that developers can walkthrough the code and also talk on the code design.
All in all it was a great experience and the worries that we had initially went away over the period in time.
Locations
We have implemented Agile Offshoring for both development and QA teams spread across Reston(VA), Kansas(KS), Bangalore (India) and Gurgaon (India) for a major communication client.
Methodology
We follow SCRUM Agile process with two week sprints and a production release atleast after two sprints. We do not do any new development/stories seven days before the release date to accomodate 5 days of regression test and 2 days of code lock. This helped us to have stable releases to production.
Setup
Initial set up was challenging more from ramping up the teams with the business domain knowledge as well as application design. One of our team members spent about three weeks in Bangalore with precise daily schedule for knowledge transition and also travelled the technical lead from Bangalore to Reston. Meeting people in real life helps to know each others working style and it eases the virtual communication downstream.
Velocity
It took us some time to measure the velocity of the new distributed team as during the transition it was low however we strived to keep up with the velocity. Once the team members returned to their original locations and team ramped up decently on the functionality the velocity picked up. Initially we started with low priority work and bug fixes to get team moving on understanding the code. I would say we are operating at about 80% of the velocity compared to when the entire team was colocated in Reston.
The most critical element of this is the feedback loop. We used to change something or experiement it and find out how it went than learn from it and again change something else. We used to keep the feedback loop as short as possible mostly an iteration so that the process can be adapted quickly.
Communication
One major question was how to integrate the two development teams together for the design sessions. We started a daily stand up call within the development teams to allocate tasks and get on to the same page as to what is delivered or being worked on for the next day using microphone and live meetings. Once the initial design has been completed the developers used to get it reviewed in the morning meeting by doing a code touch point walkthrough including what he/she is planning to change. However instead of 15 minutes these meetings run about 30 minutes to an hour depending on what is being discussed on the call.
QA
To bring the testers also on to the same page with the daily changes, we used to update the notes section of the Stories with the properties/parameters which the tester need to know for doing the data preparation. We also used to have an automated mail sent to all stake holders whenever there were changes to the stories after certain point in the iteration. We used Version1 to manage our Stories.
Knowledge Base
We used Wikis to document and store the knowledge of the module design after the coding is complete. Created videos of the ramp up by module so that developers can walkthrough the code and also talk on the code design.
All in all it was a great experience and the worries that we had initially went away over the period in time.
Comments