There is no "Agile" Chasm.

I keep hearing the question "has Agile Crossed the Chasm yet?". 

I used to answer "No, not really".  Now I answer, "Chasm?  There is no Agile Chasm.  It is an illusion."

Let me explain.

The Chasm

You've probably heard about the "Chasm".  It's the tar pit that new, disruptive, technologies get stuck in when the folk who have been successfully selling and marketing them to the "innovators" and "early adopters" in our population start selling and marketing them to more mainstream customers - the early majority.  They get stuck because - according to Geoffrey Moore, author of Crossing the Chasm - the people after the chasm need a different marketing message and a differently packaged product to what the innovative, early adopters need. 

The chasm is a useful metaphor and while I agree that it looks like it applies to Agile adoption it doesn't.  It only applies to a subset of agile: XP and (less so) Scrum.  I'll come back to them shortly.

Why?  Disruptive Technologies

The Chasm applies to DISRUPTIVE TECHNOLOGIES but Agile in general is not a DISRUPTIVE TECHNOLOGY.  Scrum and XP, both subsets of Agile are disruptive, but Agile as a whole isn't.  Go take a look at the Agile manifesto and check - there is absolutely nothing in the manifesto that is DISRUPTIVE.  There are a few things that are maybe a little different and might raise a few eyebrows, but there's nothing in there that is DISRUPTIVE. 

(This next bit is going to give a few Agile purists a wee heart attack).

You can do all of the things in the Agile manifesto by doing two things:

1. Break each big project down into a series of mini-projects where each mini-project delivers solid shippable code.  You'll do better if you prioritise the features first, start working on the most valuable features, and reprioritize between each project.  You'll do better and find it easier if you expect each mini-project to finish a little early or a little late, rather than dead on time.  You'll do even better if you expect to use the last mini-project as a buffer, to protect your delivery date - it contains the lowest value features anyway, so if you have to drop some of them in order to finish on time, you're not going to miss much. You'll find it even easier, when you realise that you'll finish the project sooner if you spend a little extra time during each mini-project making sure that the code is cleanish, malleable and easy to work with.  You won't be perfect, but you'll be better and as time goes on you'll find even more ways of getting better and better (see point 2) .
2. Setup a process of ongoing improvement.  It's not rocket science how you keep improving - I rely on Goldratt's TOC - but the key thing is to set time aside to sharpen the saw.  This is the process that gently adds other Agile practices as they are most needed.

Neither of those 2 steps are disruptive. 

Go ask any software development manager, any software developer, any analyst, or any tester if it is easier to deliver a 6 week project or a 6 month project?  Spend a little time helping them figure out how they can break a 6 month project down into four 6ish-week-long projects and they'll say - "this isn't all that hard.  Now go away and let me do it".

Then go and ask their project's Sponsor if they'd rather wait for  6 months until they can use the software or 6 weeks.  Answers will vary - some will love the idea, some will think it sounds like it makes more work for them.  Spend a little time with them helping them to see how they could be so, so much happier by getting the software earlier.  They'll find it a little unusual but not particularly disruptive. 

So why do people think there is an Agile Chasm?

People mistake the XP+Scrum chasm for the Agile chasm.

Many people think Agile = XP+Scrum.   

XP and Scrum are both disruptive.  They were designed to be.

[Disclaimer: XP is great.  Don't let anyone tell you otherwise.   In 30 years time XP will be know simply as Programming.  XP is up there with the invention of the steam engine and the light bulb. That's what they'll say in 50 years time.

Scrum is fantastic.  I've said this tons of times: I learned more in 2 days with Ken Schwaber than I learned in 4 years worth of MBA.  In 50 years time people MBA marketing courses will hold Ken Schwaber and Kent beck up as examples of early 21st century marketing geniuses.]

Both XP and Scrum invented their own vocabularies specifically to distinguish themselves from the mainstream.  That was pragmatic.  That's what you have to do to start a revolution.  It's good marketing.  The only trouble is that they now seem a bit radical to some people.  XP is quite big (on the face of it) to get started with and it looks like you need to be a rocket scientist to do it - there's a little truth in that.  Scrum is just iterative and incremental development - or, as I put it, doing 1 big project as a series of smaller projects - but its fancy words put some people off.

The 98% of people who hear the word "Agile" and think it means "XP" they think that it will be hard work to adopt Agile.  They think it will be disruptive. Many ordinary, pragmatic folk - the early and the late majority - think they can't do Agile.  So they're missing out.

That's why I've started all this crazy talk about EverydayAgile.  I didn't want to invent a new term ... but I can't think of any other way to speak to the people who think agile is too hard - disruptive - for them because Agile=XP. 

People can get happier and businesses can make LOADS more money by adopting EverydayAgile.  It's not hard.  It's easy.  It's easier than what you're currently doing.  There is no EverydayAgile chasm.

In fact, assuming you can already develop software successfully, using the old ways, there are only THREE things you have to do to do EverydayAgile.  More on them shortly.

Comments

[Bruce]

Clarke,

You explain the agile v xp/scrum distinction nicely. Thanks for that.

On a similar note, or tangent, your notion of chasm suggests that the 'mainstream' will pick up the agile trend at some point. This means that eventually more people will be doing agile, than will be doing heavyweight software projects. Would you hazard a guess at

A) what the current balance between agile (or lightweight) and waterfall, et al (or heavyweight) methodologies might be, and

B) when the majority of software might be done with agile methods?

If you don't want to do 'B', could you suggest what conditions might be necessary for this to happen?

[Kevin Rutherford]

A process of ongoing improvement IS likely to be seen as disruptive in an organisation whose processes are defined and imposed from the top.

And incremental development IS seen as disruptive in organisations that are afraid to deploy new software, or where the reaction to past failures has been to raise the entry barrier so that only "mature" ideas survive past infancy.

[David Peterson]

Right, so the UK government can easily switch to your brand of agile? I don't think so. The traditional big specification, big design up-front process is engrained in every pore of some organisations. It's very easy to say "break each big project down into a series of mini-projects", but not so easy to put into practice. Agile methods ARE disruptive. You say it yourself: some managers (early adopters) will love the idea of 6 week deliveries and some will think it sounds like it makes more work for them. It's convincing those people that is the difficulty. That's the chasm.

[Steve Freeman]

At one level you're right, breaking stuff into manageable bits is fundamental good sense, as is a culture of improvement. Sadly, as the others have pointed out, this is totally radical in many organisations. It happens that there's a nice little quote in the most recent Cringley rant:

"Rather than make applications more reliable and reduce problems, IT managers seem to prefer shopping for cheaper labor."

and I've been corresponding with a business school professor whose mission in life is to put an end to mega-ERP implementations commissioned at too high a level to understand the consequences. And a previous employer of mine combined continual running down staffing levels with grandiose schemes for new architectures. etc, etc.

[Niraj]

Hi Clarke,

If you wanted to "rebrand" your agile offerings, why in the world would you call it "EverydayAgile"? Wouldn't these people you believe to equivocate agile with Scrum+XP and thus feel agile is disruptive, have a knee jerk reaction that your "EverdayAgile" is some variant of this disruptive process?

Nice to meet you.

Niraj.

[Niraj]

Hi Clarke,

If you wanted to "rebrand" your agile offerings, why in the world would you call it "EverydayAgile"? Wouldn't these people you believe to equivocate agile with Scrum+XP and thus feel agile is disruptive, have a knee jerk reaction that your "EverdayAgile" is some variant of this disruptive process?

Nice to meet you.

Niraj.