(De-)Scaling with Scrum

So you’re supersizing your company or are looking for ways to supersize Scrum to your supersize company. I have a perfect approach in mind for you. A small question first though: feel like some vanilla ice cream?

Now before you jump on the Scaling Scrum bandwagons of Nexus, LeSS, Scrum@Scale or before you buy yourself an Agile Release Train ticket to frankenstein it all the way up to SAFe, I beg you to consider the following.

Battling complexity

Scrum is small and lightweight, so how can it be fit for enterprise?!

Scrum is designed to battle complexity and works well for organizations that operate mainly within the complex (or even chaotic) domain of the Cynefin Framework by Dave Snowden.

“As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily.” — Uses of Scrum, the Scrum Guide

Ergo, Scrum in itself is already is the proven answer to how to deal with markets and environments that “have rapidly increased”.

One of Scrum’s most successful strategies for resolving complexity is by remaining simple and lightweight itself.

Another strategy of Scrum is revealed through its routine: consistency.

Methodologists generally have a habit of battling complexity by well… adding even more complexity. Just watch the overhead grow until it’s all way over their heads. Oh sure, they abandon stuff too…mainly those very practices which were hard, but should have made them great over time. In their habit to try and control complexity, they fail as all these controlling policies and processes make the organization rigid whilst they are meant to thrive in dynamic environments. Now, turning rigid, rather than thrive, they have to try and survive.

Resolving dependency

The main reason put forth as to why to scale Scrum is to manage inter-team communication and dependency. Thus, each and every single scaling approach to Scrum introduces roles, teams, committees and whatnot. These can be organized in various ways in Nexus (integration) Teams, Product Owner Teams (LeSS Huge), Scrum of Scrums, and even (I wish I was kidding) Scrum of Scrum of Scrums (Scrum@Scale).

This too inadvertently calls for aligning these committees to Scrum’s events which generally end up wrapping themselves around them.

But how do Scrum Teams manage their inter-team dependencies? Well, the answer is (not surprisingly) simple: by organizing teams cross-functionally and empowering them to self-organize. This enables them to resolve complexities and dependencies. Now though that principle is indeed a simple one, the practice is difficult. A good place to start is to refine work (slice the cake into consumable sizes) so it can be completed in a Sprint where the dependencies that remain are limited to what a team can self-manage.

‘But what do we do with all this middle-management overhead and self-important higher-ups?!’. SAFe grants them all fancy titles and puts up a facade of new Agile ‘lipstick on a pig’ terminology. Well with ‘vanilla’ Scrum, organizational management would not be excluded from participating in Scrum Teams. They don’t just cease to exist, do they? Their competencies don’t just vanish either. Their ‘product’, is the organization, which to is a complex entity that emerges and requires an incremental approach to its development. In math, a product is ‘a quantity obtained by multiplying quantities together’. Scrum Teams resolve their dependencies with other Scrum Teams inter-aligning Sprint Goals. No need for any new fancy terminology. What’s more, they’re now super-supported by all this transparency and super-involved servant leadership. It’ll be like walking out of Plato’s Cave to them.

Cookie Jar

One of the challenges Scaled Scrum Frameworks try to solve is the ‘too many hands in one cookie jar’ problem.

It’s about many teams working on a single product. Many teams need to forecast (select Product Backlog items for a Sprint) from a single Product Backlog. So what, one might wonder, could possibly guide the teams in forecasting these items? What could provide this guidance to the Development Teams so they don’t all grab the same cookie at once?

“The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.” — The Scrum Guide (emphasis added)

Some Product Backlog Items could indeed relate to multiple objectives. It’s not rocket science to make transparent which team is selecting which items into its forecast and align on those that share dependencies. As these dependencies become transparent they can be resolved. These Scrum organizations will learn to value the INVEST criteria when it comes to defining and refining Product Backlog Items where the “I” stands for “Independent”.

The Product Cloner

Another challenge that is introduced when many teams work on a single product is that it would become hard for the Product Owner, being part of all those Scrum Teams, to attend the events that require their presence (Sprint Planning, Sprint Review, and the Sprint Retrospective). Surely, the Product Owner cannot clone him or herself to attend all these events at the same time.

Though the Scrum Guide does describe the purpose of the events and what would fulfill its purpose, it doesn’t prescribe how the events are to take place. A Sprint Planning or Sprint Review indeed could be run ‘bazaarmode’ as LeSS does. Also, the Scrum Guide doesn’t prescribe that all members have to sit out the event’s entire time-box. What’s more, a Development Team might contain members who support the Product Owner. Those would be diligent inspectors and value-oriented specialists (UX-Designers for example) that assist and guide the Product Owner. Although this is hard to manage, the alternative of introducing proxy Product Owners introduces its very own challenges and complexities related to transparency. So choose wisely.

Commercial $crumundrum$

Now naturally it would have been a commercial blunder to not offer a scaled Scrum solution to large corporates, as clearly they cannot overcome the conviction that a big and complex entity requires something scaled to manage it.

The practice of scaling Scrum is controversial. It is almost paradoxical. Even the two co-writers of the Scrum Guide could not agree on a single scaled approach and they ultimately introduced each their own. I bet I am not far of the mark imagining that it was agreed the ‘scaling of Scrum’, inevitable as it was, was best done in a contained and controlled manner “without adding unnecessary complexity or straying from Scrum’s core principles” (as quoted from the Scrum Nexus Guide). If you can’t beat them… join them. Approaches like Nexus, Scrum@Scale, and LeSS do a decent job at reducing complexities to retain a level of simplicity and consistency. So yeah, a few extra toppings on top of that vanilla ice cream can be a guilty pleasure.

The Scrum Framework itself is a great, if not best, approach to scaling. It’s lightweight enough to enable all the freedom on the canvas required to deal with inter-team dependencies when it comes to collaborating on a single or even multiple products.

Now, if one still considers Scrum to be a box too small for one’s enterprise ego, I’d recommend these two Dr. Who’s Tardis intros as a metaphor to approaching Scaling with Scrum as-is.

Recommended continued reading:

Consider running through Willem-Jan Ageling assessments on Scales Scrum Frameworks:

Check out Paddy Corry’s hands-on advice on resolving complexity.

Plato’s Cave by Max Heiliger

Do you want to share an article in Serious Scrum? Connect with us and make it happen!

Also, you’re all invited to the Serious Scrum Slack workspace. Come join the conversation!