Agile Design

I was first introduced to the concept of Agile Development when Paul Giese, Traction's Director of Technology, had me read an eBook that was put out by 37 Signals.

The basic premise of the book is that there's a smarter way to develop applications. By taking a rapid, iterative approach where a team updates features early and often you wind up with simpler, better applications — in less time. Simpler is key. The argument made by 37 Signals is that most applications (think Microsoft Word or Excel) are bloated with thousands of features that 99% of us never use. Why would a company create a ton of features you wouldn't use? To justify the cost of selling you an upgrade every year.

Simplicity becomes very important for a number of reasons. First, if we have a dedicated team releasing early and often, we have to prioritize what they do next every couple of days. When you have to make choices, suddenly unnecessary features become... well... unnecessary. What you wind up with is an application that just does the things the human beings that are going to use it need it to do. And do them really well.

And this is why zillions of companies from Microsoft and Google to every twodotohdotcom start-up in the universe are using agile development to facilitate innovation.

Sounds great, right?

The problem for agencies has been that "agile" is contrary to how companies and interactive agencies structure things. The way we've done things with interactive projects in the past is:

STEP ONE: client issues RFP
STEP TWO: agency writes proposal or Statement of Work
STEP THREE: agency gets the job and writes a func spec
STEP FOUR: agency does the job
STEP FIVE: the client wants something that is out of scope—we have to write a change order!

Agile Development effectively gets rid of the scope. We have a budget. We have a deadline. We have objectives. We have process. Now, let's create something using our process that meets our budget, our timeline and our objective. What will we create? We'll find out when we get there.

Ironically, the ad agency retainer model works really well here. With an advertising retainer, you're not buying specific deliverables. You're buying a staffing plan — hours of people's time. We estimate hours based on potential needs, but what those hours will buy will shift based on mutually agreed upon priorities.

Lucky for us, Traction is both an ad agency and an interactive agency, so this actually works well for us. We're currently using it with about half of our clients—from start-ups to Fortune 500 companies.

But what we're seeing now is the need for more than just agile development, but Agile Design. In one case in particular, our team is currently prototyping a really cool, really top secret immersive digital experience for one of the world's largest financial institutions. The timeline is ridiculously tight. The potential scope is massive. There's a boatload of both graphic and interaction design work and presentation layer coding (Flash, AJAX, HTML) to do. And, the client wants to review it 2 or 3 times a week.

We're using an Agile Design process to make this work. We are creating a feature prioritization matrix and assigning a "must-have," "should have" or "nice to have" label to every component. Digital triage. We will upload work in progress daily, but designating key areas to feedback. Feedback goes into the matrix too. The benefit of presenting often is that course corrections are made early—incredibly important for a project with a large number of stakeholders. A hard-stop design and feature lock date ensures we'll have the time to test the hell out of this puppy and deliver the high quality product our clients expect and deserve (of course, the browsers we'll test it on where prioritized too).

Now that I've written this post, I guess the reality is that this is really a hybrid Agile Design & Development process, but that's not the point. The point is that a lot of guesswork goes into estimates for interactive projects. Why? Because until you've actually designed something, you have no honest idea what it will take to build it. Being agile eliminates the guesswork.

This is great for both agencies and for clients. What's important to each?

Agencies want to produce successful work that helps them grow their business, make a reasonable profit and have a good working relationship. An agile process enables them to create successful work, plan their resources effectively so they can make that profit and establish the kind of frank dialogue that makes for a great working relationship.

Clients want to produce successful work that helps them meet their business objectives, pay a reasonable price and have a good working relationship. An agile process enables them to ensure the work that is produced is focused on successfully meeting their objectives, is fairly priced and is managed with the kind of frank dialogue that makes for a great working relationship.

If anyone has any experience working with this kind of process in an agency environment, please post comments. I'd love to hear about it.