James Shore wrote a brilliant article titled The Decline and Fall of Agile. Excerpt:
But because Scrum works in short cycles and doesn’t include any engineering practices, it’s very easy for teams using Scrum to throw out design. Up-front design doesn’t work when you’re using short cycles, and Scrum doesn’t provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt. Two or three years later, I get a call–or one of my colleagues does. […] By that time, fixing the real problems requires paying back a lot of technical debt, and could take years.
What frustrates me the most is that this situation is entirely avoidable. In a green-field environment, the solid agile engineering practices included in Extreme Programming pay for themselves within the first few months. […] Doing anything else is pure negligence… […]
It’s not entirely Scrum’s fault. Agile development isn’t just about good engineering practices. It’s also about acknowledging the importance of people in software development, forming cross-functional teams, obtaining high-bandwidth communication, constantly reflecting and improving, delivering value, and changing plans to take advantage of opportunities.
Scrum includes these other points. […]
But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.
And my favourite paragraph:
These teams say they’re Agile, but they’re just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It’s the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables. By leaving out all the other stuff–the stuff that’s really Agile–they’re setting themselves up for rotten teeth, an oversized waistline, and ultimate failure. They feel good now, but it won’t last.
What James describes in his text is what we, consultants, see every single day.
The article suffers from Silver Bullet Syndrome–ironically, it’s true but for the wrong reasons. The curve of methodology usage is strongly skewed in the bad direction for any technology, like it is for any expertise worthy our while.
It’s quite obvious from the past history of the field–or any field at all-that you can always make a living of “fixing” incorrect usage of “methodologies”. It’s true of RUP, waterfall or insert any of your old-schoold methodology here and it would be surprising if it wasn’t true of Agile/Scrum as well.
Bemoaning this fact and calling it the fall of Agile is just simple-mindedness at best. In any way, Scrum adoption is just like the old koan: “If you meet the Buddha on the road, kill him”.
I thought it was a great, timely post, but Uncle Bob doesn’t seem to agree:
http://blog.objectmentor.com/articles/2008/11/16/dirty-rotten-scrumdrels
It’s always nice to read something that is aligned with your thinking.
I would put a couple of thoughts to you:
1 - XP practices won’t save you from getting into this situation. No practices will.
2 - “What James describes in his text is what we, consultants, see every single day.” What do you think should be done about it?
@Ronaldo,
I’m not sure I understood your comment. The fact that you need your car fixed doesn’t mean you can’t get a better car to start with -or use your car properly.
@Colin
I think Uncle Bob didn’t get the point. As James commented the text is a rant.
@Lachlan
Good questions.
1) I don’t think James’ text is about specific practices from any methodology. I see his warning as “you can’t remove engineering practices from an agile project”, what is something I totally agree with.
2) Don’t try to make of agile software development a generic project management toolset. We already have one and it doesn’t work well for software development.
I totally agree with James.
Some people say that scrum has good pratices for management and I agree. But… What are we building? Software?
Or in the worst case trying to adopt just because it is the last hype.
The secret are the principles, and a good agile team must have habits and practices in harmony with that. It’s not just about using post-its and planning every week…
Cheers!
@Phillip: You said… “What James describes in his text is what we, consultants, see every single day.”
And don’t forget those teams doing Daily Meetings as pure Status Meetings.
Here’s a story… Project Manager command and one talk. And that one talks to the project manager, not to the team. And no knowledge sharing, just strait talk. And the PM asks percentage done of the task and also recommends one extra hour from the person, to help task completion.
It’s crazy. Like James said.
“But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.”
One I was watching a presentation and a person in the audience asked to the presenter… “Hey, isn’t this bad, I mean, people doing all this mess in their companies and teams?”
And the presenter said:
“Well, it’s very bad, but thanks to them I have a job. :-)”
@Shoes: Of course not, but trying to characterize this as the “decline and fall of agile” is just misleading. It’s quite obvious that you can’t take engineering practices from agile processes, and that’s true of anything else in development.
What I was trying to say is that James has taken a fact that applies to any market and methodology and philosophy and passing it as a specific problem with Agile and Scrum. It simply doesn’t make sense. Even if Scrum were to blame for problems in the Agile model, James arguments wouldn’t apply.
Ronaldo,
I don’t think you got the spirit of his post. It’s a rant and this means that it will contain bombastic yet vague claims that are mostly useful to catch your attention.
Also I don’t think James blames Scrum, he blames people that use Scrum and forget that software engineering is about… err… engineering. An iterative and collaborative process is great but lack of engineering won’t get you anywhere.
As a professional software developer and a consultant I can tell you that it is not obvious that you can’t take engineering practices out of development processes. Five minutes in any mailing list will show you so.
And I still don’t get your argument about “a fact that applies to any market and methodology and philosophy”. He didn’t say it is a problem that happens only with agile processes, he said it is a problem agile processes have! If this is a problem other fields or techniques have too that does not mean we should ignore the problem with the agile community/field/methodology/whatever.
James himself characterized it as essay and not as a rant in the comments on Uncle Bob’s article (which was a rant itself). At not point of the text, he uses any amount of the usual irony and desultory arguments of a rant.
I’m not, of course, advocating that we should ignore the problem. My entire point is very simple: he’s taking something that is clearly a case of 80/20 reality and turning into an argument about an entire age (so to speak) of development. At least to me, the point is kind of moot. Of course if you take a process designed for one thing and try to pass as another thing you’ll have problems. Of course, it’s a problem that most people adopting Scrum/Agile will have. Of course there’ll be people selling it as a silver bullet. Been there, done that. See Peopleware and The Mythical Man-Month for similar arguments.
About the non-obviousness of the need of engineering processes, I don’t think you can use a mailing list to demonstrate the point. I’d say that would only prove Sturgeon’s law.
At the point I’m currently in my career, I’ve been avoiding to work with people that don’t get this and that’s it. Not all people will have this opportunity, but you can always find ways to exercise you engineering muscles. Leave the non-obviousness to the failing companies. 
Anyway, I’m not a professional software developer and I’m not a consultant so it’s very probable I’m just not getting James’ point. I can live with that.
I can’t really understand why a rant cannot be presented as an essay. Even if it couldn’t saying something doesn’t change the reality, and unless Shore presents some research his text is a rant (“a loud bombastic declamation expressed with strong emotion”).
I think you may be getting too attached to the article’s title. James didn’t say that all teams using Scrum/agile/whatever will fail, he didn’t even say that most of them will. He said “a lot”.
If you can choose a good team to work with you are lucky but in most cases people don’t have an option.