Scrum is an abstract class

Teams provide the implementation

Published in

Serious Scrum

5 min readSep 14, 2018

In Java, an abstract class cannot be instantiated, which means it can never really exist in a pure form. However, it can be brought into existence if it is extended — and therefore used — by a concrete implementation.

In other words, if you like the behaviour described in the abstract class, you can extend it, and create your own custom version. However, there is a contract or an agreement implied here. Using an abstract class means you agree to inherit and adapt those behaviours. After extending the abstract class, your sub-class is an instance of it.

An abstract class includes methods, which always have signatures. A method signature means a couple things. First, it names the method. Also, it fixes the expected inputs and outputs. These two expectations set the entry and exit points, but you get to write the body of the method. In other words, you’re free to decide how it works for you.

Imagine, for a moment, that Scrum is an abstract class. It could have a method called sprintPlanning, that takes the Sprint Goal as an input, and returns a Sprint Backlog as an output. The method signature is quite well defined, but how the team implements Sprint Planning is entirely up to them.

Is this how you would write scrum as an abstract class?

Removing roles, events or artifacts means it is no longer scrum

Scrum defines a set of method signatures which need to be fleshed out. Even if all of the events, roles and artifacts are tailored or adapted by an implementation of scrum, the result is still scrum. It is only by removal or omission of these methods that we breaks the contract of the abstract class. When that happens, we are now implementing something else.

“although implementing only parts of Scrum is possible, the result is not Scrum” (The Scrum Guide)

Imagine, a team that has decided to stop doing retrospectives. Unfortunately, this means that you have moved away from the minimum requirements of scrum. To be a scrum implementation, implementing retrospectives is necessary. However, how you do retrospectives is entirely up to you and your scrum team.

You will definitely need to add methods to scrum

One other cool thing about implementing an abstract class is that you are completely free to add methods. Indeed, when you implement scrum, you’ll quickly find that this is essential. Some important methods are completely absent.

The scrum guide was never intended to be prescriptive or a checklist for a software development team. Many important practices are not covered in the scrum guide! Gasp! We actually have to go and figure some of this out for ourselves…

It is interesting to note here, however, that this omission is entirely by design.

Scrum “functions well as a container for other techniques, methodologies, and practices.” (The Scrum Guide)

Engineering Practices must be added

For example, engineering practices were explicitly left out of the scrum guide by Ken Schwaber and Jeff Sutherland. Just let that sentence settle for a moment. The framework that is used by thousands of agile teams to deliver software does not include any guidelines on how to build software.

If we use the metaphor of scrum as an abstract class, think of engineering practices as methods that you must define and implement yourself.

“I learned from Jeff Sutherland that the first Scrum actually did all the XP practices. But Ken Schwaber convinced him to leave the engineering practices out of Scrum, to keep the model simple and let the teams take responsibility for the tech practices themselves” (Henrik Kniberg, Scrum and XP From The Trenches)

For an implementation in software development teams, there are many other examples of methods you’ll need to add. These might include the roles that exist in your organisation, and how they fit into scrum teams. You might want to think about stakeholder mapping, value stream mapping, metrics, release planning, continuous integration and continuous deployment… the list goes on!

The Definition of Scrum

However, don’t lose heart! Scrum can actually help with this. Let’s go back to first principles for a moment, and the definition of scrum:

Scrum is “a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value” (The Scrum Guide)

Scrum is designed to facilitate learning and adaptation. Remember how the agile manifesto is all about ‘uncovering better ways’ of working to deliver software? Scrum gets that.

Scrum is about empiricism: transparency, inspection and adaptation. These are essential to uncover better ways of doing things, and for new, helpful practices to emerge within the team. The Scrum framework facilitates this, but the entire team needs to have responsibility for making it happen.

Experimentation is essential so that the best, most helpful practices can emerge and be added to the abstract framework. Courage is required for this. The team also needs to keep focus on delivering value while improving. This is challenging! Commitment and trust are essential, and the team needs to be open to the challenge.

To recap, Scrum is designed like an abstract class, but also as a framework for helping you to define your custom implementation. The contract implied by using it means that you agree to implement certain roles, artifacts and events. However, supplementing the roles, artifacts and events with your team’s emergent practices will help your team to succeed with delivery of valuable products, and the processes of empiricism and values will help you on that journey.

It might feel like abstract art at times, but Scrum was designed this way.

Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.

My twitter profile is https://twitter.com/paddycorry