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:

Development models

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 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?

7 thoughts on “Musing about Agile”

  1. Funnily enough, I have been musing on pretty much the same thing, although maybe from a different angle;

    I see Agile evolving to push more and more of the responsibility to the user, through concepts such as Service Factories. I am still trying to define what these Service Factories might look like and how they would work. I see users being able to create their own solutions on top of a virtualised delivery platform, without needing any specialist technical knowledge.

    Re: The Joel Test, I can see changing this to talk about build every compile, tests driving development etc. I might spend some time on this, as it could be a useful litmus test for our development teams.

  2. Justin,
    I think your first stab is good…. and similar to the set I dreamt up in my head.
    I would be inclined to add something about documentation in code to be just good enough. Almost a Design by Contract model. External Communication is also important, but must not be a burden.

  3. we have done some work thinking about the smell of agile lately

    just a slightly different perspective. the user is king, but needs to be crowned by the developer, not the sales or marketing department.

    an interesting tension between Extreme’s YAGNI (you aren’t going to need it), and user-driven adoption, with flow.

  4. Phil,

    I agree, adding something about self-documenting code would be good. I think that Design by Contract is kind of covered by the Test Driven Development (contract between actor and component). I guess that from an architectural perspective, contracts between internal interfaces is important, and I guess something about high internal cohesion and low external coupling could also be included.

    I will have a go at refining this when I get the time.

  5. Interesting viewpoing “Customers don’t want software, they want the things they can make and do because of the software.”

    This said, software is not just about customers.. It is also about enabling businesses to help their customers.

    I guess I am talking about the non-sexy Electronic Data Processing needs where the requirements for, say payroll processing or accounts receivable are well laid out and just needs to be done. Bulk of such work need not be agile, eh?

Let me know what you think

This site uses Akismet to reduce spam. Learn how your comment data is processed.