Skip to content


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

Posted in Software.


7 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Justin Brister says

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

    http://jbrister.blogspot.com/2007/01/to-agile-and-beyond.html

    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 Brister says

    Had a quick stab at the Joel Test;

    http://jbrister.blogspot.com/2007/01/agile-joel-test.html

  3. Phil says

    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.
    Phil

  4. James Governor says

    we have done some work thinking about the smell of agile lately
    http://www.redmonk.com/cote/2006/12/05/the-smells-of-agile/

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

    http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/

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

  5. Justin Brister says

    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.

  6. Mohan says

    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?

Continuing the Discussion

  1. Scott Rosenberg's Wordyard » Blog Archive » Blog responses to Dreaming in Code linked to this post on February 14, 2007

    […] From JP Rangaswami: If you’re interested in software development, you should read the book. […]



Some HTML is OK

or, reply to this post via trackback.



%d bloggers like this: