The Agile Philosophy

How UX Fits in an Agile Framework

Agile vs Waterfall

Describing how Agile works in the world of UX ends up diving into the abstract relatively fast and because of that, I find the best way to understand Agile is to compare it to waterfall—a system that we all intrinsically know. Like all classic UX analogies, lets talk about houses.

Imagine you’re building a house. This house needs to have a couple bedrooms, an office, a kitchen… usual house stuff. So you learn about building houses, you design some blueprints, you get to building and a year goes by and you’ve got yourself a house.

This framework of design emulates what’s referred to as a waterfall process.

There’s a discovery phase—learning about what kind of house to build, a design phase—making the blueprints, and finally a build phase that correlates to building the actual house.

If you’re feeling fancy, you might even toss on a ‘testing’ phase at the very end to validate how successful the thing that you build was. But of course the thing is already built so the value of that testing is somewhat questionable because you’re learning about it too late.

So that’s Waterfall in a nutshell. The main philosophy here is that waterfall tries to get things right on the first try.

Agile takes a different approach.

Like before, we start with the same requirements of the house: the couple of bedrooms, an office, kitchen, all that stuff. As usual, we start with the discovery portion of building a house but rather than learning about the entire house, we’re going to first understand what requirements of the house are the most important and we’re just going to focus on those areas. For me it’s the office because that’s where my computer is.

Rather than doing discovery on the whole house, we’re just going to learn more about the office because that’s one of the areas of the house that has the highest amount of impact and value.

So we learn more about the office, we design the office, we build the office, and then—and most importantly—we test if we succeeded in building the office. Because we’ve only built one of the rooms of the house, we can validate if how we built that room was correct and if not, we can change how we build things before we build all the other rooms. So we build the office, then we move on to the next most important room and build that one, and then the next one, and on until the entire house is built.

And that’s Agile in a nutshell. The main philosophy of agile is—unlike waterfall that tries to get things right on the first try—agile tries to get things right eventually.

So why would you want to choose an agile approach to product design over a waterfall approach? Wouldn’t you always want to get things right on the first try?

To answer that, lets take a look at the timelines of these two approaches and how they differ.

Going back to the waterfall approach, we had the discovery phase—lets say that took three months—our design phase and lets say that also took three months, and the build phase which is more complicated and took six months. All together, the entire project took a year to build.

Now lets compare that to the agile approach.

Because in the agile approach we focused on building the office first, the entire process ended up being faster because we’re focusing on only a small percentage of the entire product. So for building the office, lets say discovery took a week, designing took a week, building took two weeks, and then testing took an additional week. All together, building the office took a month but of course, we then moved on to the next room and started the whole thing over again. After every room was done, the project could still take a year to make.

So in both instances, the project could still take the same amount of time to make. But here’s the thing: the agile approach has two massive benefits the waterfall approach doesn’t. To understand that, rather than looking at the overall project timeline, lets instead take a look at when we provided value. 

In the waterfall approach, value wasn’t really created until the very end. That’s when he house was built and somebody could move in.

In the agile approach, value was created after just a month and a half after the office was built. We knew that the office was one of the most impactful features of the house so by building that one first, we were able to almost immediately create value.

The other huge benefit is the testing phase. We got to learn how we were doing and potentially change our approach moving forward if anything wasn’t satisfactory. So we essentially saved having to do re-work later to fix things while also validating that we were moving the right direction.

Now, if one is literally building a physical house, the agile approach may not be the most effective solution. Nobody is going to move into a house that is just an office—although housing markets am I right?

But in software and product design, we can totally do that.

Imagine you’re building an app and you have a list of 10 requirements that you have to build but in your discovery you learn that 90% of users only use one or two of the? Build those first. Those two things are providing the most value and you can start making impact way faster.

And that’s what an agile approach to product design looks like how it differs from waterfall. Naturally, there are deeper conversations and nuances to all of this—particularly how UX integrates within this flow because it’s not necessarily as clean as I’ve described it—but at a high level, waterfall tries to get things right on the first try while agile tries to get things right eventually.