20% DISCOUNT ON ALL OUR COURSES 14 hours 48 minutes 31 seconds Use coupon code: BlackFriday on checkout

SAFe is a Scaled Agile Framework, Not a Scaled Agile Methodology

SAFe is a Scaled Agile Framework, Not a Scaled Agile Methodology

Last week this was a theme in the Implementing SAFe class Ofer Cohen and I ran in Waltham, MA.

We find it crucial when training new SAFe Program Consultants (SPCs) to emphasize 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 which can be used to 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 process required.

… 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. …

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 within many contexts, but not necessarily best practices that always work.

For example, we don’t believe story point estimation is necessarily the best way to estimate in all cases. We believe that sometimes it’s enough to just count stories.

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 )

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.

Bottom line, both when it comes to how to practice SAFe as well as how to implement it, we prefer to consider it a very useful but flexible/incomplete structure that requires well-trained and experienced practitioners to successfully apply, and that’s a key design principle for our Implementing SAFe workshops where we train future SPCs.

Comments ( 3 )

  • David

    Well said. I think many, many people approach SAFe’s Big Picture and think “Great! We just do all this and we’ll be Agile!” when, in fact, that’s a recipe for failure. I tell my teams that SAFe is a collection of practices that, for the most part, are defined elsewhere. It’s important to know what all those elsewheres say about the practices that they, in fact, invented before believing that you “get” SAFe.

    SAFe is a sometimes brilliant framework in how it pulls various practices together. It is no disservice to Scaled Agile to acknowledge that SAFe depends upon those practices being done well in their own right in order to reach its own maximum effectiveness.

  • Agile/Lean

    Nice article! I wish people go back to fundamentals of agile and lean and solve the root causes of problems than taking frameworks by book. There is definitely some good stuff in the frameworks but somethings go against the core principles of lean and agile.

    • Thank you for your thoughts Santhip. curious as to which things go against the core of lean/agile in your perspective/experience.

Give a comment

1 × 3 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Skip to content
%d bloggers like this: