SAFe Agilist Anti-Patterns: Leaders Who Certify and Change Nothing

The most common anti-pattern in SAFe is not a process error. It is a leader who completes Leading SAFe, sponsors the adoption, requires the teams to change how they work, and changes nothing about how they themselves fund, govern or decide. Everything below follows from that, and each one is recognisable from the outside within a single Program Increment.

Key Highlights

• The dominant SAFe anti-pattern is asking teams to adopt new practices while leadership retains project funding, per-release approval gates and unchanged reporting.
• SAFe is presented as a leadership framework, which is why the Lean-Agile Leadership material sits at the foundation of the model rather than alongside it.
• The Innovation and Planning Iteration exists as an estimating buffer and innovation time, and using it to absorb carryover work is one of the most widespread misuses in the framework.
• Inspect and Adapt fails when improvement items are identified and never funded, which turns the workshop into a recurring list of the same complaints.
• Business Owners assigning business value outside PI Planning removes the negotiation the event exists to produce.
• Anti-patterns are diagnosable from outside the organisation, because each produces a visible symptom that does not require access to internal reporting.

Why leadership anti-patterns dominate

Team-level anti-patterns exist and they are mostly self-correcting. A team running a bad retrospective usually notices and fixes it, because they feel the cost directly and they own the remedy. This is why team-level Agile coaching produces visible results relatively quickly and why organisations often conclude, wrongly, that the same approach applied further up will work the same way.

Leadership anti-patterns are different in three ways. The people creating them do not experience the consequence, the people experiencing the consequence cannot fix it, and nobody in the organisation is positioned to name it. That combination is why they persist for years.

It is also why they appear in a leadership course rather than in team training. The material on Lean-Agile leadership is not an introduction to the framework. It is the part that determines whether the rest of it functions.

The certification anti-pattern

The parent of most of the others, and worth naming precisely.

A leader takes Leading SAFe. They now understand the framework, sponsor the adoption, and communicate it well. Teams reorganise into an Agile Release Train, PI Planning is scheduled, the events run.

Meanwhile funding still moves annually by project. Approvals still route through the same board. Reporting still asks for percentage complete against a fixed scope. Nothing above the team has changed at all.

The result is an organisation running SAFe ceremonies inside a non-SAFe operating model. The teams absorb the cost of the new process and none of the benefit, because every decision the process is designed to accelerate still queues behind the old machinery.

The diagnostic question is short. After the adoption, what does leadership do differently. If the honest answer is that they attend PI Planning, the adoption has not happened yet.

Anti-patterns in the events

PI Planning as a presentation. The event exists so teams build the plan and commit to it. Where leadership arrives with the plan already made and uses the two days to communicate it, you get attendance without commitment. The tell is whether any team leaves with a materially different plan than they arrived with. If plans never change during the event, it is not planning. Our PI Planning guide covers what the event should actually produce.

Business value assigned afterwards. Business Owners assign business value to PI Objectives during PI Planning, in the room, with teams present. Doing it by email afterwards removes the negotiation, which was the point. Teams learn what leadership values by arguing about it, not by receiving a number.

Inspect and Adapt without funded outcomes. The workshop produces improvement items and they compete with feature work for capacity in the next PI. Feature work wins every time unless someone protects the improvement item. Two or three PIs of this and the workshop becomes theatre, with the same issues raised and no one expecting action.

The Innovation and Planning Iteration as a catch-up sprint. It exists as an estimating buffer for meeting PI Objectives and as dedicated time for innovation and learning. Using it routinely to finish carryover work is extremely common, and it removes the buffer that made the PI commitment credible in the first place. The organisation then wonders why predictability is poor.

The System Demo as a series of team demos. It is supposed to show integrated functionality across the whole train. Where each team demonstrates its own work in sequence, nothing is integrated and the event confirms nothing. This one is worth catching early because it is easy to fix and expensive to leave: a train can run for a year believing it is integrating continuously while every demonstration happens against a local branch, and the discovery usually arrives at the worst possible moment.

Anti-patterns in structure and funding

Trains built around the org chart. An Agile Release Train should be organised around a development value stream, so that it can deliver something end to end. Where trains are drawn around existing departments, dependencies between trains multiply and the coordination problem gets moved rather than solved.

Projects renamed as value streams. Lean Portfolio Management funds value streams rather than projects. Relabelling a project portfolio as a value stream portfolio while keeping annual fixed-scope funding changes the vocabulary and nothing else. This is the most consequential anti-pattern on the list because it defeats the entire portfolio layer.

Guardrails that are actually approval gates. Lean budgets come with guardrails, which are spending policies. Where every decision inside the guardrail still requires sign-off, the decentralisation the model depends on has not happened. The tell is asking what a value stream can spend without asking permission. If the answer is nothing, the budget is not lean regardless of what it is called.

The train with no Business Owners. Business Owners are a named accountability. Where nobody senior is genuinely on the hook for the value the train delivers, PI Objectives get assigned business value by whoever is available, and the number stops meaning anything.

Anti-patterns in behaviour

These are harder to see and they do the most damage.

Punishing early bad news. The single most destructive thing a leader can do in a SAFe organisation, because every inspect-and-adapt mechanism assumes honest inputs. One public interrogation of a team that raised a slip early teaches everyone watching what visibility costs, and the reporting quietly turns green from then on. What makes this so hard to reverse is that the leader involved usually does not remember doing it. They asked a reasonable question in a difficult meeting. Everyone else in the room drew a conclusion and acted on it for the next two years, and no amount of subsequently saying that bad news is welcome undoes a single demonstration to the contrary.

Treating teams as allocatable capacity. Moving people between teams to balance utilisation destroys the stable team assumption the whole framework rests on. Velocity becomes meaningless, and so does any planning built on it.

Changing priorities between planning events. Direction changes are legitimate. Changing them outside the planning cadence means teams execute one objective while being measured against another, which produces the appearance of poor delivery when the actual cause is upstream.

Requiring the framework and not learning it. Leaders who mandate SAFe without understanding what the events produce cannot tell a functioning implementation from a ceremonial one, which makes them unable to intervene usefully and prone to intervening anyway.

The anti-patterns that look like good practice

The hardest ones to name are the ones that resemble diligence, because arguing against them sounds like arguing against rigour.

Adding governance to the train. A steering committee reviewing the ART's plan after PI Planning, on the reasonable grounds that someone senior should check it. What it actually does is make the planning event provisional. Teams learn that the plan is a proposal, commitment weakens, and the confidence vote becomes theatre because everyone knows the real decision happens later.

Standardising everything across trains. Consistent boards, consistent definitions of done, consistent reporting. Presented as enabling comparison, and comparison between trains is rarely a decision anyone acts on. The cost is that trains lose the ability to adapt their practice to their context, which is the mechanism relentless improvement runs on.

Measuring more. Adding metrics because they are available. Each is defensible individually and collectively they create a reporting burden that consumes the capacity improvement work needed. A train reporting fifteen numbers is usually acting on none of them.

Training everybody. Certifying the whole organisation before changing anything. It feels thorough and it front-loads cost while deferring the structural change that produces the benefit. It also means everyone learns the framework, sees nothing change, and concludes it does not work.

Perfecting the first train before launching the second. Sensible-sounding and usually wrong, because the second train is where you learn what was specific to the first. Organisations that wait for a perfect first train often wait indefinitely.

The common thread is that each is a reasonable instinct from a pre-SAFe operating model applied inside a SAFe structure. That is what makes them persistent: nobody is being careless, and the behaviour is exactly what the previous system rewarded.

The tells, at a glance

How to raise one without losing the room

Naming an anti-pattern to the person creating it is the actual job, and it goes badly more often than it needs to.

Describe the symptom, not the diagnosis. Improvement items from the last three workshops have not been actioned lands better than leadership does not support improvement. The first is checkable and the second is an accusation.

Attach it to something they care about. Predictability, delivery dates, attrition. An anti-pattern framed as a framework violation invites a debate about the framework. Framed as the reason a date slipped, it invites a conversation about the cause.

Bring the mechanism. Explain why the practice produces the outcome. Leaders who mandated SAFe without learning it often genuinely do not know that the IP Iteration was a buffer, and will change it once they do.

Ask rather than assert where you can. What happened to the improvement items from the last PI is a better opening than a statement, because it lets the answer come from them.

This is a substantial part of what a SAFe Agilist is for, and it is the reason Leading SAFe certification training spends as much time on leadership behaviour as it does on framework mechanics.

What to do if you are inside one

Practical guidance for the far more common position of recognising an anti-pattern you did not create and cannot unilaterally fix.

Pick one. Not the list. An organisation presented with seven anti-patterns hears criticism; an organisation presented with one hears a problem. Choose the one causing the most visible pain rather than the one that annoys you most.

Find the person who feels the consequence. Anti-patterns persist because the creator and the sufferer are different people. Someone senior is experiencing the symptom, usually as unpredictable delivery, and does not know the cause. That person is your route.

Make the smallest possible ask. Fund one improvement item this PI. Protect the Innovation and Planning Iteration for one cycle. Have Business Owners attend one value assignment. A small reversible change gets agreed where a principle does not.

Measure it. If the small change works, you have evidence rather than an argument, and evidence is what gets the second change agreed.

Accept that some will not move. Where funding structures sit above your organisation entirely, no amount of framing changes them. Knowing which battles are unwinnable is part of doing this work sustainably, and spending a year on one is how people burn out of transformation roles.

This is difficult work and it is most of what the role actually involves. The framework knowledge takes two days. Learning to raise an uncomfortable observation to someone senior without being dismissed takes considerably longer, and it is what Leading SAFe certification training is really preparing leaders for. If you want to test how well you know what each event is supposed to produce, which is the ground you have to stand on for any of these conversations, the free Leading SAFe practice test takes a few minutes.

The three that are worth tolerating

Not every deviation is a problem, and treating them all as one is its own anti-pattern. Three are usually worth leaving alone.

Modified event names. Organisations that call PI Planning something else, or run a shortened version, are frequently doing the substance correctly. The name is not the mechanism. Spending credibility on renaming an event that already produces commitment is a poor trade.

A configuration smaller than the framework suggests. Starting with Essential and staying there is supported rather than deficient. Not every organisation needs the portfolio layer, and the four levels of the Scaled Agile Framework are presented as configurations precisely so you can stop where the problem stops.

Partial adoption across the organisation. One train operating well while the rest of the business runs traditionally is often the correct interim state, not a half-finished job. Forcing uniform adoption before the first train has proved anything is how expensive failures start.

The test for whether a deviation matters is whether the mechanism still functions. Does the planning event produce commitment. Does improvement get funded. Does bad news travel early. If those hold, the label on the calendar invite is not worth a fight, and a SAFe Agilist who picks fights over vocabulary spends credibility they will need for the funding conversation.

That judgement, knowing which deviations matter and which do not, is most of what separates useful framework knowledge from pedantry, and it is a large part of what Leading SAFe certification training is trying to build.

The one question worth asking

If you want a single diagnostic for whether an adoption is real, ask what leadership does differently now compared with before.

Not what the teams do. What leadership does. How money moves, who approves what, what gets reported, and what happens when someone raises a problem early.

If those four answers are unchanged, the organisation has bought a set of ceremonies. The teams will absorb the overhead, the reporting will look healthier than the delivery, and in eighteen months someone will conclude that the framework does not work.

That conclusion will be wrong, and it will be understandable. The framework was never the part that had to change.

For leaders who want to avoid that outcome, Leading SAFe certification training covers the leadership behaviours the framework actually depends on, and the free Leading SAFe practice test is a quick way to check how well you already know what each event is meant to produce.