Yesterday I tweeted this:

Scrum is not an agile software development framework. Scrum is not a software development framework at all. Scrum people have been telling me that for years. I should have believed them.

Clickbait and provocative, of course, but also quite true. Let me explain. No, it is too much. Let me sum up.

Many Scrum experts say that Scrum is a product development framework. The Scrum Alliance says:

Scrum is a simple yet incredibly powerful set of principles and practices that helps teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change.

while the Scrum Guide, and scrum.org says:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

None of these definitions mentions software development, nor the word “agile”, much less “Agile”. That’s probably a good thing.

Scrum itself, in my view, is a good thing. It’s not the best possible thing, as we’ll discuss a bit here, but used as intended, I think it is helpful to organizations and generally harmless to people. Used poorly, Scrum can be harmful to people, especially to the “Dev Team”, while still remaining helpful to the organization. That would be bad.

But first let’s talk about “agile” and “software development”. Clearly Scrum can be used in an agile fashion, and it can be, and usually is, used for software development. Why, then, do I say that it isn’t an agile software development framework, or a software development framework at all?

I prefer to use the term “Agile”, especially with a capital A, to refer to the Agile Manifesto, which sets forth various values and principles. Sometimes I leave off the capital, still meaning the same thing, and sometimes I might use the word “agile” to mean dancing about in a responsive and flexible fashion. Scrum is neither of those things.

Scrum can be used in an Agile and agile fashion. It can be used in accord with the values and principles of the Agile Manifesto, and it can be used in a responsive and flexible fashion. It can also be used with truly terrible values and principles, and without being flexible and responsive. That would be bad.

Scrum can be and often is used in software development. However, Scrum itself has no software-focused elements. No software principles or practices. Scrum is defined that way. I can see two reasons why it might be that way. First of all, Scrum is trying to be a general way to develop products, not simply a software method. That’s a perfectly good way to position a framework, and it’s the one that Jeff and Ken chose. Second, Scrum is trying to be minimal. It’s trying to be as simple as possible. As such it makes sense to leave out details, especially if they’re not as “universal” as the rest.

These are decent decisions that you could make when creating a framework: make it general, leave out as much as possible. It’s possible to disagree with that idea. It’s possible to think they left the wrong things in and put some wrong things out. That’s fine. You get to define your own framework if you want to, or try someone else’s framework on for size. It’s all good.

In my view, Scrum is a pretty decent place to start. More important, perhaps, is that it is almost certainly the most widely used framework today (other than unbranded ones like “chaotic”, “completely ****ed up”, and “wtf?”). Because Scrum is out there, it seems to me to be a good idea to understand it and know how to help people become effective inside Scrum.

There are, however, other views. There is a lot of Scrum bashing out there. There are two kinds of Scrum bashing, and one of them is good and the other not so good.

The good kind points out where people are doing Scrum poorly, with a result of being less effective, or, even worse, making people’s lives worse. This is unfortunately not uncommon and it should be called out and remedies offered.

The not so good kind of Scrum bashing occurs where people decide that something in it is bad. Favorites are “Sprints are bad”, and “Product Owners are bad”. In my view, some Sprints are bad, and the behavior of some Product Owners is bad. The ideas themselves are not optimal but they are decent and generally not harmful. Let me try to do near-justice to the objections and then try to dispose of them.

Sprints are bad

There seem to be two main related sub-gripes about Sprints. One is that work does not come neatly sized and therefore a Sprint cannot be properly filled with work, because it won’t add up quite right. The other is that bad people (maybe those bad Product Owners, maybe bad managers) will try to cram more work into the two weeks than can reasonably be done, and that will result in unhappy developers and inferior work. Therefore Sprints are bad and therefore Scrum is bad and therefore if you believe in Scrum you are probably also bad.

Yes, well. The packing issue is a red herring. Yes, it’s true that work doesn’t come neatly sized, and therefore there will probably be too much or too little to fit into a Sprint. Big deal. There’s also too much to fit into Wednesday – and it’s not the best idea ever to carry work overnight. Take on a little less work than you think the Sprint will support. It’ll be fine. There will be something to do come Friday. In fact, odds are you took on too much anyway. That’s OK, too. It’s a forecast, not a promise.

Oh, it is a promise? Then the problem isn’t the Sprint, it’s whoever made a forecast into a promise. The problem isn’t the Sprint, it’s the people.

As for too much work being loaded onto the team, that is in fact a bad idea. A team under pressure will take shortcuts, leading to defects and bad design. They will be unhappy, leading to less dedication to work, and ultimately to loss of good people. And it’s cruel. What causes that overload? Bad product owners, bad managers, bad leadership. The calendar does not cause the overload.

Now, it’s probably true that Scrum provides frequent opportunities for people to apply pressure. The Sprint is one and the daily standup is another. And sometimes those features are in fact abused to apply pressure. It is quite silly, however, to imagine that by removing those meetings we’d remove the pressure. Quite the contrary. Since the pressure is being applied by a person, not an event, that person will just find another way to apply the pressure.

The problem isn’t the Sprint, it’s the people.

Product Owners are bad

The main idea here is that the Product Owner role should not exist. Objections range from objecting to the word “owner”, which combined with “master”, apparently evokes memories of people’s days as slaves or something. Honestly, slavery is really evil, but there must be something more substantive in life than to worry about those words every time they turn up.

More substantial is the objection that the notion of Product Owner is too exclusive, and doesn’t suggest that the whole team should feel ownership of the problem and solution space in a nice cozy and cooperative collaboration. Yeah, well, I’ll buy that when everyone drives the speed limit and no one crosses a solid white line and everyone in the twelve items or less lane has twelve items or less. (By the way, that sign should say “fewer” not less.)

Now I prefer the term Product Champion, which I first heard from a Disney PO who clearly said “I don’t want to own the product, I want the team to own it.” And yes, that’s just right. That’s how you ought to do it. Well done. Carry on.

However, there’s nothing in the word, or the role, that stops you from working that way, and there’s plenty in the Scrum world of training and writing and coaching that will remind you to work that way. And if the company is going to have the wrong person “in charge” of the product, you’re going to have that problem.

The problem isn’t the Product Owner, it’s the people.

Scrum is OK, I guess.

I think Scrum is a perfectly reasonable place to begin on a journey to a more agile and Agile way of building products, including software products. It’s also a perfectly reasonable way to run a bake sale.

Are there better ways to do those things? Absolutely there are, but there are none that come in a box. You can roll your own if you’re up to it, but most people who’ve never done [A/a]gile are not up to it. You can pick another process off the rack, but all but one of them are just as bad or worse. Scrum is an OK way to start.

Then you have to make it work. Scrum’s fundamental principle is “Inspect and Adapt”. Every Sprint you plan an Increment of product, build the Increment, review the Increment with stakeholders to get their feedback, and review your performance with the whole team to see how to improve. What could go wrong?

There’s only one thing that could really go wrong: you could see something that wasn’t going well and fail to fix it. You could see that your people were getting overloaded in Sprints, and fail to fix it. You could see that your Product Owner was driving too hard and not collaborating enough, and fail to fix it. You could see that your code was getting crufty and fail to fix it. You could see that your defect count was rising and fail to fix it.

Your problem isn’t Scrum.

The problem isn’t that Scrum isn’t agile, though it isn’t. The problem might be that you’re not using it in an Agile fashion.

The problem isn’t that Scrum isn’t a software development framework, though it isn’t. The problem might be that you’re not using Agile Software Development values and principles, or agile software development techniques to build software inside Scrum.

The problem isn’t that Scrum has Sprints or weird names for its roles. The problem is that you’re not inspecting, adapting, and improving what’s going on.

You don’t have to start with Scrum if you don’t want to. (Well, someone might impose it on you. That, too, would be bad, but if they do you still have the right and responsibility to inspect, adapt, and improve. And again, that’s about the people, not about Scrum.)

Are there better ways to start? I’m not sure: I’d start most teams with something that looked a lot like Scrum, but I’d consider other starting points as well. Scrum, in my view, is not a bad place to start.

Are there better places to move toward? Absolutely! It’s better to produce a running tested shippable increment every day or every hour. Scrum doesn’t say you can’t do that. It’s better to be working so closely together that you don’t need a daily standup meeting. If so, drop it (and stop saying you’re doing Scrum). It’s better to have a Product Owner who shares problems with the team and lets the team go about solving them. So do that. Call them by another role name if you want to, it’s OK. You can even say “We’re doing Scrum and we call our Product Owner the Chief Knower of Problems.” It’s OK.

The point of Inspect and Adapt is to improve.

Suzuki Roshi said:

You are perfect as you are. And you could use a little improvement.

Your problem isn’t Scrum. Maybe it’s that you could use a little improvement.