AP UX Week '07: Waterfall Bad, Washing Machine Good
[Live blogged from Adaptive Path UX Week 2007. Waterfall bad. Washing machine good by Leisa Reicheit]
Came at UX through project management.
Back in the days of yore people would write functional specs. They would be signed off on, set in stone, and put into production. Theoretically, knowing the end goal would let you estimate costing, etc., in a project.
But in reality this doesn't work as promised.
[Great story about a project where they decided to attack small problems on a site instead of jumping head first into a giant redesign. The lesson is that there are many ways to manage projects and they are all valid if chose in the right situation.]
Caveat: this is focussing on the positive. There are problems with Agile but we are focussing today and its advantages.
Waterfall = Bad
Scope > design > Build > Test
Why is waterfall bad? In 1970 W. W. Royce outlined waterfall among other methods. He didn't have good things to say about it.
I believe in this concept, but the implementation is risky and invites failure. W. W. Royce, Managing the development of large software systems
Waterfall is bad for designers
- Assumes that you know what you are doing at the beginning. This is rarely true. In fact, in the best project you know very little at the beginning.
- Assumes that there is a point in the project where design stops. This never works. When you hand something to developers and watch it come out the other end you know that design hasn't stopped. So why leave designers out of this? When technology smacks design in the face the designer should work with the developer to make solution. Design decisions at all point should not happen in a vacuum. Developers should be brought in to the whole process and not just get the end deliverable.
- Discipline discreet phases keep people apart. This diminishes the work environment. People don't learn as much this way. We learn more if we are working with all different disciplines.
Waterfall is bad for humans
MCC did a study on this in the 80s. Watching how people actually work on projects they learned that people don't cleanly divide their work between understanding the problem and exploring solutions. Waterfall assumes that these are completely discreet.
Waterfall does not support the way our brains work.
Washing machine is better
This isn't an accepted term for a methodology so let's explore this.
- Iteration at every step
- Early and rapid release of prototypes and products
- Multi-disciplinary in the same room and on the same task
- Collaborative throughout the whole process
- Involves real end users in the whole process
So what's out there already?
Agile
This is becoming more popular in the last few years. Scrum, a flavor of Agile, dates back from 1986. This can also mean working quickly without planning but that isn't really Agile.
Agile is not Ad Hoc
Agilists have lots of rules. They are very conscious about what they are and are not doing.
Waterfall is predictive and Agile is adaptive.
Agile is:
- Sprints/ time boxes
- User stories
- Pair design/ programming
- Close proximity teams
Agile is all about working software at the end of each sprint.
Start with a story > Fine tune the details > Build something > Test the thing against the story
User Centered Design
- Iterations
- Personas/ Scenarios
- Contextual research
- User testing
So what..
Agile is weak on user involvement. UCD is weak on multi-disciplinary collaboration, it is very design focussed. UCD is also weak on early release.
The best way to do it is to start with Agile and add in UCD techniques.
Cycle Zero
This is what happens before the project begins.
Do this when a project needs up front research and high level design strategy. This takes time but don't forget that you are trying to be agile about it. Stick to short time frames (2 to 6 weeks) and deliver something that works, not working software but shared goals or vision.
Cycle One
How much design can you do in this cycle? How much testing can you do in this cycle?
Cycles should be 2 to 4 from start to completion.
Mid-project cycle
(This is a Venn diagram when you aren't writing your notes in words...)
Designer
- test previous
- design next
- research next
Developer
- implement design from previous
Both
- feedback on design
- feedback on implementation
Conclusion
Now is not the time to become a purist about methodology. Pick and mix from whatever works and build something for your context and your team. The time for buying project management methodologies off the shelf is behind us.
-2 TrackBacks
Listed below are links to blogs that reference this entry: AP UX Week '07: Waterfall Bad, Washing Machine Good.
TrackBack URL for this entry: http://www.samfelder.com/mt/mt-tb.cgi/311
Who is this guy?
Leave a comment