|
|
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.
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.
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.
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
|
|
|
|
|