(2021-07-20) Jeffries Scrum Is Not An Agile Software Development Framework

Ron Jeffries: Scrum is not an Agile Software Development Framework. Scrum is not a software development framework at all.

Many Scrum experts say that Scrum is a product development framework.

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

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.

Scrum itself has no software-focused elements

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.

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.

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

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.

What causes that overload? Bad product owners, bad managers, bad leadership

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.

Product Owners are bad

The main idea here is that the Product Owner role should not exist.

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.

Now I prefer the term Product Champion

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.

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

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”.

There’s only one thing that could really go wrong: you could see something that wasn’t going well and fail to fix it.

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.

The point of Inspect and Adapt is to improve.