Why Iterate? I've been thinking a lot about this. (and obviously so has the rest of the development community.) Iterative. Agile. Extreme. Scrums. Sprints. You guys all know the score, right?
This is what Wikipedia has to say:
Iterative and Incremental development is a cyclical software development process developed in response to the weaknesses of the waterfall model. It is an essential part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks.
It's represented by graphics that typically look like this:
This is a much better, more detailed version I stole from Cambridge:
I've worked on my share of projects that used some flavor or other of agile development, and I have to say, I prefer it. You get to results (working code) faster. Clients are happier. And because agile requires a sense of ownership by the entire team, agile projects tend to promote better, more fulfilling work environments.
So far my favorite approach to agile is Mike Cohn's User Stories Applied. I love the concept of a story (requirement) as the beginning of a discussion between the developer and the business owner and the experience designer rather than it being some kind of set-in-stone set of instructions inflicted upon the dev team. Stories let developers be creative. And creative developers often come up with amazing solutions. Traditional requirements treat them more like coding bots. And if they are treated like robots, it's only a matter of time before they start thinking and acting like them, following those instructions to the letter (if not spirit)...
Sure, iterative development, but iterative design?
SO, all this said, I have yet to experience an agile project with integrated experience design that didn't feel like some kind of Rube Goldberg contraption held together by gum and bailing wire. Often a waterfall approach to design is tacked on the beginning of agile development. There's all kinds of reasons for this:
- it's the nature of agency work (AKA: clients want to see what you're building before you build it)
- design requires a different kind of thinking (AKA: we designers need to think about the entire experience, understanding all the nuances, before we come up with the optimal design)
- design is a learning process (AKA: the business and user goals are hazily understood at best, and the design process is needed for all the stakeholders to understand them clearly)
All of these arguments have their points... good design thinking requires time to understand, and digest, and process, and create. We have to understand who we are building for, and what their needs and wants are, before we can experiment with the best way to meet them.
AND I'm sure we've all worked on projects where design is rushed, wireframes slapped together without any conceptual design work done, so that developers using an iterative process could get coding RIGHT AWAY! We live in an increasingly agile world. One where our clients want to "fail fast" and live in "beta culture" as they iteratively "tack" towards a successful application. One where they can't afford to wait for 6 months to see something.
So what's a poor designer to do?
Embrace the Madness..
And make the process our own.
Can design be iterative too? Desiree Sy and the folks at Autodesk have been thinking about this, and pioneering it in their own process. Here's a brilliant diagram that outlines their approach:
In a nutshell, the philosophy is that dev and design work in parallel tracks, with dev coding the current build, and design thinking about the next sprint--testing the previous sprint, doing further discovery, and designing.
Can we apply some of the great stuff they've learned to the agency world? And how would it be different for us agency folks?
Sooo, because this blog entry is getting waaay too long, I'm going to slap up some diagrams for what I've been thinking:
I'll go into more detail later, but it would be great to hear from others out there. Is anyone else thinking about this stuff? Had any great successes/miserable failures to learn from?