Programming in Bed 05 November 2003
keywords: blog, dispersed agile development, distributed agile development, DAD, extreme progamming, agile methods, design
I went to the BCS OOPS talk by Allan Wills in London. Before being recruited by Microsoft, he and John Daniels founded "Fastnloose", a company pioneering dispersed agile development. It seems to have turned out a lot better than I thought it would.
Immo Hüneke has published comprehensive notes, which are available from the BCS OOPS website.
Some selling points:
- Customers won't have to find facilities for the programming team on-site.
- Network-based projects can use tools like sourceforge to make project state much more visible to managers. [Let's hope this won't tempt them to do micromanagement.]
- Although not strictly dispersed agile development (one team, each member separated), practices like test-first development and continuous integration can be used to integrate work done by distributed teams. This could be enough to make outsourced work agile.
Some downsides:
- You can almost do distributed pair programming with Terminal Services but they tended to do this only for short periods of time. Then they work apart and join up later to review the work. Swapping "drivers" usually means getting the changes you've made onto your partner's computer. Currently this is inconvenient. (You wonder why they don't check-out from a well-known tag, and email across a patch of the changes they've made since that tag.)
- It can be difficult to get customers and external collaborators to do encrypted email and firewalled VPNs.
As far as social patterns go they:
- They have a daily conference call with the whole development team.
- They work on-site with the customer in the early days, until the scope of the work stablises. [Nobody said what would happen if the scope doesn't stablise.]
- Hire your mates: They only hire former colleagues and co-locate apprentices, so they know each other pretty well.
Alan Wills said that customers were more surprised by staunch adherance to test-driven development than by the dispersed development. When you think about the way most developers work, perhaps that's not surprising.
