An introduction to Agile projects

This post was written by Graham who’s been managing projects at Simpleweb since January 2013. Say hi to Graham on Twitter.

If ‘Agile’ is a new concept to you when it comes to running projects (as opposed to taking part in an assault course), here’s my take on what it means, and an insight to how we use it on some of our projects at Simpleweb.

We don’t take an agile approach with all our projects, but instead pick a methodology that best suits the product, technology, and above all the people, whether that’s the client, the end user or the development team.

We don’t strictly follow any particular school of thought on Agile, such as Scrum, which I find far too restrictive and jargon-filled.

What is an Agile project?

A typical, waterfall project, starts with a very fixed idea of what features will be developed and when, and everything is tested at the end.

In an Agile project, the features you end up developing are pulled from a prioritised list (or ‘backlog’), and only specified in more detail just before you start working on them. Testing happens throughout the project.

To accommodate real world client budget constraints, the project has a fixed amount of time (effort) attached to it, for example 50 days. The client signs up to that. That means only the features that get developed within that time limit end up seeing the light of day in the released product.

So, does that mean we end up releasing a product with a key feature, such as registration, missing, or its nicely designed interface nowhere to be seen?

No, not at all – although this is something that can scare people about Agile sometimes.

What stops this happening in our Agile projects is that at the end of every sprint (a fixed duration of 1 week to 1 month typically), there must be a fully working version of the software that the client can use, review, and feedback on (and we can subsequently fix, change and enhance). There are formal reviews of these sprints to collect feedback and decide on what to tackle in the next sprint.

Each sprint in the project will normally be themed or have a particular objective in mind, to focus the project team (and the client). At Simpleweb, the client representative is usually a project manager, and it is their responsibility to represent the client on a day to day basis (supported through ongoing communication with the client via Basecamp).

User stories

In our Agile projects, each ‘feature’ is actually called a ‘user story’, or just a ‘story’. For example, rather than a feature being called something like ‘User registration’, the story would be called ‘User can register using a form’.

This puts the emphasis on having a valid end-user goal, or objective – something that is well understood by all parties, can be estimated, and is testable.

Having said that, a project will also include some internal ‘stories’ too, which could be something like ‘provision a server for a stage environment and style guide’. Incidentally, you can even replace ‘User’ with a real name, tying this into Personas (but perhaps that’s a subject for another blog post!).

Developing stories within a team is an interesting exercise in itself. Typically, you’ll take a one line story like “John can search the site from the header search box”. Then the whole development team will start to break that down into actual tasks for them to work on, e.g. “install and configure search service”, “build UI for search box”, etc.

Another key job at this point is to ensure the story has acceptance criteria – i.e. a user test case agreed with the client, and that, ultimately, will lead to the story being approved, or signed off.

Why Agile?

On a day to day basis, taking an Agile approach to a project means that we produce daily internal releases for our own testing and review. This means that testing and QA can happen on an ongoing basis throughout the lifecycle of the project (rather than it all happening at the end). This improves the overall quality of the software, but also means that clients can feed back on any concerns they have during the project instead of at the end.

A side benefit of the Agile approach is that stories can be moved up or down the priority list during the course of the project if the client feels they have become more or less important. It also means that if we are making good progress, i.e. we are developing faster than anticipated, we can get more stories developed, so everyone’s a winner!