SAFe is a Scaled Agile Framework, Not a Scaled Agile Methodology
- October 15, 2018
- Categories: Agile, Scaled Agile Framework, The AgileSparks Way
- Tags: Agile, AgileSparks, Scaled Agile Framework, SPC
- Author: Yuval Yeret
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, and 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.
