SAFe Is a Framework, Not a Methodology
The difference between a framework and a methodology matters. SAFe gives you structure and choices, not a prescriptive path, and that changes how you use it.
Click image to open full size We find it crucial to emphasize when training new SAFe Program Consultants (SPCs) that they should use SAFe as a framework, not a methodology.
First, what’s the difference between a framework and a methodology? I found this concise, useful comparison written by Liz Keogh, who I think highly of over at Quora -
A methodology is a set of principles, tools, and practices that can guide processes to achieve a particular goal.
A framework is a loose but incomplete structure that leaves room for other practices and tools to be included but provides much of the required process.
… Scrum could be considered a framework, as it leaves room for teams to choose their own technical processes, development roles, etc. XP might be considered a methodology, as it provides guidelines for all the same things that Scrum does, along with relevant technical practices. …
Options, not a prescribed method
With this in mind, what we emphasize in the workshop is the options and choices you have when you Implement SAFe. Yes, some people look at SAFe and see a methodology that tells you how to estimate, prioritize, plan, how your kanban boards should look like and what questions to ask in each Scrum of Scrums. We prefer to see all of those as a good set of options to start with in many contexts, but not necessarily best practices that always work.
For example, we don’t believe story points estimation is necessarily the best way to estimate in all cases. Sometimes it’s enough to forecast using smaller slices and throughput instead of turning it into story point theater.
The schedule/agenda for PI Planning is great, but we definitely inspect and adapt it on every implementation depending on the context and encourage SPCs and RTEs we teach to do it as well.
We always inspect and adapt the definition of Workflow of the Program and Portfolio Kanban boards on our implementations and we talk about it in class as well.
We always mention that SAFe’s approach to Weighted-Shortest-Job-First Cost-of-Delay-based prioritization is only one option and that some other interesting and useful and maybe even better ones for your context are available (and we point people to Don Reinertsen and Joshua Arnold )
Structure and rollout choices
What is the right Agile Release Train and Value Stream design? SAFe provides ways to help you design your implementation including some principles and considerations, but it doesn’t give you a hard and fast answer… This is one of my favorite sessions in the Implementing SAFe class actually.
Which elements of the SAFe Big Picture do you need? Which Spanning Palette or Large Solution elements does it make sense to use even if you’re using just Essential SAFe? And does it make sense to use Large Solution or Portfolio or Full? When?
In general, What is the right way to roll out at scale? Again, SAFe gives you some options and considerations to be aware of but doesn’t give you a concrete playbook.
Why flexibility beats prescription
Bottom line, when it comes to practicing and implementing SAFe, we prefer to consider it a very useful but flexible/incomplete structure that requires well-trained and experienced practitioners to successfully apply. That’s a key design principle for my work with organizations on scaling agility using SAFe without compromising on agility.
Practical thinking on turning AI pilots, adoption, and portfolio work into business impact - by finding the constraint, changing the work, and proving value as you go.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →
- 01 SAFe Configurations 7 min
- 02 SAFe Criticism, Deconstructed: The SPC Role 4 min