Last week, I commented on some changes I’d like to see in the SAFe Big Picture.
Today, let me suggest some changes in the ‘standard implementation roadmap’ that’s a part of SAFe. If you’ve read my stuff for a while, forgive the repetition, because much of this I’ve covered here or there.
Here’s the tl;dr – I think we need to structure change planning around three core principles:
Changes are incremental and complete (i.e. you can make the change and stop);
Incremental changes are prioritized based on their ability to solve the most pressing problems/deliver on the most pressing opportunities for the organization;
Leaders go first.
If you look at the SAFe roadmap through this lens, you see a lot of issues – many of which I’ve seen and I think many of us see in change work we’ve done.
We built long change plans and then then change capacity runs out, have to abandon them in flight – which means they don’t always deliver the goods.
We often plan change around logical organizational skillbuilding instead of impact – which means we do things that help the organization build agile skills – but don’t necessarily solve pressing problems.
And we let leaders tell us to ‘make them agile’ while they keep walking the same path, meaning that agile becomes a layer in the bottom or middle of the organization, and ultimately gets worn down by top-level culture or top-level planning, reporting and financial structures.
Overall, I think the roadmap as it exists is optimized in favor of making the agile transformation as efficient as possible – i.e. at maximizing the efficient use of the organizations internal or external agile resources.
What it doesn’t do is tailor the path of adoption to the actual problems the organization is hoping to solve by shifting toward agility.
Let’s talk about why that’s a problem.
Change uses capacity – people’s time and attention that could otherwise be applied to doing the stuff that makes the organization deliver value. What we’re not doing with traditional agile implementation roadmaps (I pick on SAFe, but it isn’t alone) is optimizing the path forward around using the organization’s change capacity in ways that effectively and visibly (visibility counts) solve the organization’s problems.
I sketched out a quick model for this in an earlier post (Sketching an alternative SAFe Implementation Path (substack.com) ) and had a map of it here:
So the major changes from the current SAFe path (which looks like this:
Here are the key differences (as I see them – feel free to weigh in…):
The SAFe roadmap kicks off with a decision to go, and then trains change agents and then leaders. I think you need a conditional decision to go, followed by an assessment that delivers a problem statement (what part of the org are we talking about? What are we trying to accomplish for them?) and an explicit plan to deliver change that ties to the desired outcomes, and validates that the capacity to take on that change exists.
Only then do we decide to proceed (and deciding not to or to proceed in a different direction is explicitly a step).
The next thing we do is train leaders and build a Lean Portfolio for the specific part of the organization we want to change. Why start here? First, because leaders always go first. They set an example for the people who report to them, and by adopting elements of the new ways of working, they create conditions that encourage the changes we seek rather than impede them. Second, because one of the challenges of lean or agile change is always dealing with the inherently ‘dirty’ (incomplete, unformed, unprioritized) work that the newly agile groups are supposed to ingest. By starting with ‘clean fuel’ – structured, prioritized work – the downstream change becomes far, far easier.
And again, we can pivot or persevere (based largely on the assessment/planning work done before) once we’ve done this.
Only then do we start setting up agile teams and integrating them into ART’s.
And in parallel we should be setting up the technical infrastructure that will support true agile delivery (of systems, or for non-technical groups, of operations or outputs that support the desired outcomes).
This isn’t exhaustive (and I really ought to flesh out my sketches as I have time in the coming week or so) – but it does kind of ground the direction I think would be worthwhile.
As always – what do you think?
Marc this is very insightful. Indeed, a problem-centric approach is what I usually advocate. This is Theory of Constraints, and I like your principles that leaders go first, and that changes small be incremental but complete. Those are interesting ideas.
I also would encourage people to look beyond the SAFe toolkit. I think it is a mistake to try to "implement SAFe", even if you do it a little at a time. SAFe contains some good ideas, but SAFe alone will not make you Agile, and most likely SAFe is too much structure for your situation and will bog you down - especially when you consider all of the other elements (which SAFe has coopted - like DevOps).
What I advocate is looking for ideas in frameworks and elsewhere; then start with where you are, then identify your biggest sources of pain, try to understand the root cause, then figure out how to address that in incremental steps: and to do that, look to frameworks and other sources (DevOps, Lean, operations research, ...) for ideas - but ALWAYS craft your own approach, and refine/adjust it over time to make things better and better.
I believe these are the thoughts behind the recommended implmentation:
You may need help in convincing leadership that change is needed. SAFe advocates developing a team to guide the movement to SAFe. Federated change agents, which may include some leadership, are trained before leaders to assist with changing processes and cultures, including those of leadership. The problem statement and recommended transformation approach is included as input to the decision to change. This will probably take several discussions - first to agree there's a problem to be solved, next to agree that Agile is the best approach, and last to agree that SAFe is the top option to try.
Trains are constructed prior to the LPM level because it's a pull system: you need a functioning train to accept the goals identified by the LPM level. Trains can start with "clean fuel" by only tackling new work and ingesting them as features or using "dirty fuel", implying some work breakdown rework by the PM, RTE, Solution Architect, team, etc. You've pointed out the benefit of clean fuel. The downside is those who stay with the waterfall work can feel left behind. The decision to inject "clean" or "dirty" work into the train is situational, IMHO.
It's a nice article and definitely got me thinking. Thanks for posting it!