Moving Beyond Waterfall to Agile Development + Design

Waterfall has been an industry staple for decades. Find out why the Agile philosophy can make for a more nimble, efficient design process–and discover how to get started.

Whether you’re a designer, illustrator or artisan, you probably know the Waterfall process. It has a clear beginning (planning), middle (design) and end (production and release). This rather Aristotelean method of working in three—or more—acts has worked and continues to work for many of us. But it’s not the only method—so why do we default to using it?

The Waterfall process has its roots in manufacturing and construction. Consider the assembly line, a sequential process of construction where one part after another gets added to a product that finally rolls off the line when it’s completely built and ready for use. When designers embark on a project, we follow a similar process.

We’re familiar with the Waterfall method, and know it for the sequence of check-ins that have to happen before moving on to the next step. A project is initiated, and we learn about needs, scope and benefits through a creative brief we receive or create on our own.

When economic matters are involved—which is often—we consider the marketing factors, like overhead and return on investment. Research and planning requires us to learn more about the problem, perhaps collecting data related to the context and content. We analyze the data and assess what has to happen through the creative process, including issues related to staffing and production. And during this time, we constantly check back to the initial project brief.

Once we have enough information to work with, and understand the people, place, culture and production, we begin design by sketching or roughing things out. Web designers often call this the prototyping or “skinning” stage. Surface treatment such as color, typography, imagery and materials may come into play. We create additional prototypes, conduct reviews and testing in the form of internal critiques, and perform external assessments in the form of focus groups or client reviews. Then we have feedback to compare against the needs we perceived, be they functional, aesthetic
or otherwise.

Waterfall: design and review

Design and review may happen repeatedly until we get things “just right” and have polished the design to a ready state for production. We go through pre-construction where we may see a first draft printed or modeled, but even before doing so, it’s necessary to preflight all of our files and assets necessary for facilitation and production. Once those preliminary files have been assembled and tests have been incorporated and approved—with some edits being made at the blue-line stage of printing, for example—the design is created.

In the case of a website or app design, a very similar process happens, except the production necessitates back-end development in HTML/CSS instead of generation with ink on paper. There may be revisions or edits to make to a printed work, but in nearly all cases a website will have ongoing maintenance, upkeep and content addition, just to name a few tweaks needed as the process unfolds. And the operative word there is ongoing—as in, forever.

For designers, the Waterfall method has been used for most—if not all—of what we do because much of what we’ve produced over the past few decades has been print media. And although the tools we use have changed over those decades, the Waterfall methodology associated with it has changed very little.

Waterfall definitely has its advantages. First and foremost, personnel know what they have to do. Accountability gets distributed. If you’re a copywriter working on the text for a brochure, you know what you have to do and when you need to hand it off to the designer. It’s simply human nature to carry out activities through a kind of “if/then” sequence: If the sun sets, then we should get ready for dinner; if we feel thirsty, then we should drink some water. Our creative process is similar: If I have to lay out a book, then I need the text first; if I’ve designed the book, then I need to review it to make sure there aren’t any errors. Throughout those if/then steps, checkpoints ensure that reviews have been done—and done correctly—before a design moves to the next phase. This gives us (and our team) necessary reassurance.

Agile development for design: an iterative methodology

agile development; agile method, scrum

What is Agile methodology? Agile practices and methodologies date as far back as 1968, but contemporary practices have their roots in what was developed between the 1990s and early 2000s. Being Agile means moving through the development process in a way that is both efficient and effective, “releasing early and often,” and iterating along the way to change—ideally for the better. You release software, websites and products quicker. You stay in touch with your consumers and users, improve quality assurance and improve the product over time (while having something in the market to base your improvements on).

Designers and developers deliver a functioning product to the user, listen to their feedback and make improvements through a state of constant iterations. As such, Agile happens through what Craig Larman calls Iterative and Incremental Development, or “a subset of iterative and evolutionary methods.” IID requires releases to happen frequently, with each release having its own life cycle. Several iterations may happen over the course of a product’s lifespan, with delineated scheduling and staging happening in parts.

Timeboxing requires the team to establish a fixed iteration date or time on task. So if you plan to release something three hours from the time you begin it on a Friday afternoon, then that release time has to happen even if less critical functions aren’t ready by then. At the end of the timebox, you review the work to see if the goal has been met. As long as you’ve completed the one goal you established, you release it within the timebox. With a lifespan of a day to several months, timeboxes vary, and some even have their own moniker.

Agile development and iteration

Industry digital strategy experts, like Mike Arauz agree that an Agile process really works. Arauz will be providing an in-depth look at how to implement an agile workflow at the upcoming HOW Interactive Design Conference September 3-5, 2014  in Washington D.C.  Also here is an simple summary overview of what the Agile approach looks like in terms of the web design process:

Agile Development; agile method; waterfall

1. Develop. A quick release of a website’s single home page must happen. Develop only the home page over a period of four days.

2. Establish. Create five timeboxes to craft the written content, lay out the page, program the HTML/CSS, test it internally and release it.

3. Release. The single page of the site goes online.

4. Assess. Gain customer input and develop customer relationships through online data gathering, such as Google Analytics, feedback or review prompts and/or social media.

5. Research. Use feedback channels to learn what content users want, and to clarify site modifications in the project’s updated goals.

6. Modify. Work on those items to be added—the most important items—and get them integrated into the site.

7. Review. Pass designed items through the given review/acceptance channels.

8. Be Agile. You’ve released something quickly and have made changes based on feedback to evolve the site. You constantly check in with users and work on the most important items first, as dictated by customer requests.

Being Agile requires you to be an agent of change, and quality is important over the course of the changes you make. Don’t rush through the work during the production and design stages in order to meet your goals. Good design and good programming are as important here as anywhere else.

Implementing the Agile approach and delivering to the customer early and often isn’t a foolproof recipe for success, just like using the Waterfall method isn’t always a sure thing, either. For designers who work on websites and apps, the question of quality may come before the question of completeness. Being Agile may mean getting a project out the door with a less-than-typically-acceptable “look and feel.” The fonts may not look “just right” in the early iterations. Remember that quality is important, but try not to let striving for “perfect” get in the way of “good” and slow down your overall process.

Dig into more Agile processes in the complete Expert’s Guide

agile development;