There really is a “definition of Scrum”. It is called the Scrum Guide. There is another description of Scrum, according to the Scrum Alliance, in the AgileAtlas.org “core” page. These are not two competing definitions: the Atlas page is intended to be consistent with the Guide, speaking in its own words.
There are many other, larger descriptions of Scrum in the books by its creators and other people who study and practice Scrum. Here’s another description, by way of considering something else, what actually happens:
Scrum is a “framework” for building products. It is quite simple, as we’ll see here.
Inspect and Adapt
Scrum relies on a single principle: “Inspect and Adapt”. The framework is designed to provide ample opportunity for the people building the product to see what is going on. Scrum demands that when they observe things not going well, they improve what they do to make things go better.
Scrum demands that the team produce a new increment for the product every couple of weeks, in intervals called “Sprints”. This increment may not be feature complete, but every feature in it must be in good enough condition to ship to end users.
Definition of Done
The meaning of “in good enough condition” is called “Definition of Done”. This is an agreed set of criteria across the whole team. The Definition of Done includes all the criteria needed to make the product shippable from the viewpoint of quality. All aspects of “quality” are intended to be included in this definition.
The Definition of Done will evolve over the course of the project, as the team learns. Early definitions will be simple and easy; later ones will be more stringent. In all cases, the entire product increment must meet the Definition.
Retrospectives: Inspect and Adapt
After every two-week “Sprint” ends with a retrospective, in which the team inspects what has happened and adapts by figuring out ways to improve.
Not just good ideas
The Product Increment, the Definition of Done, and the Retrospective are not just good ideas. Scrum demands that you actually do them. If you are not producing Product Increments, if they do not meet increasingly difficult Definitions of Done, if they are not good enough to ship to users, or you are not examining what’s going on and improving it, you’re just not really doing Scrum, at least not yet.
Role: Product Owner
Scrum specifies that there must be a single individual, called the Product Owner, who is responsible for maximizing the return on investment of the project. The Product Owner does this by choosing the next items of work (called Backlog Items) to be done. By choosing these in the order of highest value, the Product Owner can ensure that at any moment in time, the product’s value is as high as it can possibly be, given the team’s pace of work.
If you don’t have a Product Owner with the authority to decide what to do next, you’re just not doing Scrum. If your Product Owner is making poor decisions, you’re just not doing very well. Inspect and adapt.
Role: Development Team
Scrum specifies that the team must include people with every skill necessary to creating the Product Increment. The Dev Team has the responsibility to forecast how much work they can do in the next Sprint, and to produce a Product Increment, meeting the current Definition of Done, containing as much of that work as they are actually able to accomplish. Note that, like any forecast, the forecast might not come true. The team produces an increment in any case, perhaps containing less than was initially forecast, or even containing more.
The Development Team is not responsible for going as fast as people randomly want. They are responsible for producing a Product Increment meeting the Definition of Done. They are responsible for maintaining the quality of that Increment, and for going as fast as they reasonably can while maintaining quality and a sustainable pace.
Scrum adds a special role called the ScrumMaster. This name is perhaps unfortunate, because the ScrumMaster has no authority over anyone: he is not their “master”. The ScrumMaster is a coaching role, with the responsibility to help the team stick to their agreed process, to ensure that everyone understands Scrum, and to see to it that any identified impediments to progress do get resolved.
The ScrumMaster does this job by applying leadership, not by applying force.
You have a Product Owner who has sole responsibility for delivering the best possible result that the team can produce. You have a Development Team who have all the skills necessary to product Product Increments. And you have a servant leader who helps you to keep on track, to understand what you’re doing, and to remove the things that are in your way.
If you don’t have these roles, or their responsibilities aren’t aligned this way, then you’re not doing Scrum.
Meetings and Activities
Scrum specifies some meetings and activities: Backlog grooming, which keeps the list of things to be done fresh, clean, and prioritized; Sprint Planning, which selects the work to be done in each Sprint; Daily Scrum, where the team coordinates each day’s work; Sprint Review, which displays the Product Increment to all stakeholders and collects their feedback; Sprint Retrospective, where the team reviews the past and improves for the future.
That's all there is
You might be doing something really good. You might be doing something really bad. But if you’re not doing these things, with these roles and these activities, then what you’re doing really shouldn’t be called Scrum.
It’s like playing a game with sticks, hitting baby chicks over the fence. It might be a hell of a lot of fun but it isn’t baseball.
(Sorry about that.)
What People Do
There are an infinity of things that people do that look somewhat like Scrum, and unfortunately people even call them Scrum. Here are a few deviations just to give the flavor:
No Real Product Owner
Often a team has no real business-side connection, no one really in charge of maximizing product value by choosing the work to be done. Instead, they’re just ticking through some list of everything they need to do. Usually it’s a list that no one understands.
This isn’t Scrum. It’s not even a very fun game, and it’s not likely to result in anything good.
No Decent Product Increment
Often a team doesn’t produce real software at the end of every Sprint, or that software doesn’t look like a product, or it isn’t of good enough quality to kick to the curb, much less give it to actual users.
This isn’t Scrum. It might result in something good, but since you can’t see what’s going on, how can you be sure?
ScrumMaster Held Responsible
Sometimes companies are used to having Project Managers who are held responsible for getting the product out, and they just assign those people to be ScrumMasters, still responsible for getting the product out.
This isn’t Scrum. It might get you a product that someone wants (although history suggests otherwise), but it’s not consistent with Scrum, so you should call it something else.
Dev Team Held Responsible
Sometimes companies just continue to pile work on the developers and demand that they deliver a good product on time.
This isn’t Scrum. It isn’t even sensible. To get business value, you need business people guiding things.
I could go on ...
There are as many different ways to do products as you might want. Some of them are Scrum. They’re the ones that work within the simple framework described above. The ones that do not match that framework might be really great ideas. They might be really effective.
But they are not Scrum.
Why does this matter?
This matters for at least these reasons:
- If people are doing just what Scrum says, and it isn't working, maybe there's something wrong with the Scrum central ideas.
- If people have used the official definition and training, and aren't doing what Scrum says, but think they are, then maybe there's something wrong with the words in the description or the training.
- If people have not used the official definition or training, and aren't doing what Scrum says, but think they are, then maybe we need to better publicize the real ideas.
- If people know they're not doing what Scrum says, but they continue to say they are ... well, I have no idea what's up.
Bottom line, whether you’re into critiquing a general method, or into helping a specific team, it’s important to understand what they say they’re doing, what they’re really doing, and where they learned it.
And, whatever they’re doing, if they’re not inspecting and adapting, continually improving, I don’t hold out much hope for them.