PostCMS

How agile works

Traditionally, a website project is broken up into distinct phases, each of which has to be completed and signed off before the next one starts.

Using an agile methodology, these phases become strands which run in parallel, and the project is implemented in a series of iterations, called sprints.

That means you've got some working code at the end of the very first iteration, rather than having to wait until the end of the entire development cycle. So you can adapt to change as the project proceeds, for example, revising your navigation in the light of user experience testing.

Time-boxed iteration

How long is a sprint? That depends on the complexity of the project and availability of resources. Between 3 and 6 weeks is normal. But once you’ve agreed a sprint’s length, you can’t change it. Agile sprints are time-boxed, meaning that release dates are immovable. If something has to slip, it’s functionality.

How many iterations till the website is ready to go public? Again, that depends. For a typical informational or marketing site, one or two sprints will usually do.

Setting your priorities

What goes in each sprint? That’s up to you, as the website owner. First, you will prepare a backlog of stories describing what the website has to do, and prioritise the most important of these. At the beginning of each iteration, there is a planning meeting where the team works out how many of the stories can be included in the coming sprint.

Daily reviews and the burndown chart

How do you measure progress? The team holds a brief daily review which monitors progress and identifies problems. The key documentation is the "burndown chart", a simple graph of actual progress against expected progress.

Cross-discipline teams

The agile team includes a range of disciplines: creative designers working alongside developers and information architects. Most importantly, it includes a project owner from your organisation, who has authority to make decisions without having to refer them back. With agile, you don’t just outsource the project and wait to see what you get back: you need to be involved all the way.

Low on documentation

Detailed documentation freezes out change, and uses up resources that could be better used in delivering a working solution. Agile methodologies minimize the amount of documentation generated, filed and forgotten.

Continuous delivery

Few websites are ever “finished”. Once you’re live, you’ll learn a lot more about your audience by analysing how they really use the site. If you follow a traditional approach, you might find that the website you’ve built to a detailed specification isn’t working how you’d hoped, and it might be difficult to do anything about it.

With agile, that’s just part of the process. You go public (at least to an internal audience) as soon as you can, but continue iterating, both to implement the lower priority goals that didn’t make it into the first release, and to make changes arising from experience.