At last week’s Epicenter software conference, our very own John Wood spoke about applying agile software development methods to interaction design projects.

In his talk, he posited that the old waterfall model of project development is dead, and that traditional business requirement documentation and delivery is a dead end.

But is the agile method championed by 37 Signals’ Getting Real manifesto right for interaction design projects?

John thinks not.

A bit about agile

Agile development involves little advance preparation and process definition. It’s all about getting into the actual coding of software as quickly as possible, and iterating your design over and over again.

The traditional waterfall method involves development prefaced by heaps of documentation, most of which is a poor conceptual mockup that tries to transmute something intangible into a black-and-white document.

Coders then have to take that paperwork and interpret it as best they can. The disconnect that arises between definition and development means the product that’s defined can bear little resemblance to the product that’s designed.

Requirements are dead, long live requirements

The agile development process, as outlined in Getting Real, throws requirements out the window.

This is fine for small companies who build software basically to please themselves. But it’s just not realistic – sorry – for consultancies and large companies with many stakeholders.

A pinch of agile with a dash of documentation

Here at iQ, we’ve been testing out a new development process that’s a mashup of our i3 project development method – a version of the waterfall model – and an agile development method called Scrum.

What’s great about Scrum?

We’ve found it leads to:

• Better communication
• Empathy
• Fewer and quicker meetings
• Clearer accountability
• More ability to cope with change

What’s bad about it?

In his talk, John said that scrum addresses the right problems, but it throws the baby out with the bathwater.

Why? Because it assumes that the essential concept behind a project is correct – that what you’re building is what should be built

Its agile phases only iterate a website’s form and function, but it doesn’t go all the way back to address the ‘Why’ question.

Setting the right problem

You’ve got to continually address first principles throughout the project in order for the end result to work, and consider scrapping and changing that problem as you go, because the problem you think you’re dealing with may prove to be a completely different problem when you get deeply engaged in an agile design process.

Why Scrum works for clients

Scrum can be scary for clients at first because it involves a high level of involvement from them.

The advantages, though, are clear. From an agile perspective, it’s easier to change things on the fly, because clients see real design efforts sooner. And they see them in sketch form on paper, so there’s no real overhead involved in making changes.

When they’re brought into the planning room, clients are able to actively contribute and answer questions on the hoof – and they’re made aware of the volume & depth of a project’s effort.

Imagine, if you will, a crime-thrilleresque situation room, papered with post-its and sketched concepts. Showing clients your process on the ground is far more effective than presenting them with a set of clean wireframes, which are divorced from the process and can get clients focusing more on appearance than function.

John’s recipe for success

Marry interaction design and agile design. Don’t throw away the paperwork and get right into code – just have the right kind of discovery and documentation. And iterate early and often.