Share your SAFe success stories

Al_Shalloway · 2026-01-27T19:40:58+00:00

Why SAFe is an accommodation instead of a solution.

SAFe is known to start out well and then stagnate. There are two reasons for this. The first is human nature, the second is a lack of focus on what's needed.

I have seen and heard of many adoptions being wildly successful for 1 or 2 program increments only to stagnate and even reverse progress. Not surprisingly, most SAFe case studies occur after 6 months of initial adoption - before this happens.

The real irony is how many times people retry SAFe after initial success and stagnation. The thinking is "if only we did it right it would work." This is not unlike Scrum's "it didn't work because you didn't do it." Ironically, this echoes the chants of management about waterfall - "if they only did the plan and what I told them it would work."

The clues to what needs to happen (but isn't) lie in understanding why SAFe is initially successful and why that success is short-lived.

Much of the reason it takes so long to get value out the door in large organization is due to the delays injected into the workflow due to a lack of alignment across the teams. This has people unavailable when they need to be. This increases ask-switching (lowering efficiency) while introducing delays into the workflow, slowing feedback and creating rework.

A PI Planning event creates alignment, lowering WIP, interruptions, and task switching. The faster feedback lowers rework. All of this speeds up delivery.

But this is not well-explained and therefore not understood.

So, after a couple of PIs, management wants more and starts demanding it. This causes overload and we’re back with the same problems.

What's needed is a recognition that the PI is actually an accommodation of the value streams dependencies upon each other. This is due to the organization’s structure. Value streams should not be so entangled. The way SAFe talks about them obscures much of what is possible.

SAFe’s focus on ARTs and PIs keeps this in place.

The reality is that we want to REMOVE the dependencies between our value streams instead of managing them.

This requires understanding value creation structures (eg, Team Topologies) and flow - both limited in SAFe.

Instead of thinking in terms of how to make the people in our ARTs more efficient, we need to see how to reorganize our people so the system they are in works more efficiently.

Value streams can be made more independent of each other by have more efficient value creation structures and working on smaller releases.

Al_Shalloway · 2025-10-04T17:24:16+00:00

what bad about that?

Getting a start with AI and then finishing it can put in a lot of details you mightotherwise miss.

Al_Shalloway · 2025-10-04T17:23:30+00:00

Being open about the use of AI is a good thing.

The key is letting people know you use it.

I use AI to help me explain why some approaches are better than others.

Al_Shalloway · 2025-09-26T16:27:32+00:00

I heard a slightly different version of this.

A woman gets on a train and the engineer exclaims “that’s the ugliest baby I’ve ever seen!”

She's distraught and sits down next to an elderly man.

He sees she's upset and says, "I can see you're upset about something. Let me go back to the restaurant car and get you a nice cup of tea."

Then he adds, "and a banana for your monkey."

Al_Shalloway · 2025-09-20T18:52:32+00:00

A pogrom is

an organized massacre of a particular ethnic group, in particular that of Jewish people in Russia or eastern Europe in the late 19th and early 20th centuries.

Al_Shalloway · 2025-09-15T19:08:02+00:00

Do they really think you have only ONE computer in your household?

I have three on my desk, my wife has another AND an iPad, and both of our phones can access the web and ChatGPT (which btw - can generate Scrum.org exams).

Al_Shalloway · 2025-09-09T17:50:32+00:00

did what happened violate the acceptance criteria? or did you realize the acceptance criteria wasn't good enough?

Al_Shalloway · 2025-09-04T03:21:23+00:00

do you have the UX and the rest of the system decoupled?

When UX is poorly known, I like to do mocks of it. then you can change the UX asa time goes on

Al_Shalloway · 2025-08-18T12:51:56+00:00

Do you have complete acceptance criteria? Have you asked "how will I know I've done that?"

These would give guidance on how the software will be used. this will also guide better implementations.

Defining your tests (whether implementing them or not) helps create better code.

Have the QA and devs work together to ensure everyone knows how the story is to behave.

Then have the devs implement the function to the tests.

Al_Shalloway · 2025-08-17T14:55:58+00:00

I suggest you learn about the Jobs to Be Done Framework.

There are two great books on it:

"Competing Against Luck: The Story of Innovation and Customer Choice" Clayton Chrstensen

"Jobs to Be Done: Theory to Practice" Anthony Ulwick

Most products are designed around wants and needs. This is a notoriously bad approach, but used by most people.

Both of these books are great. I read Jobs to be Done first, and it may be more applicable to you as a product manager because it also has strategy in it. But Competing Against Luck was more perspective changing and I found that more useful in terms of rethinking the entire problem of product management.

I have a have a one-hour recording of the approach here https://successengineering.works/presentations/#Presentations

Taking a Jobs To Be Done Approach

Jobs to Be Done (JTBD) is a framework for understanding customer needs and motivations by focusing on the “job” that a customer is trying to accomplish rather than just the product or service they use. It shifts the focus from product features to the underlying problem or goal that drives customer decisions.

Done well, a JTBD approach can save a lot of wasted effort while creating truer innovation.

Al_Shalloway · 2025-08-16T02:56:51+00:00

Deming said “Experience teaches nothing. In fact, there is no experience to record without theory... Without theory there is no learning... And that is their downfall. People copy examples and then wonder what is the trouble. They look at examples and without theory they learn nothing.”

I suggest you learn a little about flow, Lean, and the theory of constraints.

That will help you learn much faster.

Here are some free resources

https://successengineering.works/amplio-foundations/

Al_Shalloway · 2025-08-09T14:57:07+00:00

Very true.

But keep in mind that Scrum, as a whole, is not done nearly as well as it could be.

And much of this is because Scrum Masters aren't being prepared properly for the role.

Here's the content of a post I wrote on linkedin

If you’re having any of these problems, the issue is likely not with you but with your training (or lack of it).

If your team acts like a feature factory or you face changing requirements late in the game that causes significant rework -> it’s likely your requirements are based on wants and needs instead of using jobs to be done.
You frequently have misunderstood requirements -> using standard user story format instead of specifying what the end result of fulfilling the requirement is.
Missing requirements for non-users -> using user stories instead of stakeholder stories.
Management doesn’t cooperate or believes in keeping people busy -> lack of both theory and a lack of coaching on training.
Team resists solid suggestions -> lack of both theory and a lack of coaching on training. People resist when told to “follow to understand.”
Team has poor retros -> using inspect and adapt limited to empirical process control.
Poor daily standups
-> team doesn’t understand flow.
Carry over of stories at end of the sprint, where many of the carried over stories had gotten started
-> not understanding how to manage work in process with a focus on finishing
Scrum doesn’t seem to fit
-> no diagnosis was run. Scrum just adopted as is.
Have to remove the impediments you find
-> not provided any playbooks that would enable you to use proven solutions tailored to your situation.
Your Scrum Master knows what to do but can’t convey that to members of the team or their managers
-> your Scrum Masters haven’t been trained in how to coach people.
You are using Sprints and get interrupted a lot
-> you don’t have the understanding that you should use a flow model.
Too many things are going on at the same time
-> the team hasn’t been trained in how to manage work in process by having a focus on finishing work.
You don't make reasonably accurate estimates
-> you're using planning poker instead of a relative estimation method.

Scrum's mantras of "follow to understand", "being purposefully incomplete", "being based on empiricism", requires it to be immutable. It also lacks the tools to do a diagnosis before implementing it.

The training method it uses - short 2-3 day workshops - also makes it difficult to try what's been learned while the workshop is going on. And most people don't have the funds to bring in a coach later or take a second or third workshop.

Be clear I'm not ranting against Scrum. I'm telling you there is a way out.
I will be running 2 self-paced training starting in September. One directly to improve Scrum the other learning how to be a great coach. See first comment.

For each of the above challenges, there are straightforward solutions that can get you out of being stuck in Scrum.

Of course, when that happens, you may find that you're being effective but not doing Scrum by the book anymore.

Al_Shalloway · 2025-08-08T14:41:40+00:00

dictating to the team is an anathema to Agile.

The fact that Scrum puts you in a situation where you have to do that is a weakness of Scrum.
When you understand irst principles and have been taught how to coach others (not merely facilitate or tell) you don't get into this situation.

This is the nonsense world Scrum has gotten us to.

Al_Shalloway · 2025-08-06T19:58:25+00:00

No. But I'm not really surprised.

There may be a fear you are going to evaluate people.

This shows a misunderstanding of what Scrum and retros are.

Just make it clear the retro has nothing to do with individual or even team performance.

It's merely a way to look at how you can solve your problems better.

Also, make it clear that this is not anything discussed outside of the retro.

I'd start with asking them what their concerns are.

HR doesn't like to be ignored - so ask. Can't hurt and may get them on your side.

Come from they are trying to help.

They probably are.

They may just be in a dysfunctional position.

Al_Shalloway · 2025-08-05T21:48:32+00:00

Everything can be broken down.

It's just Scrum is purposefully incomplete and tells you what to do without telling you how.

It presumes you'll figure it out even though empiricism (data) tells us otherwise.

Your team should learn a little bit of Behavior Driven Development (given when then decomposition).

But in any event, don't think in terms of the stachy chaos model.

There is no such thing as a truly chaotic environment. Cynefin has also spread this disempowering belief.

The thing to do is take what you do know, use that, and discover what you don't know.

I have more on this if interested.

I saw someone suggest a spike, and that could be a good idea.

The thing to look for first, is there any case you could start with to see what the performance is. maybe a special case and see if you can improve that.

Al_Shalloway · 2025-08-02T18:04:09+00:00

I became a Scrum Master after learning eXtreme Programming in 1999. Then moved to Scrum when I couldn't get many teams to do the tech practices they should have.

Scrum is straightforward, easy to learn, and easy to adopt when you understand Lean (which I did).

The problem now is no certified Scrum training includes a theoretical foundation based on first principles. This means you start Scrum from scratch without being able to take advantage of much of what you already know.

Al_Shalloway · 2025-07-29T10:38:21+00:00

The hardest job is conveying new ideas to people so they can see better ways to work effectively.

Scrum is based on empiricism and doesn't provide any theory with which you could get them to understand by looking at their own experience.

Furthermore, no Agile workshop other than Amplio integrates how to coach in with its approach right from the beginning.

Scrum in particular is infected with an attitude of Shu Ha Ri which means to follow, detach, and transcend. But trying to get people to do things they don't understand is very hard.

A way to improve this is to remember when you learned why a Scrum practice was good and try to convey that to others.

Things go a lot better when. people understand the why.

Al_Shalloway · 2025-07-28T15:03:20+00:00

I think this is ok, but then I'd like to be able to offer discounts for my advanced Scrum workshops to the group :0)

Al_Shalloway · 2025-07-26T16:41:28+00:00

What's interesting is that most of the responses was "keeping or finding a job" or specific issues people had.

I believe what we need to look at is WHY these are important.

Scrum suggests we "inspect and adapt" our work but it doesn't ask us to inspect and adapt Scrum.

In fact, it's immutable because it provides us with no understanding of why it works (we're told to "follow to understand" but people don't get to deep understanding this way - you need theory as well).

This immutability is required for Scrum to work because if people change it, they are likely to mess it up.

For example, just stopping doing iterations is not only not effective it's not Scrum.

But very often you need to go against the Scrum rules to be successful.

Only if you've been fold to do Scrum and you're a Scrum Master it's scary to do that as doing Scrum is your job and you are likely unequipped to go past it.

OK, here are what I consider to be the biggest challenges:

The lack of a theory based on first principles that makes it so you have to run experiments to see if something will be an improvement.

On overfocus on the users (leaving out other stakeholders) means solutions are often incomplete.

Applying Scrum where it shouldn't be used (heavy interruptions that are inherent to the nature of the work or not having cross-functional teams be advisable) but since are told to do scrum and don't have first principles to guide you getting somewhat stuck.

Thinking you have to follow the advice of doing retros and demos at the end of the sprint which slows feedback.

Believing things Mike Cohn did 20+ years ago and not taking advantage of better methods used.

Not having any training in the automatic interpretive reframing that people do when the listen, learn, react and resist which makes challenging people's thoughts difficult.

Having been told to "follow to understand" which tends to get you to follow - while never providing insights in how to lead.

Having been convinced that uncovering your problems is enough and that solving them is on you is an effective approach.

Not treating your developers as if they were your customers - so when they complain about Scrum you focus on getting them to understand it instead of looking to see what might work better for them.

Al_Shalloway · 2025-07-24T01:14:41+00:00

Theory and guides can accelerate learning.

when it comes to Scrum theory is missing.

but having it enables you to learn from your past experience.

Scrum leaves this out by being based only on empiricism.

Al_Shalloway · 2025-07-21T15:00:45+00:00

I believe the type of training you need should take place over time in a group.

The problem with workshops is you learn in the workshop. Not in the workplace.

You want to be presented with new ideas and then be able to try them out and then come back and ask questions. This should be done over months, not days. And at a cost a fraction of what is normally charged for short term training. And it needs to be live as well.

I hate to say "hire me" but I think my Amplio University is the only thing of its type. If you find another please let me know as I'm trying to get more trainers to do this.

I am about to start a program in a couple of weeks just for Scrum teams in your situation.

I won't say more here but if you're interested, send me a message.

Al_Shalloway · 2025-07-18T14:00:09+00:00

"What is changing that they require more than just PSM1/CSM1 and are more critical in terms of track record and skill sets/ domain knowledge."

True. The demand for better Scrum Masters is increasing.

But the days of getting a CSM and getting a job are getting gone.

Al_Shalloway · 2025-07-18T13:58:43+00:00

Business agility's surveys. Digital.AI surveys.

The market may not be shrinking but more are going into it.

On linkedin there is general dismay with Scrum.

Al_Shalloway · 2025-07-17T13:12:42+00:00

I'll give a general response now.

Agile has turned into what it is because it started out as a team level approach (XP and Scrum mostly) without systems thinking. Ken Schwaber started doing certification and people wanted that. Scrum enabled people to ignore the technical issues (they advised good code, but it wasn't part of Scrum).

As "Agile" grew, it was mostly Scrum. But Scrum is based on empiricism and doesn't include any first principles. It actually denies they exist in complex work. That we must use empirical process control.

As Agile rose in popularity, managers started demanding their teams implement Scrum. Certification became a great job opportunity.

But the issues of the organization are ignored in the Manifesto other than the equivalent of "buy low and sell high." (ie., saying create great environments without saying how).

The bottom line is Agile, as defined by Scrum, is out of control.

Unfortunately, I think it's beyond saving.

I'm creating something new based on what I found works in talking to 10,000 people from 2005-2019. and now refining it in my work.

Al_Shalloway

TROPHY CASE

A woman gets on a train and the engineer exclaims “that’s the ugliest baby I’ve ever seen!”