Adaptive Path Blog

Leisa Reichelt
For a long time, she had a traditional approach to product management. Discovery, documentation, functional specifications, sign off, and then go into production. This was a low-risk way of producing projects. It worked fairly well.

But then larger and larger projects, that methodology started to give way and not really work. Came to a fork in the road: another approach. Little changes over time that completely transform over time. The old process can take longer. Not exactly Agile, but similar. More iterative. Agile does have a lot of problems, definitely.

Waterfall = Bad
Scope > Design > Build >Test

Why is it bad? It does bad things to us as designers and to the human brain.

Assumes that you know what you are doing at the very beginning! You know in detail things like schedule, budget, timing, etc. But this isn’t really true. Half of the battle is often understanding the problem.

It also assumes that there comes a point in the process when the design stops. Designers walk away and the developers develop. Again, not true. Still design decisions happening: because of documentation ambiguity, because of technological constraints, because developer “helps out” and “fixes” the design for you.

Waterfall likes people in silos, in boxes. Creates a diminished working environment.

Waterfall doesn’t support the way we solve problems or how the brain works.

Washing Machine = Good
Iterative design. Obviously not a formal methodology. But has characteristics:

Iteration: start by designing, build, take what you’ve done and test with users, take back the design, refine, do it again.

Early and Rapid Release: don’t have to do the whole design process at one go. Break it up into chunks. Public or not, depending on the project. Incremental approach. Helps overcome design fatigue. Compare your first wireframes to your last!

Multi-Disciplinary: involves everybody who is involved in the project. No real stakeholders–everyone is involved (ideally) throughout the entire project. Maintain engagement with the project.

Collaborative: an ongoing engagement with all the different parties.

Involves End Users: real end users! Not just user advocates or usability people.

Agile vs. UCD
Sprints vs. Iterations
User Stories vs. Personas and Scenarios
Pair Design & Programming vs. Contextual Research
Close Proximity Teams vs. User Testing

Agile: weak on end user involvement
UCD: weak on early release and multi-disciplinary collaboration

We need to make Agile more like UCD or UCD more agile! Agile UCD? Can’t just do UCD in the beginning and Agile in development.

Cycle Zero
Happens at the beginning of the project before Agile happens. More upfront research, analysis, and strategy which is existing in UCD but needs to be added to Agile. Need to deliver something that “works” at the end of 2-6 weeks. Deliver: product goals, shared vision, contextual research, personas and scenarios.

But how much design can you do in one cycle? How much testing can you do in a cycle? (cycle=2-4 weeks!)

Mid-Project Cycle
While developers are working in a cycle, designers are involved but also looking to the next cycle.

Pick N’ Mix! Now is not the time for get purist re: methodology!

This entry was posted on Tuesday, August 14th, 2007 at 11:50 am and is filed under Conference Commentary, Product Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

This post is licensed under a Attribution-Noncommercial-No Derivative Works 3.0 Unported License.