The waterfall method that many creatives are used to has its place. It benefits us when we have most—or all—of the information we need to have during a project’s earliest stages of planning and development. It’s important to know the consumer, the client and the media, the methods, and have the personnel to follow through and move forward with the project. Each checkpoint along the way ensures that things are accomplished in order to fulfill the inquiries and needs established during the problem-definition stage.

In digital design—especially as it relates to web design, app design and a wealth of other technologically driven design—there’s a need to move nimbly and efficiently to create quickly for consumers so they get a taste of the product in-process. This rapid release invites the consumer or user to test the product and provide direct feedback about what works and what doesn’t. Users are active participants in the creative process, and influence the changes to the product to meet their needs.

This rapid and iterative method of creation and delivery, as well as the maintenance and updating throughout iterations, has begun to replace the more sequential and step-by-step waterfall process. The iterative, Agile philosophy allows today’s web designers and developers to get products to market quickly, and it involves customers more directly. The Agile philosophy can help boost brand awareness, as well as enhance team morale, a company’s financial value or return on investment.

But iterative design and an Agile philosophy isn’t a catch-all solution, the same way that a waterfall process isn’t always a fit. There’s even debate surrounding semantics connected to Agile itself: It’s argued as neither a method nor a process. Agile is more descriptive than prescriptive. More than anything else, it’s a philosophy of “releasing early, releasing often” in order to deliver functional products to the user.

In some cases, a waterfall process may be a better fit than an iterative one. Designers, developers and project managers need to have a critical gaze on all of the factors involved to decide whether being Agile is the right fit for a specific project. This guide is intended to give you the perspective and tools that you need to make that assessment.

What is Agile?

Most designers are accustomed to working within a waterfall project management cycle, where one task gets completed before moving to the next. This is, for the most part, a sequential process. But software developers, programmers and web designers have known about iterative design and Agile’s benefits—and they’ve been implementing Agile strategies in order to produce results quickly.

Being Agile, as it relates to the “Agile Manifesto,” requires a design and development team to release something for users as soon as possible. Then the team incorporates feedback received from users in order to make constant improvements. In many cases, designers and developers follow Agile principles when developing software, websites or apps, but these principles can also be applied to products outside of the digital realm.

Agile Principles include:

Customer satisfaction

Harnessing change

Functional software delivered sooner than later

Interdepartmental collaboration with developers

Trusted and enabled team members

Using face-to-face communication

A constant pace of production

Technical excellence

Good design

Simplicity

Self-organizing teams

Checking in at regular intervals to improve

Designers should recognize nearly all of the items listed above, and be able to align them to their own creative methodology and customer/client promises. Most of us want to give users something that will satisfy them, and we consider customer satisfaction part of our job. In order to do our jobs well, designers collaborate with small to large populations, and, increasingly, the users themselves. More often than not, designers would like to be at the boardroom table with business decision-makers—a marketing/business analyst or chief executive officer—in order to steer a project in the right direction, both strategically and aesthetically, at the early stages. When it comes to the tools we use, technical excellence means knowing how to build the design we’re making, whether on paper or on screen, with Adobe, Apple or Microsoft software used for creation and production. When good design happens, it’s a result of many factors fusing together, to deliver a product ranging from the most simple to complex.

But what makes a designer Agile? One of the common misconceptions surrounds semantics. Are you agile with a little a or Agile with a capital “A”? Generally speaking, being agile with a lowercase a means you’re able to produce quickly and efficiently. Who knows exactly why, you’re just nimble. Semantics aside, if you adhere to the “Agile Manifesto,” as created by its founders and signatories, you value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

In today’s digital design landscape, an increasing number of web and app designers have been adhering to the “Agile Manifesto” by using Agile Principles. Many job openings in those areas require front-end and back-end designers to understand what it means to be Agile, and what it takes to be a change agent. Although Agile development has permeated much of the contemporary software and web design landscape since 2001 when Kent Beck and his colleagues established Agile, its foundation harkens back to the 1950s and 1970s. Gerald M. Weinberg went on record in an interview published in Craig Larman’s Agile and Iterative Development, saying that as far back as 1957, he and his team felt that waterfalling a project was “rather stupid” …

About Jason Tselentis

Jason Tselentis is a designer, writer, and educator. As Associate Professor at Winthrop University, he teaches visual communication design, brand strategy and development, web design, and typography. His writings about design and visual culture have appeared in Arcade, Eye, mental_floss, Open Manifesto, HOW, and Print. He is a Print contributing editor. Mr. Tselentis also has four books to his credit on design and typography principles, and design history.