This version of the site is now archived. See the next version at v5.chriskrycho.com.

Is Agile the Enemy of Good Design?

John Cutler on “Agile,” good design, and the reasons the two often seem at odds.

July 29, 2018Filed under tech#agile#business#design#software developmentMarkdown source

In line with my recently stated desire to share out things I’m reading:

I just ran into a really excellent piece by John Cutler (who is also new to me), Is Agile the Enemy (of Good Design)?. The whole thing is worth your time, but a couple bits in particular stood out to me in light of some ongoing conversations Ben Makuh about wisdom and folly in startup culture.

In particular, these two bits from other designers Cutler cites sum up a huge amount of what’s wrong with a lot of what passes for “Agile” and indeed for “startup culture”:

The stuff you’re talking about rarely happens. It is all about “ship, ship, ship”. We don’t pivot. We don’t refine. The product owner just wants to mark it done in Jira. The MVPs are an excuse to get crappy stuff out the door. I guarantee that if I am methodical with my prototype testing, I can come up with something better because I will expose it to users. Not AS great as doing it the perfect Agile way, but better than nothing. I mean I struggle even to do usability testing. So you know…yes in theory all that is good, but it doesn’t happen.

The enemy of both actual agilistas and the UX/design community in 2018 is, as John points out, short-term, output-centric thinking driven by a focus on short-term financial results, and all the cultural ramifications of this mindset.

These things are antithetical to the original ideas of the Manifesto for Agile Software Development. But they’re also, well… pretty common. As Cutler puts it:

…Agile — like many other things in cut-throat business — is often no match for the universal threats of output fetishism, success theater, and cutting corners. Trust me… these predated Agile.

And this is some hot fire here:

So where does this leave us? Designers have a right to be concerned. At least with waterfall no one prematurely yells “ship it” in the middle of the project. Designers have time to work instead of trying to jump on and off the sprint conveyor belt. And because the “thing” is built in a big batch, they have time to tackle the design problem holistically right from the beginning. “Good” waterfall beats abused Agile any day.

He’s not wrong. You should read the whole thing.