There’s a bit of a tempest going around …

In an interview, Ken Schwaber said I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”

I think that’s true.

On his site, Alan Shalloway converted that quote to “The Scrum community acknowledges that only 25% of teams adopting Scrum will get the value they hope to get from it.”

I think that’s exaggeration. 

Alan titled his article “Challenging Why (not if) Scrum Fails,” and refers  to “the high failure rate.”

I think that’s distortion.

My work, primarily, is helping Scrum teams get higher on the benefit scale. Every single Scrum installation I’ve visited has been pleased with progress, and wanted more.  

I think that’s important.

Alan's point ...

… and he nearly has one, is that Scrum (itself) does not change (itself). He asserts that Scrum should change, and that he knows how it should change. He thinks that Lean and Kanban and a few other things perhaps should be added to Scrum, and that somehow it would evolve.

Sorry, but that’s not the Scrum model.

 Scrum is about “Inspect and Adapt”. Scrum installations change. They are mandated to change, required to change. They are required to use every resource of their minds to see obstacles and impediments, and remove them or get around them. That’s the essence of what Scrum is.

Scrum is not a process based on a mass of  rules, principles, laws, and practices. It has a few roles, a few meetings, a few rituals. These frame a team’s work in a way that lets obstacles become visible. Scrum challenges the team to figure out what to do.

And that’s the end of Scrum’s job … and the beginning of the rest of your professional learning.

Teams using Scrum need to learn whatever will help them perform as well as they want to. Is Lean valuable? Certainly: many Scrum teams are applying Lean. Is Kanban valuable? Absolutely: there are probably more Scrum teams using Kanban boards than there are Kanban software teams in total. 

There’s a huge amount of material one needs to learn to be really good at anything, including software development.  There are many theories and principles that will help. The entire Agile / Lean / Scrum / XP / Kanban / Whatever community is engaged in finding better ways to be good at what we do.

It seems to be part of man’s history for a couple of people to get a hold of part of the same idea, then try to tear each other down for being wrong. I’d like the world better if it worked some other way, and mostly that’s what I try to do.

Would you like some help improving what you’re doing? I can help, and I can recommend others who’ll also help. 

Now then. I’m going out in the sunshine. Have a great day!

 Sunshine car: Montego Blue 335i Convertible