Making it work
Using Agile in combination with offshoring may seem counterintuitive. However, in our experience, adopting Agile methods with their emphasis on clarity, transparency and communication may in fact reduce some of the risks inherent to offshore development. In particular, things like Continuous Integration, Burndown Charts, Project Backlog, Planning Game, and some other practices and tools can actually mitigate such typical offshore development issues as configuration management problems, inaccurate and disconnected estimations, and decreased visibility into project status.
Our team has been doing offshore Agile development for almost a decade. We have successfully delivered many dozens of Agile projects with distributed or fully remote development teams. We have had to learn to deal with such challenges as distance and time difference. We have also learned to apply elements of Agile in client engagements with traditional project lifecycles.
Agile emphasizes co-location for a reason: having all team members in the same room together facilitates the ongoing communication and the exchange of tacit knowledge that is so critical to Agile. With Agile teams that are remote or globally distributed, we can significantly reduce the impact of the physical distance through extensive use of multiple means and channels of communication. In addition to email and various collaboration and issue tracking tools, our teams use wikis, instant messaging, and Skype, including video calls. The ability to instantly ping a counterpart in the remote location makes distributed work surprisingly smooth.
Daily standups (scrums)
The daily standup meeting (or scrum) is an invaluable practice that allows teams to sync up and communicate the progress developers are making, as well as any impediments they run into. On a distributed Agile project, where the customer representatives are in a different time zone, we often run two standups a day: one local and one cross-shore (or global). The timing of the global standup, which includes the customer representatives and is usually done via a conference call, depends on the client’s time zone: for example, if the client is in North America, it is usually done late in the afternoon, after the client’s team has come in to work. We also augment the global scrums with the extensive use of wikis and other collaboration tools to help share the captured information.
Regular builds to get feedback on functionality
With a co-located Agile team, the close proximity between customer and developers allows the customer to monitor progress frequently and to spot misunderstandings more quickly. With a remote team, having regular integrated builds allows the customer to pull down the most recent work and try it out. While not as immediate as co-location, this practice still allows the customer to catch and correct any misunderstandings in a timely fashion. We also highly recommend doing a demo, or a showcase, at the end of each iteration (for example, remote teams can show the new features in the software via a desktop sharing platform). This is also important from the standpoint of building links between offshore and onshore, and between developers and customers.
Since the offshore team is typically unable to locate a business customer willing to play the role of onsite customer, establishing some type of “proxy customer” (in Scrum terminology, “proxy product owner”) may be a good idea. Often a good proxy is not necessarily someone experienced with the domain, but rather a person with a combination of interests and abilities in both technical and business sides. This proxy customer must be able to interact and communicate equally well with the technical and business project members. On larger projects that have a team of proxy customers/analysts, it may be useful to have a blend of onshore/offshore resources playing this role, along with some kind of “analyst exchange program.” This kind of cross-functional collaboration is essential to the success of an agile development team.
Expect more documentation
Although Agile methods emphasize ongoing communication over documentation, producing documents becomes more important with offshore development, since the face to face communication is reduced. That’s why offshore Agile projects typically see more documentation than co-located Agile teams. Writing formal documentation should be supported and augmented with more active collaboration tools (e.g. wikis or issue tracking systems). We always try to make sure there is sufficient active communication about the format and templates of the documents, and that there is feedback about how well they are working. It is best to allow the structure of the documents to evolve over time as teams learn to work better together and are fine-tuning the process.
Not Agile? Not to worry
Our objective to produce the absolute best software possible for our clients, working within the existing budgets, timeframe, and organizational culture. Therefore, if you are not using an Agile process, but are ready to outsource anyway, First Line is still a good candidate to consider. We fully understand that different methodologies suit some types of projects and organizational philosophies better than others. Still, even if your SDLC is closer to traditional than to Agile, we are confident that we can improve the overall productivity and quality of your development by selectively applying certain elements of agility. Our experience shows that the following general principles can positively affect almost any process:
- Continuous improvement through time-boxed, iterative deliveries and review
- Implementation of the most important (valuable or risky) items first
- Constant collaborative communication
There is also a number of specific Agile practices that can bring improvement to the lifecycle. To use the RUP terminology, they can be used both the elaboration (for example, the “speclets/scenarios”-based approach we borrowed from Behavior Driven Development) and the construction stage (Extreme Programming-inspired techniques like Test-Driven Development, Continuous Integration, Pair Programming, etc.).