Home | Services | Events | Features | Interviews | Profiles | Reviews | News | Resources | Press


Posted: Mon, April 19, 2004

Distributed Agile Development

By Dafydd Rees

What does "Agile" mean?
Practical considerations for distributing agile development
Conclusion

Agile methods for software development seek to provide a simple, working system as soon as possible and to evolve that system through continual customer feedback based on personal communication. These techniques place a high value on face-to-face communication. This presents a challenge for businesses that wish to reap the benefits of distributed development.

Distributed development isn't a new thing. Many large software systems are developed across multiple sites. For example several teams working at different locations may be working on different parts of the same software product, perhaps with an integration team somewhere with the responsibility of overseeing the assembly of each part into a cohesive product.

The overwhelming majority of software produced in the open source world is created by individual hobbyist developers working from home offices or student terminal rooms. This type of development is characterised by the fact that almost every developer is physically separated and that a small number of trusted developers are responsible for integrating submissions from a wide pool of contributors. These trusted developers effectively work as editors deciding which submitted "patches" to accept, and they decide how each accepted patch will be worked into the released product. The developers rarely meet, and integration of each patch or commit happens relatively infrequently, certainly by extreme programming standards.

The multi-site corporate development effort and the typical open-source project are only two examples of distributed development. There are a number of different possibilities, each one driven by different motivations. These can be roughly categorised as "distributed" or "dispersed" development.

Distributed development : This usually means co-operation between several teams located at different sites. This includes large software companies developing a single product out of many parts where each part could be built at a separate location. Oracle Corporation does this with certain products. This classification also includes efforts where the bulk of the work is outsourced to developing countries with a small team of consultants working on site with the business stakeholders.

Dispersed development: Dispersed development refers to individual developers located separately, working together over a network. One company consisting of a small group of experienced developers decided to work from home using high-bandwidth connections. This was essentially a lifestyle choice. Some companies prefer to hire contractors that work from home, so that they don't have to provide office facilities for them during the project. Another example of dispersed development includes forming project teams of specialists that would be too expensive or impractical to relocate to a single site project room.

What does "Agile" mean?

Unfortunately, the term "agile" has become a synonym for "good" in the software business. Nowadays there are even television adverts that use phrases like "fabulous toys for the agile business". In this article when we refer to something as "agile" we mean that it promotes the values of the agile manifesto:

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
(c) 2001, the above author this declaration may be freely copied in any form, but only in its entirety through this notice."


This manifesto emphasises an approach to software construction based on craftsmanship, face-to-face learning and interpersonal skills. Many vendors and consultants want to productize their tools and services. The danger here is that an attempt to productize an agile methods approach would codify the practices in place today without preserving the attitude, values and the thinking that led to those practices in the first place. Finding a genuinely agile development team is difficult and it's also difficult to learn agile methods through any technique other than apprenticeship.

The agile manifesto also mentions, "responding to change over following a plan". Whilst we can understand that well-specified, fixed scope could be outsourced to software houses in developing countries without too much difficulty it's unclear how less well-defined, changeable projects could be completed in the same way. By contrast, agile methods provide means for managing these less well-defined, changeable projects by producing working software frequently and allowing the customer to steer the project through frequent feedback. Several companies have already started developing methods that combine agile methods with outsourcing.

Over the course of the last year or so, published work has appeared about several, different distributed agile projects. Most of this work has centred on derivatives of the eXtreme Programming (XP) and Scrum agile methods.

Practical considerations for distributing agile development

In November last year Allan Wills, formerly of Fast'n Loose, a company pioneering dispersed agile development gave a talk to the BCS Object-oriented Special Interest Group. He described a number of techniques used in his dispersed agile development projects. In this section we'll review a number of practical considerations that were raised in his talk along with some observations from my daily work as a practising extreme programmer working in a team that's beginning to collaborate closely with other teams around the world.

Communication
Good communication between all participants is vital in all agile methods projects. In order to kick-start the project Fast'n Loose works on site with the customer during the initial stages of the project to get to know the customer and to build a shared understanding of the project. This makes it easier to build the trust and understanding necessary to work at a distance. Another important point is that Fast'n Loose hired friends and former colleagues so that although the developers wouldn't work in the same room, they already had the advantage of knowing each other very well. Apprentices are co-located with experienced developers for a few months so that they can learn the method directly from an experienced developer.

Security

Many customers of agile projects are rightly concerned about confidential data and intellectual property. Fast'n Loose use broadband routers that have a VPN feature to create a secure, private network shared between the dispersed development team and their customers.

Remote Collaboration

Most agile methods emphasise concrete, low-tech face-to face collaboration methods like status reporting at daily stand-up meetings, a project status notice board, and "user stories" written on index cards. These low tech, face-to-face techniques are simple, fast and have very little management overhead. Many people new to agile methods fail to see the value inherent in the directness and simplicity of these low-tech methods.

In a distributed environment, these face-to-face mechanisms must be replaced with some kind of server set aside for common file storage, web-based collaboration and a private instant messenger service. Typically, the web-based collaboration will involve discussion forums and some form of project planning and tracking tool.

Setting up a distributed project of this nature clearly requires more technical facilities. Rather than buying a notice board, pins and index cards, you now have to take time out regularly to administer a discussion forum and a messaging server.

According to Allan Wills, this can be turned into a selling point: Replacing significant amount of informal, face-to-face communication with web-based discussion software has the advantage that the customer can be given a much better picture of the state of the project. However, some extreme programmers have criticised this point because most of the communication between developers is about development issues rather than business ones. Extreme Programming sets out a "developers bill of rights" and a "customers bill of rights". Exposing too much development information to customers may tempt them to start micromanaging developers.

Code Repositories
A source code control system like CVS, Subversion or Perforce is a requirement for all professional software development projects. Installing CVS on a dedicated server may suffice for a small team, even for a small, dispersed team. Take into consideration the volume of network traffic and scalability of your source control system in an environment with large numbers of users, or systems that require synchronisation across continents.

In one project it took four hours to synchronise a developer workspace in Washington State with a CVS server in England. Given that a typical extreme programmer would expect to release code every fifteen to thirty minutes, requiring synchronisation, catch-up, build and a commit, a four-hour catch-up is clearly unacceptable. This problem is thought to lie in either in network connections or in the VPN encryption infrastructure. Some source control systems like Perforce provide proxy servers that can reduce the volume of traffic required between remote sites and the server location. This issue clearly can't be ignored for big distributed development efforts.

Conclusion

Agile methods can provide a competitive advantage by delivering early, simplifying communication and allowing the business to respond more quickly to the market by changing the software. Trying to distribute a development project in an agile way isn't easy and will involve compromises. However there are a number of benefits that can be gained both for the enlightened businesses and developers. Perhaps the most interesting outcome is experience at Fast'n Loose where the customer was more surprised and impressed by the thorough use of extreme programming-style unit and functional testing than the dispersed development.

References

Rees, Programming in Bed, http://www.dafydd.net/blog/entries/20031105.html
-- My account of the BCS Object-Oriented Special Interest Group Talk "Programming in Bed" given by Allan Wills last year.

Fowler, Using an Agile Software Process with Offshore Development, http://www.martinfowler.com/articles/agileOffshore.html
-- How Thoughtworks does Agile Offshoring

Massol, Agile Methodologies in Offshore Development, http://www.theserverside.com/talks/library.tss#massol
-- How Pivolis does Agile Offshoring (Webcast requires Internet Explorer and Media Player.)

Distributed Development, ACM Queue, 1(9), December/January 2003-2004
-- This entire issue of Queue addresses distributed development though most of it isn't specifically concerned with distributed agile methods.)

The Agile Manifesto, http://www.agilemanifesto.org
-- The official website of the Agile Manifesto

About the Author

Dafydd Rees is a developer specialising in Object Technology. He welcomes feedback at http://www.dafydd.net/feedback.php





Home | Services | Events | Features | Interviews | Profiles | Reviews | News | Resources | Press
About ITWales | Archive | Privacy Policy

All material on this website ©2002-2009 ITWales
spacer

Search ITWales

Advanced Search
envelope Subscribe to
ITWales Updates
Click Here!