I was recently asked to give a talk on innovation, agile, and offshore development. The first two topics are ones that I talk about on a regular basis, but the last one required a little extra thinking. Many of the articles I’ve read on agile, offshore development have focused on the communications, collaboration, and culture and how each of these is more difficult in an offshore development project. However, I think these are issues for “any” offshore project — agile or otherwise.
There are a number of practices and tools for improving distance communications and collaboration — collaboration tools (e-mail, discussion groups, IM, telephone, video conferencing, document sharing, cross-site visits, and more). Companies are putting into place distributed, integrated development environments in which teams can work on the same code base no matter where they are located. But all these things can be used in both agile and traditional (serial) development projects.
So what are the factors that would make agile better or worse for offshore development that also had an innovation component? An innovation component means that the technology might be somewhat leading or bleeding edge for the team and the requirements might be subject to change and evolution as the project unfolds (I’ve labeled these high uncertainty and risk projects as high exploration-factor projects).
First, as the exploration factor goes up, there is a far greater need for constant feedback — trying things out and seeing if they work (technologically) and if they deliver value (to the customer).
Second, as projects become distributed, control always suffers. For example, as a project manager, it’s one thing to receive a status report from a local group that you can wander over to and discuss status with and another thing to receive a status report from a group 8,000 miles away. Verification is much more difficult.
Looking at just these two factors — feedback and control — agile development would appear to be a far superior model for offshore development. Specifically, the iterative and feature delivery aspects of agile methods greatly enhance these two factors. Taking two points on a spectrum, let’s evaluate the feedback and control aspects of a waterfall project. Typically, the preponderance of the customer’s (one source of feedback) interaction with the team comes during requirements specification at the beginning and then acceptance testing at the project’s end.
The customers, other than with prototypes used during requirements analysis, don’t have an opportunity to see partially completed applications, learn from interacting with them how those features work, and provide timely feedback into the process. Similarly, technical work such as architectural and design decisions are not tested until near the project’s end. In iterative, agile development, both customer and technical feedback happens over the course of a few weeks rather than after months. Feedback is more frequent and more relevant in an agile project.
Second, management control over traditional serial projects is task and percentage completion based — i.e., the requirements specification phase is 45 per cent complete. It is very difficult to verify real progress because managers only have someone else’s opinion about how complete the project seems. Furthermore, until actual modules are coded and tested, status reports often proved illusory.
On an agile project, after an initial iteration 0 for planning, requirements analysis, feature identification and release planning (this iteration may last several weeks given the nature of distributed projects), the project team delivers done-done features every two to four weeks. Done-done, as a client defines it, means that the development team is done with the feature (specified, designed, coded, unit tested), and the customer is done with the feature (acceptance tested). From a management control perspective, would you prefer a status report that says 46% of the documentation for requirements is complete, or one that says that 46 per cent of the identified features for the application are done-done? Agile projects provide for better control — which is especially critical on distributed, offshore projects.
So if we have subscribed to the idea that agile is a better way of developing software in a collocated group because of better feedback and control, shouldn’t the answer be the same for offshore development? Of course communications and collaboration is harder, but it is also harder for a traditional project. It is actually because communications and collaboration is harder on an offshore project that feedback and control issues are so critical.
Quick feedback and verifiable results are critical to the success of offshore projects, especially those with higher exploration factors. The agile model is just as suited, if not more so, to distributed, offshore development as it is to collocated development.
– Jim Highsmith is director, of Cutter’s agile project management practice
