Agile for agencies

Last week I went to the DevWeek conference at the Barbican Centre. It’s a week of workshops and talks on all sorts of technical subjects, and a great place to gain an insight into new ways of working. The agile software development session got me thinking about how to further adopt the approach at Zone. I’m convinced we could deliver even better software for our clients if we did – but we would need to change the way we work with them significantly.

Our projects, especially big web builds, are usually run on the traditional ‘waterfall’ model – this means the whole project is specified in some depth at the beginning. Work then starts on the design and build stages, before a final stage of testing and client acceptance.

I think there are two drawbacks with this approach:

Firstly, it is hard for us, the developers, to accurately estimate the time that a big software project is going to take. We often don’t really know how long something is going to take until we start digging deeper into the problem and writing code. This can cause problems later on if our estimates vary significantly from the actual time it takes.

Secondly, it’s difficult to accurately capture all the nuances of a big project at the beginning, and often specifications must change during a big project.

From the development team’s perspective, these are good arguments for moving away from the waterfall model. But our clients work with the realities of fixed budgets and timelines. Understandably, they want to know exactly what they’re getting for their money, and are disinclined to accept an open-ended project plan without a firm budget. So we usually include a detailed project specification and breakdown of costs in the contract.

We always try to take the best from various methodologies, and already make use of some of the technical aspects of agile. We work flexibly and react well to change – in that sense we are already agile. But to run a project in a truly agile way means doing away with the big specification document at the start. Instead, we would produce lots of small ‘stories’, each being a simple description of one requirement of the system. These would each go through the full development cycle of IA, design, build and testing very quickly – this means we could deliver incrementally more complete versions of working software every few weeks.

How would this affect our clients?

Firstly, we wouldn’t provide them with a time estimate for the whole project up front. Instead, we would wait until several iterations of work were completed, and then make better informed – and regularly updated – estimates, based on information from actually working on the project. Because detailed specification would take place more regularly on smaller pieces of work, requirements that were not fully understood would come to light faster, since we’d involve the client at every step, rather than at the formal acceptance stage at the end of the project.

We’d be able to react quickly to changes in the client’s priorities, since we would not be locked into a big specification document that has a lot of time and effort invested in it.

The ‘Agile Manifesto’ states that we should ‘Value customer collaboration over contract negotiation’. In that spirit, we should abandon the waterfall methodology and contracts that include a detailed specification, and instead adopt the agile approach.

This would involve a real shift in thinking on both sides. Our clients would need to accept that we would commence paid work before they get an overall cost and timeline for the project. In return, the client would know that when we provide information, it is based on real evidence from the project. They would be able to see small but complete parts of the project within weeks – and reprioritise on a weekly basis, without the need for changes to a contract. This arrangement is a sort of ‘subscription’ model – where everyone accepts the idea that software is never really finished; it just keeps evolving and getting better all the time.

Would it require a leap of faith from a client to agree to this? Possibly – and it’s our job to build the trust necessary for them to make it. I’m sure that better software would be the result.