Adventures in agile

As an agency with a long history of designing and building social sites and apps, we’re not new to agile. While in the early days we’d used the trusty (but pitfall ridden) waterfall approach, over the past couple of years we’ve been moving towards a more agile model – but mainly on our smaller projects.

So when a big and exciting design and build project landed, with a healthily ambitious deadline, we thought it was a great opportunity to put agile to a serious test.

Meeting the needs of changing requirements
The project is working with two key clients, a charity whose aim is to increase entrepreneurial behaviour in the UK and one of the country’s leading entertainment and communications companies.

We’re building a social platform that combines quick, easy video blogging and networking features, to equip disadvantaged young people with the skills, confidence and contacts to make it as entrepreneurs.

All in all this project means a lot – to the people funding it, the people who will be using it and, needless to say, to us! So as the first major project on which we fully commit to the agile process, we’re investing a lot of time, energy and confidence in this.

So if it’s a big project, why take this approach? More than anything, we’re confident it offers clear advantages over the waterfall model, especially on a large-scale build.

Traditionally the agency takes a brief, produces a full specification and goes away to build it. Months later they come back, while requirements have changed for the client, with something that might not still meet their needs. Using agile, regular reviews mean new requests can come in at any time and the end product can change accordingly.

Engaging outside expertise
We know the value of engaging outside expertise; we do it whenever we know an external resource can add massive value to our clients – so considering the scale of the project, we started by bringing in an outside Agile Consultant, Mark Stringer of Agile Lab.

Mark accompanied us to the kick-off meeting, in which we undertook the time-honoured ritual of stories and priorities – working from the core objectives of the site and the needs of the people who’ll be using it, we created a list of things they would want to achieve, which we prioritised before breaking them down into a series of features and functions.

We (the royal we, really it was Steve Winton, our technical lead) estimated how long these would take to build and broke them down further into two week ’sprints’ – bursts of work in which various people from different disciplines develop core aspects of the site.

Initially this is working well, building on the open source technologies we know and love – WordPress and the BuddyPress plugins – Steve is starting by delivering the core functionality of site while I’m designing how it will work and how it will be laid out.

Facing problem one
As with any large scale site with its own individual identity, branding is a big job and something that we’ll all need to get nailed before we can start on the page design and front-end coding.

In the meantime, we’ll work on the user experience design and back-end development, putting the fundamental inner-workings of the site in place.

Planning it out, this posed our first problem – how we can later start to tie in all the other disciplines.

The solution we’ve come up with involves a staggered approach to our sprints, coding back-end functionality while working on the user experience design for the same feature set, scheduling in page design of the same for the following sprint, and front-end coding for the one after.

It might sound confusing but on paper it’s looking like an answer to the problem of bringing agile to a large, multi-discipline project.

Problem one leads to problem two
This fluid approach solves many problems but lead us straight into to our second headscratcher…

What really happens when requirements change? As I said, in agile priorities change between sprints and new stories are introduced, which can leave us feeling a little nervous about exactly what’s going to come out at launch.

Our solution? Well, to be honest, it’s still early days and we’re still working on it. Currently we’re regularly reappraising the backlog of stories and ensuring we keep a holistic view of what we’re aiming to deliver, but beyond that it’s a work in progress. Perversely it’s one that makes us feel a bit more nervous than if we had a weighty document specifying exactly what the finished product would look like and do.

Have you used agile on a large-scale web build? Or had a site built for you where everything wasn’t set in stone before development began?

How did it make you feel? I’d be really interested to know.

Max St John wrote this on 14.10.09 – 1 comment
It's filed in the Development, Internet, NixonMcInnes, Social networks, User generated content box