I read a very interesting post from one of the founders of github.com who had heard a great metaphor for Agile development;
Imagine you’re tasked with building a computer controlled gun that can accurately hit a target about 50 meters distant. That is the only requirement. One way to do this is to build a complex machine that measures every possible variable (wind, elevation, temperature, etc.) before the shot and then takes aim and shoots. Another approach is to build a simple machine that fires rapidly and can detect where each shot hits. It then uses this information to adjust the aim of the next shot, quickly homing in on the target a little at a time.
The difference between these two approaches is to realize that bullets are cheap. By the time the former group has perfected their wind detection instrument, you’ll have finished your simple weapon and already hit the target.
In the world of web development, the target is your ideal offering, the bullets are your site deploys, and your customers provide the feedback mechanism. The first year of a web offering is a magical one. Your customers are most likely early adopters and love to see new features roll out every few weeks. If this results in a little bit of downtime, they’ll easily forgive you, as long as those features are sweet. In the early days of GitHub, we’d deploy up to ten times in one afternoon, always inching closer to that target.
I then realised that is how I have been building my-tracks.co.uk recently, deliberately firing many bullets and watching visitor trends but not by design – meaning I hadnt planned on using any development methodology but decided I needed a few goes to hit the right product. I still haven’t reached that finished site, not sure I will, there will always been improvements and features added and I may not stick with the Agile, scattergun approach but for now it fits. And I guess thats the point, you should choose a methodology that does fit with 1) your customer, 2) the product – one methodology may not be the best choice for all projects and should be made on a per project basis rather than enforcing the projects to fit the methodology.
With my-tracks.co.uk, I had a list of improvements and features added, bugs to be fixed, just prioritised them and then went about implementing them whilst pushing every couple of weeks – I would normally do it every few weeks when I a stable release. Somethings worked, some didnt – I think I redesigned the search solution several times and still not 100% happy, but I just kept trying. I think website customers respond to seeing a developing site too, I want to see a site improving and constantly changing, hopefully to meet my needs.
