How to Avoid Agility

—Andy Hunt

02/19/2013
Published in Andy's Blog

There are many great ways to avoid being “agile.” Some are obvious, such as a sticking to a design or schedule long past it’s expiration date. Plans tend to be like milk on a hot summer’s day in that regard. They go sour quicker than you expect. But hey, it’s the plan, it’s already coded, so we chug the chunky milk anyway.

Maybe you’ve even realized that you can successfully hide from agile development in the agile practices themselves. Ron Jeffries points out one way you can avoid reality by hiding in the relative comfort of OCD estimating in his article in PragPub magazine, Estimation is Evil. Ron exhorts us to skip estimating entirely, and start shipping something now.

And that’s exactly the point. Estimation, Test-Driven Development, Pair Programming, Iterations, all the other agile practices are merely tools. As I’ve said (until I’m hoarse) doing the practices doesn’t make you agile. They are helpful, they are useful, but they do not define agility or, by themselves, take you to the next level.

What is the next level? Improv. That is, instead of planning and then executing, you want to execute, evaluate, and repeat. Picture yourself as a geeky jazz soloist: get out a couple of bars of a solo, see how the audience reacts, and change it up as needed, including trying things you’ve never done before.

What is agile development?

“Agile Development uses feedback to make constant adjustments in a
highly collaborative environment.” (from Practices of an Agile Developer)

The reason Ron insists we ship is simple: to be agile, you need feedback, and you need to adapt quickly to that feedback. You need to be able to change your designs, your code, your process, your team — whatever needs changing to reflect the new reality that feedback has reveled. To get feedback on your project, it needs to be in front of the intended users. Often. Every day, every week, surely no longer than once a month.

Note that this doesn’t necessarily mean all your users; you may only roll out to the entire user base much less frequently, say every 6 months or yearly. Or maybe you do it every hour, that’s up to you. But you need feedback from real (albeit maybe a subset) users constantly.

That’s why “Real Artists Ship” as Steve Jobs told us. You have to stop procrastinating and put it all on the line, with real risk in front of real users, all the time.

And that’s where we try and hide from agility. I think it’s a form of procrastination, a form of psychological resistance. The code isn’t ready yet, it just needs…

Don’t wait for the super-elegant object-relational mapping layer you’re going to design from scratch. Don’t wait for that time when you know that new language and environment better. Don’t wait for the committee meeting. Don’t wait to get it right: getting it out there is part of the process of getting it right. You don’t need to get it right the first time, you need to get it right the last time (/ht Jim Highsmith). But on your own, you’re just guessing. Maybe you’re a great guesser, or maybe you’re like me and you guess wrong a lot too. In front of real users, you’re don’t have to guess. You know.

And now you can change what needs changing.

The Marine Corps Way

Agile development is improvisation. It’s making changes to the project based on continuous feedback in near-real time. The U.S. Marine Corps has a common and oft-cited slogan: “Improvise, Adapt, Overcome.” That’s what modern software development needs to be like.

But it seems all too often we’re not improvising, or adapting. We’re just banging out the same old memorized riffs and calling it “agile.”

Ask yourself what you’ve adapted lately. Have you changed the code all around because of some insight from real world use? Great! Have you changed your process because of an insight from a retrospective? Have you changed your team? Your tools? Anything else? At all?

Are you actually adapting? Or just complacently doing TDD, Pairing, stand-up meetings, et al?

Don’t wait: Improvise. Adapt. Overcome. Today.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.