There’s a lot of criticism of the Scaled Agile Framework (SAFe) that does the rounds and it’s not my intention to add to it. In my consulting days a lot of the larger organisations that I worked with had a number of characteristics that made SAFe an appropriate first step:
- Autocratic leadership and centralised control;
- Teams largely comprised of order takers rather than problem solvers (a natural symptom of 1.);
- Dysfunctional leadership teams with hidden agendas;
- Bureaucratic funding and governance processes;
- Monolithic technology architecture with limited or no automation coverage;
- Heavy reliance on vendors who were managed under the assumption that they could not be trusted.
Frankly none of those characteristics are an easy fix and it can take several years to move an organisation in the right direction, often with a few missteps and backwards steps along the way.
You can try to start with Scrum or XP in an environment like that but in my experience the egalitarian nature of the framework that you’re trying to roll out will often be completely at odds with the authoritarian culture of the workplace that you’re implementing it in. You may see pockets of success if you can sufficiently isolate teams from the machine, but the immune system of autocracies is strong and corporate antibodies are extremely good at sniffing out and exterminating anything that looks different.
For that reason unlike a lot of peers in agile circles in those contexts I was quite comfortable to recommend SAFe as a starting point. As someone who had spent several frustrating years on three $1B+ ‘transformation’ programs (the horror, the horror) it felt like a nice interim step - it’s close enough to what people are used to that it’s relatively easy to advocate for; and, it’s big enough to survive beyond initial rollout. If you had told me in 2005 that our national postal service would have a quality digital program that was able to retain parcels market share AND talent in 2022 I would have been very skeptical. SAFe played a key role in that.
Unfortunately, with the rise of popularity of SAFe as a scaled method I’m also seeing a rise in the popularity of agility anti-patterns, some of which create a lot of challenges in the remote / hybrid remote context. Here’s four of the most common that I’ve seen:
- Treating PI Planning like a destination rather than a diagnostic
- Pushing forward with PI Plans that resemble spaghetti
- Sticking with analogies that excite trainspotters
- Retrofitting SAFe into an agile environment to improve certainty
Let’s break those down…
---
If you’re treating PI planning like a destination rather than a diagnostic
Then work is always going to feel like work and will never be engaging or joyful
In a complex environment, where the pipeline is largely defined outside of your delivery teams, and where the work is rife with dependencies, SAFe’s PI Planning event (a derivative of Big Room Planning from Scrum) is a really effective way of surfacing complexity to leaders and bringing forward the discovery of information that can derail an initiative.
But.. your competitors (and by this I don’t necessarily mean your traditional competitors, I mean the ones that will disrupt you) don’t face these problems. They’ve worked hard to engineer out many of their dependencies and so that they can focus on how to execute on strategy rather than how to sequence work. While your teams are spending two days a quarter working out how to schedule the features that they’ve been given, their teams are striving to delight their customers and enter new markets. While your teams are twiddling their thumbs waiting for their laptops to boot or for the build to compile, their teams are solving problems. Their teams are in a state of flow. They’re engaged, productive, connected to customer value, and they’re going to be able to build better products faster and for less money than you can.
Instead leaders should treat PI Planning like a diagnostic. It's a brilliant way for you to see the mess in delivery, to make dependencies and impediments to progress visible, to highlight current and future capacity challenges, and gain insight into the human relationships in the system. The true value of PI Planning is not the plan, nor the confidence vote, it's a once a quarter opportunity to see just how hard it is to get anything done around here AND the impetus to fix it.
---
If… you’re pushing forward with PI Plans that look like spaghetti
Then… you’ve got an operating model design problem not a planning problem.
It’s very difficult to deliver a plan that looks like the one below and it gets harder when you’re not in the same room. It’s far more likely than not that the hidden queues, wait times and competing priorities in the system will derail any hope you have of success.
Instead, upon seeing a plan like this leaders need to focus on removing dependencies and on managing the spaces between teams rather than the teams themselves. This is particularly critical in remote or distributed environments when you can’t rely on personal relationships or serendipitous catch-ups to shape other teams’ priorities. Leaders also need to work closely with teams to break down the structural, architectural, knowledge, contractual and capability constraints that force their teams to work on components of the solution rather than on slices of value. If your plan looks like spaghetti, consider revisiting your operating model.
---
If you’re sticking with analogies that excite trainspotters
Then you’ll never evolve beyond batched delivery
When Spotify released a video describing its engineering culture and popularised the language of tribes, squads and chapters they were describing a point in time. Spotify has since moved onto more product centric concepts. Spotify’s teams don’t take initiatives into planning for execution, they take strategy directly into delivery using OKRs.
The ‘Release Train’ is a nice analogy for describing an environment where you regularly load up a train to deliver cargo. But there’s a subtle difference between being a train enthusiast and being a train spotter, and if you spend too much time playing choo-choos you risk finding yourself in the latter category. Successful delivery organisations don’t feed features into overloaded, fixed capacity carriages. Their teams are closely connected to customer feedback and they have agency in terms of how they’ll act on it.
Instead leaders should focus on the end-to-end value stream and ask themselves: What do we need to change to get closer to a model where teams can select from a backlog of customer problems, solve those problems, and deliver those solutions into customer's hands? How do we move away from fixed planning increments and towards a more fluid model where cross-team planning is an exception process rather than the rule?
---
If you’re thinking about retrofitting SAFe into an existing agile environment to improve certainty
Then you fundamentally don’t understand the conditions required for predictable delivery
You don’t get predictability by putting SAFe in over top of an existing set of teams. The unpredictability of delivery systems has nothing to do with the framework that you use. Unpredictability is a system condition, largely a property of wait times rather than work times. You can’t fix it with different events or with ‘better’ planning.
Instead, you get it by changing the way that you lead. By actively working to reduce internal and external dependencies, reducing the length of queues in the system, and ensuring that teams have sufficient latent capacity to adapt to changing circumstances. By moving away from monitoring adherence to big, up-front plans and commitments and towards reducing work in process and focussing on finding and fixing impediments to flow.
Tools like Flomatika and Blockedapp can provide you with data that can assist this process, but tools are not enough. The best leaders create environments where people don’t feel like unblocking impediments is a bureaucratic or political nightmare and act decisively when things are outside of their teams’ control.
—
SAFe is a nice starting point for organisations that are stuck in 1970s delivery approaches and are slaves to their vendors. This is sadly still not uncommon. If your organisation shares a lot of the characteristics I described in the introduction of this article it can be quite effective. It’s close enough to what exists to be familiar, it has enough meat and scale to survive resistance, and it’s definitely a step forward.
However, SAFe in this context is the first step on a journey, not a destination. Companies that are successful with agile adoption move on from SAFe’s Release Trains, PI Planning Sessions, heavyweight leadership structures and Portfolio Management processes. They evolve towards teams that have agency in how they design their system of work, that understand and can help to drive organisational strategy, and that feel like they can solve customer problems rather than just completing tasks.
