[Comments on this post on LinkedIn]

Let’s look at Scrum through the lens of last week’s inverse square law of framework scaling, its power as a framework being the product of:

1. The incisiveness of its point of view – its core paradigms, principles, values, and so on
2. The ease with which its key patterns combine – both with each other and with those from outside the framework

Being small, Scrum should do well on both counts; I’ll take them in reverse before returning to how it scales.

The ease with which its key patterns combine

Scrum scores really well here.

Look at Scrum merely as composition of smaller patterns (dangerous, but bear with me just for a moment) and you have to give it significant credit for normalising the practices of daily standup meetings, small-scale planning meetings, retrospectives and so on. Not for everyone an unalloyed good (“too many meetings” is an easy complaint to make if for whatever reason it’s not working), but certainly a mark of Scrum’s success.

And it gets better: Scrum as a whole is small enough that it combines easily with other things. Scrum+XP has been a thing for a long time. I’ve worked with Scrum and Lean Startup in combination (in the government sector, no less). Scrum+Kanban (Scrumban) isn’t just one thing, but several; in Right to Left I describe four common combinations and elsewhere I have counted more (it’s not hard: just consider the different ways in which their respective scopes might or might not overlap).

The incisiveness of its point of view

Here’s where it gets awkward. Scrum isn’t one thing, but two:

1. Left-to-Right Scrum: the team working its way through a backlog that is determined for it, mostly in advance
2. Right-to-Left Scrum: the team iterating goal by goal in the direction of its overall objectives

Left-to-Right Scrum is a process that’s mediocre (or worse) to experience, and doomed to deliver mediocre results at best. And it’s easy to see how it happens:

• Little room in the project for learning about the customer’s real needs or for exploring different ways of meeting them
• Thinking that the job of Sprint planning is to fill the Sprint to the maximum, a misconception amplified by story points and velocity (the problem not being that they’re nonsense metrics that cause otherwise intelligent people to bestow mystical properties on Fibonacci numbers, but that they reinforce a dysfunction)
• Reviews not of what’s being learned about the team’s customers, its product, and the team itself, but of progress against the plan
• Retrospectives that lack the authority to address strategic issues, and that fail to follow through even on the issues over which it does have influence

I’m convinced that Scrum would be considerably less prone to these failure modes if only it would maintain a clearer point of view. Scrum’s tragedy is that it’s presented as a backlog-driven process so often that its core paradigm as an iterative, outcome-oriented process gets lost in the noise. And from that failure, disengagement. All that hating on Agile? You don’t need to look far for causes.

Scaling it up

For the most part, disappointingly predictable and predictably disappointing:

• Take Scrum and layer on hierarchies of organisation structure &/or work breakdown structure
• Plug it into a project/programme structure that almost inevitably works in left-to-right terms and is given no reason to think otherwise
• Compounding it all, the rollout project – failure after failure, but still we do it!

Again, the tragedy is that it doesn’t have to be that way. Instead of layering on so much process that you disconnect teams from strategy and organisation development, invite them in! Instead of losing faith with self-organisation, invest in it! Instead of solution-driven imposition, outcome-oriented engagement! Honestly, it’s not that hard.

We’re in the business of building wholehearted organisations. Need help reorienting your Scrum implementation so that it can work as it’s meant to? Want to put authentic engagement at the heart of your transformation? Get in touch – we’d love to help!

Further reading:

• The middle two chapters of Right to Left: The digital leader’s guide to Lean and Agile (print and ebook 2019, audiobook 2020) – the framework chapters of a singularly outcome-oriented take on the Lean-Agile landscape
• ‘Right to Left’ works for Scrum too (July 2018)
• How I read the Scrum Guide (November 2017)
• What I really think about SAFe (October 2019)
• Too harsh? – change management vs engagement model (linkedin.com)
• Outcome-oriented  (linkedin.com)
• About Agendashift™ (agendashift.com)

My thanks to Teddy Zetterlund and Steve Williams for feedback on this post, and to Agendashift’s Friday #community Zoom group (details in Slack) for the conversations that preceded it.

---

What if we put agreement on outcomes ahead of solutions?

Agendashift™: Serving the transforming organisation
Agendashift  Academy: Leading with Outcomes | Home | Store
Links: Home | Subscribe | Become an Agendashift partner | Events | Contact | Mike
Resources: Tools & Materials | Media | Books | Assessments
Blog: Monthly roundups | Classic posts
Community: Slack | LinkedIn group | Twitter

Community: Slack | LinkedIn group | Twitter