Scrum is a Rigid Process ???
image from: medium.com/RandyHellerCT/5efb8551b89b

Scrum is a Rigid Process ???

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

Pete Morris, PMP, PMI-ACP

Agile Transformation Consultant

3 年

Excellent article. In Agile, just as in chess there are multiple decisions and compromises to be made. By the second chess move there are 72,084 possible games; by the 3rd move, 9 million, and by the 4th move, 318 billion. There are more possible games of chess than there are atoms in the universe. Similarly, the imposition of standard processes on Agile projects can lead to multiple responses and disastrous effects. Typically, when a company attempts to develop and implement a standard methodology, force common documentation archives or standardize post project reviews on an Agile project, the response is something like “Thank you very much, but we already got one, and it’s very nice.” ??

Viju Padmanabhan

Delivery Enablement | Technical Program Manager ( ICP-ACC | ICP-ATF | ICP-CAT l Scrum@Scale Practitioner | A-CSM | CSP-SM | CSP-PO I SPC )

4 年

Very nice writeup Tobias. Thanks for sharing

Sanjay Tiwari, CSM?, CSP?, SAFe? Agilist, ICP-ACC

Sr. IT Program Manager | Scrum Expert | Agile Leader | Java,JEE,.Net | Global Delivery | Finance | Healthcare| Insurance | Driving Organizational Transformation, Empowering Teams, Delivering Results

4 年

Great Article Tobias Mayer . Such a great explanation of scrum in a very simple language. The example of an interface or abstract class is awesome

Dave Witkin

I implement agility that delivers measurable results. Registered Scrum Trainer? (RST), Registered Scrum@Scale Trainer? (RS@ST), Registered Value Stream Management Trainer?

4 年

Outstanding, Tobias Mayer. I’ve seen way too much time spent debating individual words and sentences in the Scrum guide. Enough. Don’t lose sight of the core values and principles underlying Scrum! I’ve heard someone say that values and principles are critical. Maybe someone debating specifics can remind me where I might have heard that...

要查看或添加评论,请登录

Tobias Mayer的更多文章

  • Artificial Stupidity

    Artificial Stupidity

    "There are all sorts of temptations in this world that will eat away at your creative spirit, but none more fiendish…

  • No such thing as "Waterfall"

    No such thing as "Waterfall"

    Back in 1970 a man named Winston W. Royce published a paper with IEEE entitled, "Managing the Development of Large…

    27 条评论
  • Living the Scrum Values

    Living the Scrum Values

    How should we live the scrum values? Here's one way: by examining how we are not living them. At the end of each day…

    30 条评论
  • Staying sane in 2021

    Staying sane in 2021

    An ancient picture of childbirth. Not a typical LinkedIn topic, and not really the topic of this post, rather a…

    10 条评论
  • My Wasted Life

    My Wasted Life

    Note: This is a copy of a newsletter I sent out two years ago to a small subscription list. It occurred to me it has a…

    16 条评论
  • Is the Scrum Master a Code Coach? ???

    Is the Scrum Master a Code Coach? ???

    A New Pair of Glasses. In this series I challenge some of the misinformed and myopic statements I've heard people make…

    26 条评论
  • Virtual Scrum? Well, Maybe

    Virtual Scrum? Well, Maybe

    This article is an update to Virtual Scrum? No Thanks written three months ago. After five months of lockdown, physical…

    15 条评论
  • Scrum and WIP limits ???

    Scrum and WIP limits ???

    A New Pair of Glasses. In this series I challenge some of the misinformed and myopic statements I've heard people make…

    95 条评论
  • Virtual Scrum? No Thanks

    Virtual Scrum? No Thanks

    Five years ago I wrote an essay on training that began, "I am not a trainer. Training is for circus animals, pet dogs…

    108 条评论
  • Small Things

    Small Things

    A personal reflection..

社区洞察

其他会员也浏览了