Agile Manifesto – The First Amendment

Riddle me this:

Q – What’s the #1 difference that an agile approach gives you versus old-skool software development methodologies (hint clue’s in the name)

A – Quickly or “agilely” getting working code into your end-users hands

It’s this answer that an awful lot of people miss, and it’s why I propose the first amendment to the Agile Manifesto:

“Any agile process should strive to get working software into the hands of end-users as quickly as possible.”

Let me now explain my reasoning:

There is an awful lot of guff talked about agile, for example, I’ve held my head in my hands after reading some recent blog posts discussing Cynefin and complexity thinking.

This sort of pontificating rubbish is what gives the consulting industry a bad name.  The main elements of developing software are the same as they’ve ever been from the Waterfall method on down – Requirement gathering, Design, Implementation, Verification (Testing) and Maintenance.  Agile (in any of its forms) isn’t a silver bullet and doesn’t magic away any of these elements, it’s just a different way of mixing these basic ingredients to build the same cake.

To stretch the baking metaphor – proponents of agile will tell you that with a Waterfall methodology you might end up with a Dundee cake, when the users really needed an Eccles Cake.  This is exactly right, but the fundamental point is you’re only going to know the users wanted an Eccles Cake if you show them the first slice of Dundee cake, and they say “I’m sorry but you have misunderstood my requirement”.

So what? The point is that only the end-user can know if the product works for them.  However, often the end-user never sees the product until the end of a 12 month development phase, much like the Waterfall method.  What gives?

This problem is common in web-development.  You win a nice fat contract to build out a site for your customer (lets call them AcmeCorp).  The dev-team apply their shiny agile methodology and ship working code to AcmeCorp every few weeks.  AcmeCorp looks at it and supplies comments etc, you ask for clarifications, get more requirements and so on and so forth.

12 months later AcmeCorp launches their shiny new site, but it doesn’t get the traffic they expected, or users don’t like the features, or it doesn’t appeal to the target demographic.  Spot the problem?

You might as well have managed the project Waterfall style, you did 12 sprints/iterations/leans/kanbans/cynefines, but from the End-User point of view, it was a big-bang delivery.  You’ve been doing CAT (Customer Acceptance Testing) when you should have been doing UAT.  Arguably there may have been some benefits about getting feedback from your Customer, but if you are not getting feedback from End-Users as early as possible in the project, you’re asking for major trouble.

Conclusion

Agile teams must strive to get feedback from the end-users, not just the customer, as early in the project as possible.  As the feature you and the customer are convinced is the killer-app, may well be something your end-users don’t care about, or don’t understand how to use effectively.

UAT is the name of the game, and Agile teams should impress upon their customers the importance of putting the product under the noses of the real end-users as early as is feasible.

Advertisements

11 thoughts on “Agile Manifesto – The First Amendment

  1. I’m interested in getting more detail about your opinion on my “pontificating rubbish”. My intent was to help coaches and change agents get people to talk to each other and use Scrum or Kanban more effectively to do that. What did I miss? How could I do that more effectively? I’d appreciate some constructive feedback, or even a more useful criticism.

    • Sorry Liz but I hate these meta discussions about process, where interminable naval gazing at the process will somehow divine yet another better software methodology. I’m not even sure what point you’re trying to make in your post. I fear the basic tenets of agile and XP are being lost, in ever more jargon and mumbo-jumbo of which your post is an archetype (there’s plenty of others I could have used). Where something that was simple has been completely over-engineered, with consultants, and 500 page manuals (see Rational Rose etc)

      I’m not saying that process is unimportant, or requirements gathering is a waste of time. But the fundamental principle of agile is to get software into the hands of end-users quickly and get some feedback, is being lost.

      • OK. There are a couple of reasons I wrote that post. One was this – http://scrum.jeffsutherland.com/2011/11/alternative-to-kanban-one-piece.html – a piece which criticises Kanban but in which the author doesn’t seem to realise that we don’t do it the same way as production lines. The other reason is because I’ve seen too many coaches apply Scrum prescriptively and completely inhibit the team from actually delivering anything. Just because you work in a place where you can ship regularly doesn’t mean everyone is there, and the “navel-gazing” is mostly about how to help them get there as quickly as possible.

        I *also* write posts about how important it is to ship and get feedback. Here’s one: http://lizkeogh.com/2007/03/16/feedback-loops/ . The stuff I’m writing about in the post you reference is orthogonal, and if you don’t see the point then it might be because it’s not really relevant to you.

        There’s nothing “simple” about groups of people working together. If there was, we’d have sorted this problem out a long time ago.

  2. OK the post you link to is far clearer, but I notice it’s from 2007. I’m speaking of the increasing trends of late to add a lot of noise, platitudes and jargon around agile that just didn’t exist 5 years ago.

    Of course group management is complex. I’d argue that no process will ever be able to model and manage group dynamics, as by definition every group is different and contains a mix of different skills and individuals. So by trying the old consultant trick of throwing jargon and models and stating it’s a complex isn’t an aid to clarity, it just muddies the water.

      • lol, OK fair comment, although we used to call a coach, a consultant in my day (just joking ;-). I read some of your more recent stuff and it was a lot more pointed which was good. I just want to keep agile lean and mean, and not fill it with fluff.

    • Jordon, I couldn’t agree more. Agile is turning itself into an industry filled with “agile coaches” and “change agents”, to quote from Liz, spouting pretentious rubbish about complexity theory and quoting from Socrates.

  3. Pingback: Liz Keogh's blog » CALMalpha – the first request

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s