Agile Experiences
So after a pretty good pitch process I've found myself working with a company called
ThoughtWorks, who are very good at what they do, and rather keen on
agile methodologies.
Agile's an interesting thing. It's got devotees who are nothing short of religious and on account of it's reliance on
eXtreme Programming (XP) practices it's got something of a rebel edge to it. Documents like this
one can be somewhat unnerving at times.
My early experiences of Agile were largely negative, and I assumed that it was a convenient way for programmers to cover up lousy project management and poor client handling. This turned out to be more to do with the practitioners I was talking to being lousy at project management and client handling than any shortcomings of their methodologies. Confronted with problems I'd get the response that 'this is agile' and that I should stop asking inconvenient questions like 'are you doing anything' and focus on the ideas.
My new experiences of agile go a bit like this.
It's not a religion but it helps to be religious about itIf you're going to buy into a methodology buy the whole thing. This goes for business process re-engineering, six sigma quality, Prince 2, lean manufacturing and pretty much every major methodology around. You can't be a 'little bit six sigma', you can't be committed to constant process improvement 'some of the time' and if you're going to run your project on Agile methods you can't expect them to co-exist with more traditional ones.
It's not process or documentation lightIn fact to do Agile properly (and I'm sure we could do it better) involves putting in place a lot more low level routine processes than most software project management. You can't do it without source control, you can't do it without daily meetings, you can't do it without written tests for everything - starting with 'is there a homepage', you can't do it without a great big list of stories which require about as much effort to write and update as any specification I've been involved in.
The difference is that these processes are constant, low level and baked into the way of working. It's not about 'do the process then do the work', it's about 'the process is the work'. I suspect that this, coupled with the fact that Agile forces people to use good programming habits (lots of testing, small chunks at a time) explains most of it's productivity benefits.
It takes good people to stick with itA lot of the discussions about Agile have suggested that it wouldn't work for average or below average programmers. I suspect this isn't true. I suspect that there comes a point where all that baked in process stops looking useful because you know it would be quicker to 'just get on with it'. I think the self control to avoid doing that comes from a deeper understanding of your job and what it involves than most people have - the same thing that makes some graphic designers good and others merely competent, or turns an accountant from someone who can do the books into someone you'd ask for business advice.
Agile is for people who think about how to write good software, not because they're paid to, but because they want to.
It's still too early to tell how this particular Agile experiment is going. So far the signs are good, but it will be a huge amount of work to shift all our projects onto this development process, and Agile is a very intense way of doing things - not necessarily suited to running 8 projects through a team of five or six people. It's also not something all our suppliers could or would want to do. But it's got a lot of potential, and so far I like it.