Scrum has given us a lot, but it’s time for some conscious uncoupling

“The age of men is over.”

confidently (and rather aggressively, as you would expect from one of those nasty orcs) declares the Orc commander Gothmog in Peter Jackson’s Lord of the Rings: The Return of the King

“The Time of the Orc has come.”

There’s an irony, of course in using this quote for a blog post declaring Scrum’s ultimate decline into irrelevance. In fact the age of men (and woman as the insensitive Orc fails to include) was in fact only just beginning. It was actually the age of the Orc that was over!

On the subject of Scrum, time will tell of course. One of my favorite true-isms. Perhaps Scrum, the ubiquitous agile framework is in fact only just entering its heyday. Perhaps in so boldly declaring that the days of Scrum are starting to come to a close, it may in fact be that the days of my career that are limited :-O

I’m calling it

I can’t predict the future, sadly. But sometimes the time comes to be a bit bold and put something out there — and let history be the judge.

Within 5 years Scrum will be largely irrelevant as an influence in modern software companies

— Chris Lennon (author) July 2021

Note that I say ‘software companies’ — Scrum now positions itself well beyond software, and I predict it will have a good run in that space. But agile is rooted in software — lets not forget the founding document is the ‘Manifesto for Software Development’. Software currently leads the way in innovative ways of working, and Scrum’s coming fall from grace there will be the start of the rot for Scrum.

Bitter, much?

I will be open— there is some emotion to this article — it distresses me to think of all the good, talented men and women currently “under the Scrum”. Dutifully filing into offices around the globe to play “planning poker”, debate how to compose a “Sprint Goal” that isn’t “finish all the stories” and in some cases, have their every hour of work “burned down”.

In a way none of this nonsense is Scrum’s fault; as a framework it is in its own words “purposefully incomplete”. However these practices have become so infused into Scrum that it has now become too hard to separate the superstition from the framework.

Scrum == Agile?

Picture a ship who’s hull has become so encrusted with barnacles that the hull is rotten and the barnacles are all that are holding the vessel afloat. To remove the barnacles would be to scupper the ship. So it is with Scrum, it is now hopelessly weighed down by its own baggage.

In a recent blog post Ron Jeffries, a signatory of the agile manifesto, asks “Can Scrum be fixed?” My answer is “no”. In a way Scrum has become a victim of its own success. Teams all over the world associate Scrum with agile. Indeed at the recent launch event of the 2020 Scrum Guide Jeff Sutherland, co-creator of Scrum made the statement that “Agile is pretty much Scrum now”. Only by distancing (or ‘consciously uncoupling’ to use the term popularized by Gwyneth Paltrow) ourselves from Scrum and its legion of “certified professionals” can we give coaches and teams the breathing space to get back to the heart of agile — “uncovering better ways of developing software by doing it” as the manifesto has it.

Rituals, Ceremonies, Events — oh my!

Where Scrum is most visible is in its meetings. Sometimes called rituals or ceremonies, the current Scrum Guide calls these ‘events’. Words are interesting — the oxford online dictionary defines a ‘ritual’ as:

a religious or solemn ceremony consisting of a series of actions performed according to a prescribed order.

Stripped of their original purpose, this is what so many Scrum events have become: a series of actions performed by rote. Lets take for example the Planning meeting — as many corporate citizens will know — a time to get out the planning poker cards and gaze vacantly at the backlog in Jira. The Scrum Master often presides over this ceremony, stories are allocated points, Jira is updated, some conversations are held (these are often quite circular due to the team lacking the necessary context) and any attempt to deviate from the invisible run sheet is strongly discouraged — by the Scrum Master and often the team themselves. ‘Event’ is a better name than ritual or ceremony, but lets not forget that most events (think “Sporting Event”) are spectator sports.

Leaving the name aside its this ‘join the dots’, almost mechanical approach to the various Scrum meetings has now become infused into Scrum.

Scrum is just not broad enough to keep up

Anyone working in the software industry will be aware of two significant and complimentary global trends:

Trend One – the shift to empowered teams that own a business or product domain. Although many feature factories still churn out software, the companies that are able to shift key parts of the product decision making process into the teams producing the software are gaining an edge. Marty Cagen writes about this difference in his classic blog product teams vs feature teams

Trend Two – DevOps. In addition to working in the left hand side of the software lifecycle, teams are also now beginning to operate the software that resides within their sphere.

The Scrum guide is extremely light on the left hand side — the addition of a ‘Product Goal’ in the 2020 guide was a welcome addition — but the fact remains that the Scrum Guide has almost nothing to say regarding discovery and design. On the other end of the Software Development Lifecycle, Scrum similarly has almost nothing to say on the complex and vital operational aspect of software, seemingly leaving the actual running of the products built using Scrum to other frameworks or movements such as DevOps.

A container

“Wait, hang on” I hear you say. Scrum is an open framework — surely we can add to it or change it as we want to achieve our goals? Well lets not forget the line in the guide: “Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices”.

A container is something you put things into. Scrum is clearly designed to be the super-set of processes. And as a super-set it is simply not equipped to keep up with these global trends.

Walking the tightrope

Of course the Scrum guide may change. Peering into my crystal ball I wouldn’t be surprised if empowered product teams and DevOps make an appearance in some form in the next version of the Scrum guide. And the 2020 guide is a lot less prescriptive and more open than the previous guide. Perhaps even the famous immutability line “The Scrum framework, as outlined herein, is immutable” may disappear or change.

However there’s a danger to Scrum in being “too open” — a big part of Scrum’s appeal is that it does the hard work for you. No need to do the ways of working research, delve deeply into Lean or tailor make processes for every individual team — simply follow this handy one size fits all guide. You cannot be both very open and very prescriptive. Scrum is currently walking this tightrope — but its a tightrope that cannot be walked along forever.

Life in between the guides

Also — consider the fact that the Scrum guide has been periodically updated since its first publication in 2010. When the next version will be published is anyone’s guess, but history points towards the fact that there will be a new guide and it may be substantially different to the current guide. Practices a Scrum Master is now doing as part of being a “good Scrum Master”, may disappear entirely from the next guide, or even become frowned upon.

Lets take for example the “three questions” of the Daily Scrum (often called a “stand up”) — what did you do yesterday?, what are you planning to do today?, and what is blocking you? Asking and answering these questions was once a mandatory part of Scrum whereas these questions are now totally absent from the current guide — which says of this meeting:

“The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work”

— 2020 Scrum Guide

Today’s Scrum best practice can overnight, with the publication of a new guide become tomorrow’s overly rigid process. My question is: which Scrum practices are you and your team following as best practice that will become outmoded with the release of the next Scrum guide? Two or three years is far too long to wait for innovation to drop in your lap — teams must be free to change practices to suit the evolving needs of the team and the business.

How then should we proceed?

It’s easier to explain price once than to apologize for quality forever.

Designing fit-for-purpose team processes takes more focus, thought and, initially, time than simply implementing a one size fits all framework. Ask yourself though, as part of a team would you rather your team worked together, possibly with the help of a coach, to design the right processes for the team and project at hand? Or do you want to follow the same framework everyone else uses? Or at a higher level, which approach will give your company an edge?

There are a rich set of bodies of knowledge to which a team can refer to help them design their own processes. I have blogged about many of them: project management, agile, design thinking, lean, management theory, systems thinking and DevOps

What do we call it?

32. don’t call it anything. If it has a name, people, including you, will waste time arguing what it is and isn’t.
33. call it something. Otherwise nobody can ever talk about it

So we are deliberately uncoupling the way we work from the Scrum bandwagon. We may be working in an iterative way, or taking a more flow based approach. We base team processes on observation and collaboration rather than a document. We have an improvement process that goes beyond regular retrospectives. And we improve our improvement processes too. One problem remains … “what do we call this thing?” We can’t call it Scrum because its, of course, not Scrum. We could call it ‘agile’ but that word has come to mean Scrum in many ways, and carries a reasonable weight of baggage.

I have been using the term “purpose built” to describe this responsive, fit-for-purpose way of working rooted in proven bodies of knowledge like lean and systems thinking. “Custom built” is another possible term, but to me it sounds a little more fragile than “purpose built”. The reality is that you can call it whatever you like. Call it “Mega Tech Super-Duper Ways of Working” (but not if your company is not Mega Tech of course).

Thank you Scrum

Thank you Scrum. You have given me a lot and made an incredible contribution to the agile community. In fact my first full time job in agile was as a Scrum Master. To be honest I never quite worked out what my job actually was— it seemed to involve facilitating “events” mainly. With some confusing conversations with teams when I suggested we try something different to what Scrum was in the teams’ mind.

I see my future now in helping teams build fit for purpose ways of working that enable them to be the best they can be as a team. But who knows what my future will bring.

Time will tell.

Update June 2022

After a lot of thought and trial and error, I’m happy to say that I and some others have developed a lightweight, flexible, flow-based, template alternative to Scrum and Kanban

Check out Agile Kata