Again today, I wake up to yet another report on Scrum’s failings, this time from Mike Sutton, whom I much admire. Read his article here.

Now certainly Mike’s list of Value, Flow, Quality, Joy, and Continuous Improvement represents a good way to assess whether an organization is “successful”. Note that Mike includes “consistently delivering value” as part of this assessment.

Mike rightly points out that Scrum’s tiny collection of roles, rituals and artifacts is not a recipe. He rightly points out that there can never be an all-encompassing recipe. I’m totally on board there. Mike also says, “almost everyone takes it as a recipe and they follow it”. I have issues with that last.

First of all, I see little evidence that almost everyone takes it as a recipe, and absolutely no evidence that everyone follows the recipe. I visit many teams who call what they’re doing “Scrum” and very few of them are in fact even following the recipe, if recipe it is.

Mike tosses in a paragraph about how the Scrum Alliance amounts to Scrum 2.0, together with some very mistaken history as to why there was a split. The split was certainly unfortunate, but it was not due to a split in dogma. And since the Scrum Alliance and both subscribe to the Scrum Guide, there is still no split.

And, of course, no Scrum 2.0 is a problem as Mike sees it, because he seems to think that some change to Scrum is needed. He says:

I don’t hate Scrum – I’ve just used it long and deep enough to understand which bits I would throw away and which I would keep, what contexts I would use it in and which I would bury it so deep – no one would ever find it.

Unfortunately, Mike hasn’t as yet written the part about what he’d keep and what he’d throw away. I hope he will: I’m much more interested in what works than what does not.

Take a look again at the article. Look at the abuses he describes, such as over-worked ineffective product owners, ScrumMasters left hung out to dry without support, teams who can’t own their tools, craft, and collaboration. Those are all abuses. I repudiate each and every one of them with all my heart.

And Scrum surely does not recommend any of those. It’s quite easy to find absolute repudiation of those ideas in the Scrum writings.

Perhaps you can see why someone who has thought about Scrum for, oh, fifteen minutes, would say “That’s not Scrum!”

But suppose we accept, as I do, that [some/many/most/all] Scrum teams fall far short of what Scrum seems to offer. Take it that they “fail”. Now I’ll wager a day’s pay that in a day I can find where they’re not doing what Scrum says to do. (I really will make that bet. My daily rate, or nothing, if your project is “failing” and I can’t find a major deviation from what has been recommended.) As a hint to save you the money, here are some of the things I’ll look for:

  • Fully empowered Product Owner, accountable for maximizing return on investment in the product, able to say what to do and what not to do;
  • Fully cross-functional Dev Team, shipping tested releasable software every Sprint;
  • Sprint Review with stakeholders, showing them what we’ve got and hearing where they want to go;
  • Sprint Retrospective focusing on what is really wrong and doing something about it;

Something wrong with Scrum?

Mike and Giles and I all agree that Scrum teams are not experiencing the success that we’d like to see, and that we might naively expect based on what we hear about Scrum.

We do not agree, quite, on the reason. Mike and Giles and many others think there is something wrong with Scrum. To me, that’s a bit like believing in magic. In the business of magic, you have to say the words exactly right, make exactly the right gestures, and hold your wand just so, or the magic doesn’t work. These guys believe, it seems, that if Scrum just said the right things, and said them right, it would work and all the failing would end. I don’t think so.

To be fair — and I am trying to be fair — I think Mike really doesn’t believe in a written-down process at all. He tweeted to me about setting a direction and helping the team identify signals, in their context, as to how they’re moving toward that direction. He said “You can’t tell people everything. So tell them nothing.”

Of course, that doesn’t mean shut up and walk away: I know Mike well enough to be sure of that. I take it to mean that we help people to find the direction they need to go, to make it clear to everyone, and to check and see whether they’re heading in the right way.

I don’t know whether Mike would tell them how — here are some ways — to find direction, make it clear, see how you’re doing, or not. I suspect he would: otherwise it would be a short meeting.

What’s interesting is that whenever I get into one of these Twitter conversations, at least if I dot the names enough to pick up a few people in the conversation, I inevitably find someone who seems to be saying that it would be better to just tell people what to do. Force them to TDD or something. I refuse to be told what to do. That’s why I work for myself, and I don’t pay much attention to what I tell me to do either. So I will not tell other people what to do, not in the sense of “you must do this”. I might sometimes fall into the trap of saying “you should test that”, but I wish I wouldn’t even do that. What I try to do is to say “Here’s what I do, here’s why I do it, here’s what happens,” and leave it to the listener to decide what to do with what he has heard.

I try never to stop until I’m sure I’ve been understood, or until I catch on that people aren’t listening. But I never tell them “you must do such and so.” Even in the Nature book and the related talks I do with Chet, I might say that I believe there is no alternative to testing and refactoring if you want to successfully work in iterations, but I still try never to say “you must”. I do think you’ll fail if you don’t, and I make that clear, but it’s still up to you whether to pay attention, still up to you to decide what to do.

So I’m kind of on Mike’s side when it comes to dictating practice. Nonetheless, I believe in having practices and doing them, and I believe that empowered product owners, frequent increments of tested working software, regular stakeholder contact, and regular improvement are pretty darn good practices to have.

One question

You’ve gotta ask yourself one question: “Do I feel lucky?” Well, do ya? – Dirty Harry

When you start your next project, using some method we’ll call without loss of generality “Scrum”, ask yourself this: “If this project is successful, are we going to say ‘we succeeded’ or are we going to say ‘Scrum succeeded’?” Write that decision down. Then, succeed. If, however, you do not succeed, look at that card. If you were going to say “We succeeded” — and I hope you were — then you owe it to yourselves to say “We failed”.

If you want to own your successes, you’ve got to own your failures as well.

Yeah, fine, sure, but couldn’t Scrum do better?

Well, let’s see. It could die in a fire. According to Giles, that might help. Or it could be replaced by nothing, which Mike’s tweet seems to recommend. It could be replaced by something more stringent, like requiring, I don’t know, TDD, or the use of SharePoint. It could be replaced by something simpler, like Crystal Clear, or something more disciplined like DAD (Yes, Dad, sure) or something containing all other ideas in the known universe, like SAFe.

Or maybe it should just be expressed better. Yeah, because the existing books about Scrum have all been so carefully read and followed. Schwaber^n, Sutherland, Rawsthorne, Rubin, Sims&Johnson, Cohn, Goldstein, Lacey, take your pick. Try to pick from the top tier of authors, of course. But in those books you’ll find plenty of good advice, and not one of them is going to tell you to have 90 minute standup meetings, overworked product owners, or incomplete teams who can’t control their work. Not one.

You could even read Nature, which won’t tell you any specific thing you should do, while describing seven things to keep your eye on, namely guiding, organizing, planning, building, slicing, quality, and value. And there are pretty pictures and some supporting articles as well.

Every time I write about something, I write about it a bit differently, in hopes that this time, these words will grab someone who wasn’t grabbed before. So I’m all for expressing ideas like Scrum differently, and hopefully better. I do not believe that one single expression will work for everyone. Some people really want, and perhaps need, lots of direction. Others want to see the big picture and find their way on their own. Others are in the middle. You can’t fit that into one book, much less into a few pages of Scrum Guide.

Or at least I can’t. Maybe you can. Thus:

The Challenge

Quit yer belly-aching!
– Ron Jeffries, Sr

The challenge to you, Giles, you, Mike, and you, [Your Name Here], is to move beyond complaining about how screwed up Scrum is and start telling us things to do and things not to do, reasons to do or not do them, ways to know how we’re doing.

Take us forward.