I recently returned from Chicago, where I was speaking at the Design Research Conference. The student-run conference, sponsored by the IIT Institute of Design, focused on emerging themes, methods and issues in human-centered design research, and addressed a wide spectrum of design disciplines.
My presentation looked at the differences between Waterfall and Agile Development. I prefer human-centered design, but I wanted to round out my experiences and assumptions about these two different approaches. So I interviewed several industry colleagues — user experience designers, visual designers, project managers, engineers, and clients — who had strong opinions on this touchy subject.
The presentation I gave defines the different methods of each approach, describes when each method works better, and proposes some hybrid models that can bridge the gap between these two ways of working.
I welcome your feedback on this sometimes controversial topic.
RSS
Email
Comments (7)
Great presentation!
Hi Maria,
After looking at your slides, I think I would have liked to attend your presentation! Since I wasn’t able to hear the accompanying talk, I’m curious to hear more about one of the hybrid approaches depicted in the slides.
Slide 34 seems to show a waterfall approach to the discovery, strategy, and design portions of a project, followed by agile methods for the build and transfer. Is this something you’ve tried before? How did it work? What would be the benefits of this approach over trying to work the design tasks into the agile method?
Thanks again for sharing this!
Carolyn Hack
I too found this quite interesting, but would be even more intrigued if you could provide your talk as an mp3 or what not to make those slides come alive!
To answer Carolyn’s question:
Thanks for your comment. The hybrid model of waterfall from discovery to design and agile from build to transfer does work well.
Pros:
Both disciplines can still collaborate and participate in the design process.
Both disciplines get to work in the process that’s most comfortable for them.
Cons:
Does not save time.
It doesn’t really embody the true values behind agile development.
Hopefully this helps answer your question.
Cheers
Maria
Very interesting. Thanks. Like the simple format. Esp. When X Method Works Better.
The hybrid option is too seldom considered (or planned).
I would love more depth and emphasis on how UX research and validation plays in to each method differently, to alter results. Including for different hybrid options (e.g. more user validation with prototypes). But I suppose that’s and other prezo.
Thanks,
Michael Cummings
Thank you for putting up this presentation. I’m researching how to best incorperate designers into the agile workflow and this site was recommended to me.
An important point that you make here that I agree with is the necessity to start with the big picture. Waterfall does this naturally which is a big strength for that process. I’ve also seen agile projects take off before everyone is on board with what they are building. I am on a project now that has had some resets due to late designs and it has really hurt us.
I have some objections to the approach presented to combine the two disciplines. It appears that starting with a waterfall discovery/strategy/design process implies that the team believes they can basically get it right up front. Although the later iterative process will provide some benefits, this is fundamentally taking the heart out of agility because the premise of Agile is the assumption that it is impossible to “get it right” up front.
To put it another way, every team can benefit from moving to smaller iterations, but the real power of agility comes from moving much of the design and strategy work _into_ the iterations. After all, Agile gets its name from the notion that it allows a team to change design in response to new data gained from customers looking at early versions of working code. This type of responsiveness is impossible, by definition, if we lock ourselves early into a big up front design.
In my opinion, I think it would be helpful to accentuate the need to start out with a strong picture of what is being built. Agile proponents truly need to hear that. At the same time, it is important to downplay the need to get very detailed in the design. Waterfallers want to do a lot of study up front to verify their designs, which is great and we need to harness that energy. I think the best way to do it is to carefully pick and implement slices of functionality that will answer the big questions early. If waterfallers can see that they get to still be careful, I think it will remove some of the distrust of Agile.
Finally, another important aspect of agility that is not usually discussed is the morale issue. In an agile environment, there is more dynamic communication, more trust, and the work hours are more regular, which tends to improve morale. Waterfall pushes towards siloing, heavy documentation, and large unpredictable stabilization milestones, which tends to push down morale, especially in a long crunch. Agile is as much about keeping employees happy and energized as it is about making good software.
Dear Eric
Many thanks for your thoughtful comments. I’m glad that you found this presentation helpful in understanding the fundamental differences between Agile and Waterfall and how these two methods can work together in certain situations.
I’d love to respond to a few of your comments:
1.Yes I am in total agreement that Agile Development can benefit greatly by spending just enough time upfront to help shape the “big idea” before going into iterative development cycles. It also helps designers better understand how and what to prioritize from a users needs perspective.
2.I agree that the half Waterfall/half Agile method outlined in one of my slides doesn’t really provide the “agility” benefit on iterations, but it is still a viable process method in my opinion. This method allows designers and developers to work in methods they are both comfortable with. You can still produce great products with this approach, and in fact, some companies “fall back” on this approach if they cannot get the agile method to work in their organization.
3.I take issue when people feel “locked in with big upfront design”, and you are not alone in this assessment of the Waterfall process. There are plenty of opportunities for iterations in the Waterfall process when it’s done well. We’ve been very successful launching websites and online products going through a methodical research-based design process which gives us a clear path toward the end result.
4.I totally agree with your recommendations to tackle the big user questions early, which reinforces the need to spend time upfront to help define “the big picture” first.
5.Finally the morale issue. I’ve heard this comment before that Agile makes happy employees and Waterfall stresses people out. I believe either method has their benefits and drawbacks, and you can achieve positive stress-free results in either case if you have great project leads who can scope work properly, have excellent professional practitioners who can meet deadlines and work collaboratively, and finally, a supportive environment in which people can work.
Many thanks again for taking the time to comment and share your thoughts.