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:
- 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) .
- 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.
