Frankly, I’m tired of all of the scaling frameworks. They’re mostly driven by three needs:
Creating revenue for the firms creating them;
From a company or organizational perspective, they’re indicative of lazy, buy agile in-a-box, thinking;
And they feed the “certification happy” nature of our community.
And yes, I too am guilty of falling into the above traps.
I think the introduction of Scrum@Scale has ticked me over the edge and inspired me to write this post. That and reading this article by Neil Perkin, which takes a more reflective view to leveraging useful bits from the various scaling frameworks.
Introduction
For some time, I’ve been frustrated with the large number of scaling frameworks AND their apparent lack of agility. Most attack the problem with more complexity and are disconnected from core agile principles.
That being said, it is helpful to have a “set of patterns” that assist organizations to scale. So, I thought I’d mine some of the most popular scaling frameworks for some patterns that I feel are useful or helpful. Let’s go…
Scrum of Scrums
Scrum of Scrums – a cross-team meeting as a synch-point for dependencies and interactions. There’s some debate over who attends and what the focus of the meeting is (team ward, leader-ward, status, synchronization, etc.), but the idea is quite sound and necessary for multi-team efforts.
Simplicity of Scaling – it’s just Scrum “up a level” as a mindset. You also see this same thinking in Nexus and LeSS, and Scrum@Scale, but it began with the Scrum of Scrums.
Spotify
Cross-cutting concerns – I really like the idea of Guilds & Chapters to couple groups across teams (squads) in areas like architecture, UX, test automation, etc.
Cyclical, release-level retrospectives – not only worrying about system level demo’s, but gathering the teams together for a broader, release-level retrospective and improving as a larger scale group.
Release reviews - tied to the above, more pervasive release reviews where the “whole company” gathers around and reviews the outcomes from the teams. I think of Spotify as amplifying the “social aspects” of scalability.
SAFe
Release Trains – synchronizing sprints and creating a unique release tempo (# of sprints) across a set of teams doing related work.
PI Planning – if you’re doing trains, then having a periodic “all teams” planning event can be particularly useful. A key is visualizing all of the team work streams together and creating a shared understanding (and view) towards the work. But note: I was doing this long before SAFe was introduced with good, old-fashioned release planning.
Architectural look-ahead – one of the things that agile teams often don’t do is look ahead sufficiently. You see that most in design and architecture. SAFe’s introduction of the notion of architectural runway is a very healthy metaphor for teams to pay attention to.
Nexus & LeSS
Feature teams – where teams have an “identity” of sorts around product areas, functional areas, or application areas. With (hopefully) reduced cross-team dependencies. Or more team control over their deliverables and more input into the care and feeding of their feature(s).
Emphasis on Product Owner singularity – where product owners take on a large backlog and then spread it across multiple teams.
Keep it simple AND small – what I like about these frameworks is that they stay true to scaling by leveraging the simplicity of Scrum and simply extending it for a small set of teams.
Disciplined Agile Delivery (DAD)
Regulatory guidance – DaD is unique in providing succinct guidance around how to support regulatory concerns in agile contexts.
Technical practices – provides design guidance for what I might call more traditional technical organizations. An example would be telecommunications or any hardware-oriented products.
Scrum@Scale
The Executive Action Team (EAT) – one of the most encouraging focus points in S@Scale is the notion of an EAT. Finally, someone is placing a real focus on the leadership team level AND their overall engagement and interaction with scaling.
Also reference Keep it Simple and Small AND the Scrum of Scrums.
Other Useful Ideas
It’s about the TEAM(s), stupid! – keeping the team (Front & Center) in everything we do is central to your success. That includes things like: self-direction, autonomy, trust, psychological safety, etc.
Big Wall Planning – I first stumbled on this idea from Mitch Lacey and I’ve seen quite a few clients get a lot of traction from it. Consider it PI Planning at the portfolio level and instead of the teams, it involves customers, stakeholders, and leaders.
Kanban for portfolio-level planning – while SAFe talks about Kanban being used at several levels, I think the simplest usage is for portfolio level planning where “Epics” need to be clarified, valued, and ordered from a variety of organizational perspectives. Kanban is idea for this. And it helps introduce the organization to lean concepts.
Hierarchal stories (and estimation) – I’m not a fan of SAFe’s different views towards Epics, Features, and Stories. I think you can maintain a larger-scale backlogs with simple user stories that are framed at different levels/sizes and decomposed along the delivery pipeline.
XP practices – something most of the scaling frameworks seem to forget (or underemphasize) is the importance of SOLID technical practices being leveraged with the teams. One of the most important preconditions to scaling is having solid, mature, and healthy agile teams to build upon.
Chief Product Owner – there’s quite a bit of debate around this role and even the need for it. For example, in Nexus, there is simply a “Product Owner” for the 2-9 team scaling unit. However, I’ve found that organizationally, it’s necessary to have someone guiding the ship from a product ownership AND product management perspective.
Challenges where you need to sort out your own scaling approaches
Agile outside of IT and software development
Hardware
Strong UX
DevOps integration
Regulatory domains (medical, financial, safety, government, etc.)
And there are probably many others. The point being – don’t look for Silver Bullet Frameworks. There are none, including my recommended list, and they won’t work for you.
Instead, put on your thinking hat and…create your own success!
Wrapping Up
I want to call the above, the Bob Galen Scaling Framework or BGSF. My hope is that it’s simple AND that you will pick the patterns that work for you.
Also note:
It’s not for sale. It IS free for you to use now and forever.
It doesn’t force you to create new roles (SAFe) or encourage you to fire old roles (LeSS).
It doesn’t have a series of certifications associated with it, nor will it ever.
It DOES have the distinction that I’ve used every one of the ideas I’ve presented as patterns. So, at least in my contexts, these have work well.
I don’t offer training directly related to BGSF. Although I do actively recommend these patterns in my coaching.
Please consider BGSF as a collection of patterns that might, in some combination, be useful to you in your scaling efforts.
But never, never lose sight of:
The importance of your teams;
A focus towards the simplest possible thing that can work;
The realization that your context is unique, so everything needs to be thoughtfully applied;
Respect for existing roles and the Kanban notion of starting where you are;
And finally, that you can’t buy your way to effective agile scaling. You’ll need to create / emerge solutions that work for you.
Stay agile my friends,
Bob.
BTW: My colleague Mike Hall has written a wonderful article that aligns well with this one. He identifies the 5 Practices to Start Scaling Agile. And I love his
Postscript
After I wrote this article, I posted two other articles that have a direct connection to this one. One is on Scrum@Scale after I took the practitioner class. And the other is related to De-scaling practices.
You might want to peruse them as well…