Custard Melt

Processes, documents, contracts and planning are not meaningless bureaucracy. They're responses to particular problems - namely quality, maintainance, supplier risk and project risk. Taken by itself the manifesto reads like a rejection of tried and tested methods in favour of cowboy independence. That advocates use terms like 'movement' and 'manifesto' adds to the sense that this isn't something responsible businesses would want to get involved with.

Which is unfortunate, because Agile is a well thought out methodology that does address the issues of quality, maintainance and project risk in detail, and often extremely well. It is also anything but process light.

On many web development projects the process is a bit like this. 1. design 2. development 3. testing 4. deployment. Within each stage there are goals and milestones, the project manager can see a list of tasks, calculate the critical path, identify risks and estimate things like delivery date with a high degree of accuracy.

At that stage though process often ceases. The individual programmer, tester or designer is given a task like 'design this bit and make sure it works' with the Project Manager ticking it off when it's done. Some testing is often done by the developer and on big projects finished components are handed over to a QA guy for serious testing. When things fail, they go back into the loop.

Agile changes a lot of this, mostly by redistributing the burden of where the process falls. As 'Iteration Manager' I find that Agile reduces some of my workload, principally by pushing a lot of tasks onto the developers. Developers used to just being told to 'write this and make it work' though could well find Agile much heavier going.

Lets imagine Peter the Programmer has been asked to write some code for a project. In what I'll call 'traditional' development he'll be given a specification, write the code and when he's happy with it hand it over for testing and sign off, if it fails, he'll get it back.

In Agile development it's different. Peter isn't given a specification, he's given a requirement (called a Story). First he estimates how long this will take him. Then he has to write some automated tests which will only pass when the requirement is met. Then he has to work out how he's going to meet the requirement, write the code, test it himself and then pass it over for acceptance testing, which is less about 'does it work' than 'is this an appropriate solution'.

Advocates of Agile argue that what Peter is doing now is best practice. He shouldn't have to work to detailed specifications, because they take a long time to write and don't adapt well to changes. He should write tests and do his own estimating because that's best practice for programming, and he should be made to understand the requirement because then he can formulate the most appropriate response.

My point isn't that this isn't a form of best practice - it is. My point is that it's process, lots of it. Masses of baked in deep process. An Agile programmer spends a lot of his time doing things that the non-agile programmer doesn't have to do - things like writing tests and understanding requirements. He also has to go to daily meetings and weekly planning sessions; yet more evidence of process.

For the project manager, Agile is easier. No detailed technical specification - that's written by the programmer as they go. Estimating is done through 'points' and while things like critical path analysis and estimating timelines get harder, the responses to problems (usually triage) get easier. You only really need one document - a big list of stories, and it's written in a language your customer can understand.

For the programmer (and bear in mind that I'm not one) Agile seems to demand a lot of discipline and an adherence to a methodology that while it does allow a lot of freedom (in terms of how you solve each problem) does force you to work in a tightly defined manner.

So, my first big thought on Agile? There's a lot more process there than some people would have you believe.