Scrum, the Agile methodology allegedly favored by Google and Spotify, is a mess.
–Giles Bowkett

Giles (@gilesgoatboy) has written this article, plus a follow-up. Check them out. Giles is not a happy camper and he’s blaming Scrum for his concerns.

My first reaction was not the best. I should have compassionately embraced Giles’s pain. The things that he describes in those articles are bad things, and they should not happen. I am not able to stop them, because they are in the past and I can’t sit down with him and those teams anyway. I do have some advice that might be useful to him, or to anyone having similar experiences. Listening better would have been a good start. But hey, I’m a computer programmer, not a shrink.

My first reaction, instead, was to point out that almost none of the things Giles complained about are actually part of Scrum. They are, of course, things that people trying to use Scrum sometimes do. People using Scrum do lots of bad things that Scrum doesn’t include. Let’s look at some of those and see if we can put them in context and offer a bit of advice.

The first bit of advice that I might offer, Giles has already implemented. He got the hell out and went to a better place. Well played indeed. As Martin Fowler put it, “Change your organization, or change your organization”. Giles has gone to an organization that pretty much understands Agile. Interesting. I wish him a better experience this time, and expect he’ll find it.

Now to the articles, or some highlights at least.

Is Scrum what we say it is, or what people do?

Individuals and interactions over processes and tools? We need tools! Are you trying to send us back to the dark ages?

Every bit of advice you can give can be misused, and will be misused. It can be taken amiss and will be taken amiss.

To survive as someone who tries to give people the best advice I can, and who then sees them spin off the rails doing something else, I’ve had to learn to measure myself by how well I am understood, not by what people do with what I tell them. It sort of works, but I still have difficulty being understood. I keep trying.

I do think it’s fair of someone who teaches something to point out when people aren’t doing what he tried to teach them. And it’s also fair of people to respond that someone taught them whatever thing they’re doing instead, and told them it, too, was “Scrum” or “Agile” or “TDD” or whatever.

Nonetheless, I was there when the Agile Manifesto was written, I was there when Extreme Programming was invented, and I think I get to say, to the best of my ability, what these things are, and what they are not. Let’s look at Giles’s specifics:

Story Points

If you’re lucky, you get a variant called “the person with the highest status on the dev team tells everybody else what the number is going to be,” but that’s as good as it gets.
– Giles Bowkett

My colleague James Grenning invented planning poker, and I was with him for some of the earliest implementations, so I feel pretty confident saying that “highest status wins” is not the idea. In fact, Giles quotes a decent Wikipedia description of planning poker, while reporting that that’s not what the teams he has seen actually do.

A nontechnical participant has, at any point, the option to pull out an egg timer and tell technical participants “thirty seconds or shut the fuck up.”
– Giles Bowkett

Huh? How does a non-technical person even get an opinion on how long something takes? Where did that part of the scheme enter in? I get that that would be a living hell, but it sure isn’t what any of us who speak about planning poker have in mind. What’s going on here, and why is planning poker being blamed for the fact that Giles seems to be surrounded by assholes?

One might also mention, in passing, that Stories, and Story Points, are from XP, not from Scrum, and that they are not (at least as yet) part of Scrum canon. That’s quibbling a bit, because they have certainly found their way into common practice. But still, is it unfair to expect the tool to be used wisely?

Well, maybe not unfair, but perhaps unrealistic. People do cut their fingers off with the band saw, and I guess people do get told to shut the fuck up in a planning poker session.

Should not happen. Should never happen.

What should happen

Let’s hit this one hard the first time, in hopes of just tapping it the next time.

First, everyone should know that the meeting shouldn’t go that way. Where was the ScrumMaster, part of whose job is to see that the team executes their chosen process effectively? ScrumMaster should see that the right people are in the meeting and the wrong people aren’t. ScrumMaster should facilitate so that people aren’t shut up (while keeping the meeting on track.)

What about the Retrospective? Someone ought to say that planning is not working because people are pushing estimates that are wrong, and terminating discussion too soon. It should be easy to point to dysfunctions like stories running over time, and increased defects due to lack of understanding. But even without numbers, abusive behavior needs to be stopped. No one in Scrum wants abusive behavior. Even if some of us may sometimes accidentally exhibit some.

What about Inspect and Adapt? The essence of what makes Scrum work isn’t the three roles, the five meetings, the one artifact. It’s Inspect and Adapt. When things are not going as you like, you’re supposed to fix it.

Scrum does not say this!

Things were not going well in planning poker and Giles’s team did not fix it. That makes me sad, very sad, but it doesn’t make me want to blame Scrum. Frankly even if Scrum did say “Sometimes in planning meetings tell people to shut the fuck up”, that would be so obviously wrong that you’d be a fool to do it.

So. ScrumMaster is supposed to keep the team on its practices. The team is supposed to review and update its practices. And someone with a pair could take an individual aside and tell them not to be a jerk.

Time Boxes

I’ve twice seen the “15-minute standup” devolve into half-hour or hour-long meetings where everybody stands, except for management.
– Giles Bowkett

Um, what? It’s not called the 15 minute standup so that it can take an hour. The point of the time boxes in Scrum is for the team to learn how to get things done in the time allotted. In the end, the learning goes like this:

Hmm, we can share status and update the plan in only 15 minutes. Wow, we can plan two weeks work in only two hours. OMG, we can get our planned work done in the two weeks allotted. We rock!

Then the big learning: we can ship this product on time, because we can ship what we commit to in two weeks, planning it in only two hours, coordinating for only fifteen minutes a day. If you will learn to work within the time boxes, you’ll learn to ship the best possible product on the day they want it. You won’t get everything they ask for: they always ask for everything. But you can have the best possible product, ready to go, on that date. And it’s the time boxes that do that.

To be fair to Scrum, it’s not intended to work that way …
– Giles Bowkett

Why didn’t the time boxes do that for Giles’s team? I don’t know, I wasn’t there. But I do know that they didn’t honor the standup time box, and if you’ll read on you’ll discover that they didn’t honor the intention either.

I’m sad that Giles suffered through this, and doubtless everyone else on the project suffered as well. And I’m sad that they didn’t follow our advice very well. And I guess I’m sad that we didn’t make it clear enough that it wasn’t called fifteen just because it was the fifteenth idea we had had.

And I’m glad Giles remarks that Scrum does not intend what happened on his team. It does make me wonder why this article wasn’t entitled “Company XYZ and Every One of its Managers Should Just Die in a Fire.” But let’s move on.

“Sprint” and “Backlog”

Giles objects that these are not good words, because sprinting isn’t sustainable and you start right off behind, with a “backlog”. Yeah, I get that. XP called them “iterations”, which is more neutral, and had “User Stories” but no name for the collection of things you wanted. We kept the cards in a lunch box on the first XP project and maybe that would have been a good name.

I’m not sure I’d call those “conceptual” flaws, as Giles does, but they’re not the best possible names. Mary Poppendieck, for example, has long objected to “backlog”. Again, I get that. And I don’t care. Of course you have a list of things you want: you’d be a fool not to. What I’m aware of, and I don’t think it’s like some amazing hidden truth, is that the Product Owner’s job is to select what to do next, and what to defer until later, to get the best possible product by the desired delivery date.

I’ll wager Giles’s team’s Product Owner didn’t have that as their prime responsibility. I’d even put a little down that they didn’t have a real Product Owner at all.

Three bloody roles, Scrum has, and only three. If you can’t get that right, don’t call it Scrum, OK? Oops, sorry, I forgot I’m being compassionate. But for cryin’ out loud, is it so much to ask that you be near the ball diamond before you call it baseball? Which reminds me of We Tried Baseball and it Didn’t Work. Check it out.

But I digress. What else do we see in Giles’s cri de coeur?

Velocity

Giles objects to velocity. I could do a better job of objecting to it, and who knows, somewhere in here maybe I have, but the point is a good one. Velocity is so easy to misuse that one cannot recommend it. We did say “working software as a measure of progress”, and that’s still the best I’ve got.

You’d think that if you sliced your features small and counted them, you could get a good sense of how much you could do by the deadline, and that would help you with your planning. It’s even true but it’s too easy to resort to pressure rather than to slicing and selecting what to leave out.

I no longer recommend velocity, which means that I also no longer recommend story estimation in points or other measures. Many people disagree with me but that doesn’t concern me. See this index for some stuff I’ve said about the topic.

In my thinking, velocity is an obsolete topic. Out there in the world, estimates will be with us for a long time and will be misused. They were before Agile came into being, and will be for a long time to come. For my part in it, I apologize. Meanwhile you’ll need to deal with the topic as best you can, because it’s not going away. Consider the “Five Card Method” that I talk about in The Nature of Software Development.

Summing Up

I’m hoping to find out more, later, about what it’s like when you’re on a Scrum team and it actually works. To be fair, not every Scrum experience I’ve had has been a nightmare of dysfunction; I just think the successes owe more to the teams involved than to the process.
– Giles Bowkett

Yes, well, of course what happens is about the team. “Individuals and interactions over processes and tools”, remember?

I hope that Giles has a good Scrum / Agile experience in the future, too. I’m not sure just what they do at his new company, Panda Strike, but I hope he’ll find some good Agile-based ideas there, and I think probably he will. More than that, I hope Giles finds a fun way to be productive, because that’s more important than Agile or Scrum or any of that stuff.

That said, I’ve been doing software things for a half-century, and Agile is the best way I’ve found. Scrum, like it or not, is the face of Agile, and I’ve seen it help lots of people and lots of companies. They do need to stay pretty close to what we said, and they do need to inspect and adapt. They may wind up a long way from Scrum and Agile ideas, but I suspect that mostly, they won’t. They’ll add in a lot of things, but shipping running tested features quite often is likely to stay in their approach.

To me, shipping desirable software frequently is what it’s all about. But if Giles finds, or you find, another way to be happy … that’s just great with me. Go for it!