March 16, 2008

...Learn TDD with Codemanship

Scrum Delivers Nothing

Oh boy, here comes another ill-advised Scrum-related rant...

Before I start, let's just get one thing absolutely clear. I am not anti-Scrum. I am not saying that Scrum is Snake Oil. I am not saying that Scrum does not work.

I'm simply making an observation based on the experiences I've had with Scrum practitioners in recent years.

So here goes (now, brace yourselves).

Scrum, in of itself, delivers nothing. It achieves nothing. It is a car with a dashboard and steering wheel, but no wheels and no engine.

You can turn the wheel and honk the horn all you like, but without some actual kind of concrete delivery capability, you're going nowhere.

What prompts this tirade is that I'm sick and tired of reading blog after blog after blog about how to run Agile projects by people who appear to have either no interest and/or no ability in delivering working software.

I refer back to my earlier post about how easy it is to learn Scrum, compared to things like OO design principes or test-driven development or refactoring or configuration management and so on. And that's why, while interest in Extreme Programming* is on the wane, interest in Scrum just keeps growing and growing.

The learning curve for XP is very high compared to that for Scrum. But it seems that Scrum knowledge and experience is more highly prized, possibly because it appeals to managers who tend to have a bigger say in hiring and firing.

So we're increasingly seeing people who can talk the Agile talk, but who lack the unfashionable "hard" skills needed to deliver high quality software under commercial constraints. Indeed, more alarmingly, I'm noticing a trend among these Agile pretenders to downplay the "hard" skills and waste valuable time and energy on ever more elaborate and - in any practical sense - pointless rituals to clutter up the planning sessions, stand-ups, retrospectives and other forms of Agile worship.

How long before they start wearing special hats and special robes?

The real problem is that Scrum is just too darned successful for our own good. It's a highly infectious meme, and in organisations with limited energy and resources, it's just far too effective at competing with other pressing concerns - like usability or effective regression test assurance or minimising duplication in our code. The hard-to-learn and difficult-to-justify technical disciplines get starved of management support, and quality suffers every bit as badly as it did when PRINCE 2 was eating up our project budgets. Indeed, there seems to be a correlation between organisations who went for PRINCE 2 ina big way in the 90's, and are going all-out for Scrum now (or, more accurately, the irradiated mutant offspring of Scrum - Scrumzilla, shall we call it? - that has grown to monstrous proportions in recent years.) It seems to appeal to the same management vanities.

The beauty of Scrum lies in its simplicity. Take that away and it loses it's value dramatically. Ultimately, it relies on good deveopers doing good work. That's 99% of the equation. Scrum is just the 1% that's needed to provide focus and direction. Make Scrum a big deal, or lose sight of the fact that it still needs good developers doing good work, and you'll end up - well, where many Scrum projects seem to end up these days. Up their own arses.

You may now start throwing the furniture around.





* And, no, I'm not saying that XP is the only way to deliver software, either. I'm just using it as an example of "hard" skills.



Posted 10 years, 4 months ago on March 16, 2008