From time to time, we see people complaining about Scrum and agile being sold as a magic painless solution to all your problems. We can’t seem to catch anyone in the act of making these claims.
So who’s going around saying Scrum is a silver bullet, and that it’s all you need? Ken Schwaber’s not saying this; Danube isn’t saying this; other Scrum trainers and coaches aren’t saying this … at least not when I’m around. We’re all saying quite the opposite. I see more complaints about hype than actual hype.
Last month, I saw something that tickled my cringe button a bit: a well rehearsed presentation about an agile transformation at a major software company with a large sophisticated online product. The presenters claimed 95% customer satisfaction with their product. I asked a few friends who actually use this product what they thought of it; they were less than 95% satisfied.
But even that slick presentation acknowledged the journey was painful and confusing. Success was not guaranteed. For months the Scrum coaches were the most hated people in the company. Management practices from top to bottom had to be realigned with delivering value.
What’s more, Scrum was not enough! It wasn’t designed to be. They also needed to learn engineering practices the eXtreme Programming (XP) movement has tried to advocate since the 90s.
Wouldn’t it be nice if teams doing traditional development could suddenly start doing the XP practices all at once?
If the instant “zero to hero” approach had a higher success rate, XP might have already transformed the industry and we wouldn’t need Scrum. But this didn’t happen. It turns out there’s a curve in “learning curve.” I won’t say XP fizzled, but it can reach a lot further than it has so far.
Too many clients I meet claiming to do XP are just making excuses for not doing design or documentation, without really doing the 12 XP practices. Other times it’s only a couple people on a “team” lacking the collaborative environment needed to make these the whole team’s practices.
This is where Scrum comes in. Scrum gives teams the space, the incentive, and the peer support to start improving skills and habits at Test Driven Development, merciless refactoring, continuous integration, and pair programming (or at least more frequent code/design reviews).
Too many teams attempting Scrum get stuck on the path, not getting as far with their engineering practices as we’d like. Changing habits is hard work. But I do know these teams have a better chance with Scrum than without it.
—mj (Scrum Trainer and XP advocate)
Download the PDF version: Scrum Hype vs Scrum Education blog