Taking Agile Offshore
Companies today are attempting to lower costs and increase staffing flexibility by taking some, or even all, of their development activities overseas. Many of these same organizations have teams that are using agile development practices in an effort to increase quality and improve project performance. Some teams might find themselves in a situation where they didn’t choose to take their teams offshore; but that decision was, in fact, made for them.
What happens when these two trends in our industry intersect?
There are tools and techniques that you can draw from agile that are essential for any kind of offshore endeavor. Development practices such as test driven development, continuous integration, and pair programming can be a powerful risk reduction mechanism to ensure the quality of your product and reduce uncertainty.
Defining requirements as user stories, building out thin slices of the product, and frequently reviewing those features with the customer can go a long way to making sure you are building the right product. Using these techniques help mitigate timeline risk because the product is always in a nearly releasable state. Daily stand-up meetings, sprint planning, and sprint closedown provide essential visibility into the development process and create an environment where you can inspect progress and adapt based on that feedback.
You never get too far off before you have the opportunity to adjust.
Teams working across dramatically different time zones, separated by thousands of miles, are going to need more documentation to stay in synch. There is not enough communication bandwidth to keep everyone busy and on the same page. Documentation needs to be viewed as a means of communication and not the deliverable. It is overhead. Keep doc as simple as possible to get the point across. Having a solid architectural description, very specific story descriptions, and clearly articulated acceptance criteria are key.
You’ll need to adapt some of your agile leadership philosophies to accommodate the unique characteristics of your offshore team. You might have to take a more prescriptive approach as the team is coming up to speed. Not everyone may be culturally ready to accept the level of responsibility that agile requires. You may need to have a senior team member hand out stories, rather than having the team self select, to accommodate background and experience.
Be intentional about these deviations and have a coaching strategy for moving team members where you need them to be.
Taking an agile approach to offshore development is going to expose you to more junior staff than you might be used to working with. The market, especially in India, is very tight. As developers gain experience, many of the best people will move into management. You may experience 2-1, 3-1, or even 10-1 productivity differences between your more senior onshore guys and the offshore team.
These differences, coupled with increased documentation, increased communication delays, increased management and tracking burdens, and increased coaching overhead; create a much more complicated financial picture than just hourly rate. Using offshore talent will result in increased working hours and increased demand on the capability of the onshore developers. If cost savings are your primary driver for going offshore, you might want to look very closely at the numbers and measure if you are really getting the savings you expect.
The hourly rate is not all you need to take into consideration.
If you have had a different experience with agile in an offshore model, please feel free to comment, especially if you disagree with my conclusions. If you are a developer working for an ‘offshore’ outsourcing firm, please let us know if you think these experiences here are typical. Do you have any thoughts on how the typical offshore relationship will evolve, over time, as rates and technical experience go up? These are all interesting questions.
I will be sharing an experience report with the community at Agile 2008. If you feel strongly about these topics, please come find me. I would love to hear how using agile with an offshore team has worked for you.
Comments (3)
kishorekumar62
I am not an Agile fan myself, but I did interact with one Agile company in Bangalore which I was very impressed with: Valtech
These guys have figured out Agile offshore (Scrum offshore to be specific).
Gilda Villaseñor, QAM at Scio
I’m a member of a Nearshore Agile development team. We have been using Scrum to manage the development project, and it has result very well. Our Customer, my team and I are very pleased because we are enjoying the benefits of the agile management. Even when the Agile development management has given us a lot of advantages to improve the way we create a SW product, now we are moving forward to adopt Extreme Programming practices to enrich our SW Engineering practices aligned to the Agile development. The success that we have achieved to develop a SW product with the agile practices is due the following key success factors:
• Since we are a Nearshore provider (located in Mexico) we have the same or very close time zone as our Customers. This has allowed us to have direct phone conversations with our clients during their business hours.
• The Clients have understood the Agile processes we are following, and sometimes they even have contribute to enrich our practices.
• The clients are committed to their product, they understand their role as Product Owner, taking the ownership of their responsibilities and providing prompt answer to our questions and constant feed back to the whole team.
• We have established an Internal Product Owner role within the Nearshore team, this person is in charge to create the detail user stories where business rules, data validations, acceptance criteria among others are established. All detail user stories are reviewed by the Team (developers and testers) before they go back to the Client Product Owner. Once the detailed user stories have been created and reviewed, they are validated by the Client Product Owner in order to approve business rules, and provide answers to the team to close any gap before the user story is ready for development. And I have to say that this is a process that occurs parallel to the Development and Quality Assurance processes of the current sprint user stories, new user stories are being detailed to be ready at the beginning of the following sprint.
• Developers and testers are involved since the creation of the detail user story, by doing a review of the document, this allow them to be aware of the incoming changes and to provide feedback since the technical and quality stand point.
• Every end of sprint we have practiced the retrospective meeting where we review the team performance and process and look for ways to improve. During this meeting we identify specific actions that are implemented right in the incoming sprint. This is one of the Agile practices I like the most, as a Quality person I’m always looking forward for the continual improvement and this is a very easy method to ensure every time we do our work better to deliver better results.
There are some other factors that have been in place in order to achieve a good adoption of the Agile practices in the Nearshore development, whoever, I consider the most important the ones I mentioned above.
Offshore Software Development
Good info post. Thanks for sharing this blog.