Why You Probably Don't Want an "Agile" Project

Agile is a fantastic methodology for developing software and, here at D4, we're big fans. But if there's one term that's overused in software development, it's "agile".

Many people say they want their development project to be agile. They like the idea of lightweight process, complete flexibility, and the ability to change things on the fly. But as professionals it's our duty to spell out exactly what agile means.

Doing an agile project means you're buying a specific amount of developer time, instead of paying for a specific outcome. Sometimes developers will make promises about both - giving assurances about how many "sprints" it'll take to complete something to the customer's satisfaction without really knowing what they've signed up to deliver. This is risky and can be poisonous to the customer relationship, which is why we don't do it.

Doing an agile project means the customer needs to be heavily involved with the development process. Customer's don't always realise how much time they'll have to commit to an agile project in order to make it work.

Lastly, doing an agile project means you still need a process and you still need to write things down. Sometimes "agile" is used as a cover for ignoring all forms of process and documentation. This is bad idea. All software development tasks, whether they take 1 hour or 1 year, need:

• a clear requirement
• an element of design
• some testing
• some consideration given to how you release the software to users
• to be fixed if it breaks in future

Our process reminds us to consider each of those things at the right time, without going overboard on bureaucracy.