Scrum Notes 2013-20

A New Pair of Glasses In this series I challenge some of the misinformed and myopic statements I've heard people make about Scrum over the years, with the intent of clearing away much of the nonsense, confusion and even antagonism that surrounds this very simple, elegant and effective method of working.

Blindspot #2: Scrum is a rigid process

The things people say...

"My struggle is talking about emergent processes and Scrum together since Scrum is designed to give an immutable set of minimum meetings, roles and artefacts."

"The Scrum Guide's insistence on implementing all parts of Scrum means there is no room for innovation or adaptation."

"Scrum cannot be considered an Agile process as it is fixed and immutable. That's the opposite of agility."

And so on.

The Scrum Guide describes the Scrum framework. The Scrum framework is structured on the three pillars of empiricism: transparency, inspection and adaptation. It consists of five events, three artefact, three roles and five values. The end note of the Scrum Guide states:

Scrum's roles, events, artefacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

People take this to mean that Scrum is a rigid process—overlooking the fact that Scrum is actually not a process at all. Scrum is a process abstraction, a Platonic ideal. In programming terms Scrum is an abstract class or an interface. It describes What, it doesn't indicate How. In object oriented programming concrete instances are created from abstract classes. The abstract class provides structure, the concrete class the implementation. An abstract class is immutable. You must implement all methods of the abstract class or your concrete class will not compile, will not work. This is not rigidity, this is meaningful structure, intelligent constraint.

An abstract house would describe walls (more than two) a roof, windows (one or more) and a door (at least one). You could build an actual house without windows, without a roof, or without a door, but the structure you made could hardly be called "house", and few would chose to live in such a structure.

You can make a meal out of tomato paste, melted cheese, pepperoni, mushrooms and other meats and vegetables, but unless these ingredients sit on a base of baked dough you're not making Pizza. And you'll likely create quite a mess! Structure has an important role to play. It does not bind us, but rather frees our creativity. Creative people know this.

"The enemy of art is the absence of limitations." — Orson Welles

"Design depends largely on constraints." — Charles Eames

"Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage." — 37 Signals

I'd argue that the elements of Scrum documented in the Scrum Guide—with a single, important exception—are the minimal set required for an effective creative process. It may help to illustrate this through a personal experience.

I moved into a new home eighteen months ago. The garden was a mess, some combination of junk heap and jungle. I had some ideas of improvement. I chatted about my ideas with my wife and children. They added their own ideas. I engaged a local gardening company, just two guys, Michael and Barry. They came over. We went through the list of improvements. They made suggestions based on their experience, offered additional ideas, and made recommendations as to logical ordering of the work, taking my own prioritisation requirements into consideration. They put together a rough time and cost quote, which we agreed to revisit periodically as things changed. We agreed a start date.

Michael and Barry started the work. Each day they decided what they'd work on, always completing one job before moving onto the next job, and getting either me or my wife to review each completed job. During the day they would take breaks and chat to one another about implementation decisions, and offer support as necessary. When they had questions about the next job, or better ideas, or if they ran into problems that might mean increased cost or alternative strategy they would invite us to a design/replanning meeting. We'd explore the alternatives and make a decision. Thus the work progressed with regular reviews, approvals, slight changes of plan and finally a garden that was both attractive and usable. And not perfect.

I doubt Michael or Barry had ever heard of Scrum, but let's analyse the process that occurred, and map it to the elements of Scrum. I was the product owner (my wife and children stakeholders). Michael and Barry were the development team. My list of ideas, hopes and requests was a product backlog, the 'product' being a usable and safe garden. Each conversation Michael and Barry had with me or my wife was a planning meeting. Each conversation they had with each other was a daily scrum. Each invitation to review a finished job was a review meeting. I imagine (I don't know for sure) that Michael and Barry would reflect at the end of each day how well they had worked and what they could do differently next time. It is this way that all craftspeople improve their skills and abilities.

The process was an empirical one. We didn't know exactly what the garden would look like at the end. We had a vision, but we were constrained by both time and cost, so had to to give on scope, and continually assess need against want, for example prioritising safety over beauty. Together we inspected and adapted our way towards the vision, altering the vision accordingly as we journeyed. Each completed job represented a product increment, a usable feature.

The values of focus and commitment were apparent in the work carried out. The values of openness and respect were apparent in our dialogs. Courage was less present (and less necessary) than it might be in some other situations because respect and trust were strong.

For those who think Scrum is too rigid, I wonder what you'd take away from the garden improvement process described here. I rather feel that if anything was removed we'd have ended up with a sub-optimal process, which would likely have increased the cost and/or time, and possibly resulted in a less satisfactory garden. It is worth pointing out that we didn't begin by saying we must follow these values, do these five events, or have these two roles in place. These things occurred quite naturally.

You'll notice I said two roles, and not three. This brings us to the one exception, the one element described in the Scrum Guide that is not essential in all creative processes: the scrum master. The scrum master role is a workaround for dysfunctional organisations. And let's face it, almost all IT organisations are dysfunctional. This is why they turn to Scrum or other Agile ideas in the first place: their traditional way of doing things is failing them.

The scrum master holds it all together, until such time as the structure is strong and self-sustaining. Once a house is built the builders go away, returning only if a problem occurs, and then just temporarily. When an apprentice has learned his trade, the master goes away and the apprentice continues to learn and improve in the context of the work itself.

In its early days a new Scrum implementation needs a scrum master. If the scrum master does their job well, they can quietly go away and few will notice. The structure will stand, and the process—developed in context and constrained by the Scrum boundaries—will continue to evolve and improve.

Far from restricting a team's process, and binding it to some kind of dogma, the constraints of Scrum hold the process strong and allow it to grow, and adapt as appropriate.

—

Related reading: 1) The Silence of Scrum, 2) The Pavlova Guide