Jan 2006

Moving targets and the benefits of agile development

I’m working on a site at work that had a reasonably well laid out specification. At face value it seems like a pretty straightforward online shop, but when you delve deeper the complexity just keeps unfolding: different user types, wholesale accounts, special cases and little flags here, there and everywhere… A few weeks have gone by and we’ve made some important decisions about how things are going to work. It was OK though and we’ve got a nice user, products and permissions system in place. Everything was going to plan. Then we met the client again, partly to re-confirm some functionality. The project has undergone a meteoric shift, with most of the important parts having some major changes and more than half of the work so far has been made obsolete. Now, while this is without doubt a change to the original spec (and we can therefore re-spec and re-quote the work) it’s still incredibly frustrating to see wasted time and code.

Such massive spec changes are thankfully pretty rare, but it does highlight the inefficiencies in our traditional approach to developing applications and I’m wondering how much of a difference a more agile approach would make. Would showing initial builds of the application to the client much earlier and more often have caught these changes before now? I believe so. This may sound like we have some real problems with our approach, but I don’t think it’s really all that different to the large majority of other web development companies out there and, for a lot of projects, it works pretty well. Also, while we’re definitely becoming more convinced that it’s a better way to develop, implementing a more agile approach isn’t all that straightforward. It requires a big shift in attitude and process and I’m not sure there’s much value in trying to move over incrementally. Like any large change, there is some risk involved.

While our actual programming processes are improving all the time, one of the next, and possibly biggest, hurdles is getting over the fact that we would need to show clients not just unfinished code, but barely started code – and that’s intimidating! As developers, we’re happy working with a really empty shell of a site, understanding that it actually works much better under the hood than it appears and that making it look really nice is a pretty straightforward job. But would our clients understand that? Or would they just think it’s crap, freak out and get all jumpy? My own opinion is that they’d be quite happy with it, but probably only after having it all clearly explained to them – which makes this a client management problem as well as a technical one. Another aspect I haven’t quite got my head around is how quoting for work fits with the agile approach. Historically, I find accurate quoting difficult at the best of times and I’m keen to learn how it fits with the agile idea of being adaptive and reacting to change rather than predictive.

I’m not sure what I’m saying here other than “I think agile approaches are better and I would like us to move that way, but I realise it’s not as simple as just making a decision”, maybe I’m just thinking out loud.

Leave a comment

You must be logged in to post a comment.