Musing about Agile

I’ve been catching up with my reading, and came across an intriguing post by Kathy Sierra. Headlined What Comes After Usability, it poses some very interesting questions. I quote from her post:

Unlike waterfalls (which run in one direction and don’t back up), spirals can produce software much more likely to match what users want. Spirals support usability, and usability drives the need for spiral development. But what comes after usability? And will new development approaches emerge to support it?

So, I guess I’m really asking two somewhat-related questions.

What are spirals? Kathy’s term for the family of techniques we know as Agile and XP and fast iteration, a term I happen to like. Here’s the context she uses it in:

Kathy puts forward the suggestion that what comes after usability is Flow, and, as you would expect, makes reference to the Godfather of Flow, Mihaly Csikszentmihalyi, and to his seminal book on the subject. By the way, she invites comment and opinion on her suggestion, so please join the fray at her site so that we can all learn from it.

While I was thinking about this, I was doing my usual thing and reading a number of other books and magazines in parallel. And one of the books I’ve been reading is quite unusual; it’s called Dreaming In Code, and it’s written by Scott Rosenborg, one of the co-founders of salon.com. When I saw it was touted as “the first true successor to Tracy Kidder’s The Soul of a New Machine“, the Data General person in me couldn’t resist picking it up. And seeing recommendations from Steven Johnson and Dan Gillmor made sure I read it. [An aside. As a result of buying the book I’ve discovered Scott’s blog, Wordyard. Fascinating.]

In the book, Scott quotes from an interview he did with Joel Spolsky some time ago. While on the subject of methodologies, Joel is quoted as saying:

“The key problem with the methodologies is that, implemented by smart people, the kind of people who invent methodologies, they work. Implemented by shlubs who will not do anything more than following instructions they are given, they won’t work. Anyway, the majority of developers don’t read books about software development, they don’t read web sites about software development, they don’t even read Slashdot. So they’re never going to get this, no matter how much we keep writing about it.”

Incidentally, Scott makes reference to The Joel Test as part of this discussion, and it made me smile, just as it did when I first read it nearly seven years ago. If you haven’t seen it before, here are Joel’s Twelve Questions:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

Anyone feel up to updating those 12 questions, to make them relevant to today’s context? [Yes, I do realise that the anti-Agile crew will probably insist that no such update is necessary… the same crew who claim that opensource is anti-innovation and anti-capitalist and anti-I-don’t-know-what-else….]

Apologies for the ramble. What point am I trying to make?

Well, let’s start with Scott. One of the points he makes with real vehemence is the importance of constraints. I quote from his book:

Despite the odds — despite complexity and delay and unpredictable change — a lot of software does get written and delivered and, finally, used. Occasionally, it’s even good. Rarely, it actually does something new and valuable. And in a handful of cases, it achieves all of that on schedule.

Very often, in those rare cases, success is a by-product of iron-willed restraint — a choice firmly made and vociferously reasserted at every challenge to limit a project’s scope. Where you find software success stories, you invariably find people who are good at saying no. Like an artist who deliberately limits his pallet to one colour, a poet who chooses to write a sonnet instead of free verse, or a manufacturer who chooses to serve one small product niche, the successful programmer thrives because of, not in spite of, constraints.

if you’re interested in software development, you should read the book. Scott goes on to explain and develop the experience at 37 signals, an experience that really underlines the importance of user stories, in documenting what the user expects to see, touch, feel and do.

Then we move on to Kathy, who speaks about the need to move from usability and into flow, a state where the user is too busy enjoying what she is doing, too busy to critique or snipe at the software. Flow is when the user experience is no longer submerged in the software, but instead elevated to the outcomes that the software make possible.

Which brings me back full circle to a recent post of mine, where I was talking about Patricia Seybold’s new book, Outside Innovation. The excitement and the challenge of customer-created anything.
The excitement and challenge of helping make that happen.

Remember what Peter Drucker said all those years ago, something I’ve quoted before:

Shoes are real. Money is an end result.

Customers don’t want software, they want the things they can make and do because of the software.

When we speak of customer experience, it is not about the software, it is about the things they can make and do. That’s where the flow is, that’s where the joy and the magic are. I still remember the joy I had when I played my first Star Trek style game on a Commodore Pet, when I played my first text-driven adventure game on a Burroughs 6800, when I played my first game of Rats on a B20. Ah yes, nostalgia.

Whose joy? The customer’s. Who is in the Zone, who’s experiencing the flow? The customer. Who can define what that experience is? The customer.

Which is why everything we build should be built around user stories.

And that’s why I’m Confused. How come everyone doesn’t use Agile?