Can following a framework really be considered agile?

Basically, agile working methods are about three things:

  • To understand the organization's value creation and optimize the flow in the value delivery.
  • Dealing with uncertainty and taking advantage of new opportunities through exploration and short learning loops. That is, develop incrementally and iteratively.
  • To take advantage of the thinking power and creativity that exists in the organization by trust the people and create conditions for taking initiative and making decisions.

Behind these three points are principles from e.g. lean, the agile manifesto, Beyond Budgeting, SAFe, etc. various frameworks or philosophies. They help us understand how we can achieve results through, for example, flow optimization, learning and adaptability. Exactly how we then implement these principles in the form of methods and tools in the organization is up to us and depends on the context. Frameworks can contribute with examples in the form of patterns that show how to do things, but it is the management of the company or business that decides, who always need to understand the underlying principles and think for themselves.

But is it really "agile" to start from a framework?

Yes, it can be – if the framework is used with knowledge and insight, adapted to the prevailing circumstances. It is the management that decides on its own organization and working methods, no one else. Frameworks should be seen as knowledge bases, and precise descriptions of how to work should not be regarded as mandatory standards. How a business should implement agile principles depends on the specific context, and each business must take responsibility for that.

  • Each business determines how it should work. SAFe (or other frameworks) can never take over that responsibility.
  • No framework can either prevent or force the business to make bad decisions – stupid things can always be invented.
  • The framework can help those who want to come up with good things, but the business must think for itself based on principles and its own conditions. Otherwise, it can be stupid anyway.

What are the pitfalls when it comes to frameworks?

A pitfall is to be overly afraid of frameworks (e.g. SAFe). A fairly common misinterpretation is to see the framework as a mandatory standard. Often it is rooted in ignorance and that due to lack of time or self-confidence one does not learn the underlying principles. Then you could realize that you have to "implement everything by the book" for it to work, which in turn can lead to a fear that the framework will force you to do things that are not right for the business. Seen in perspective, this seems completely crazy, but it's actually not completely unusual. The consequence is either (if one is careless) that one implements the entire package without understanding why (so-called cargo cult behavior) which leads very wrong.

Excessive skepticism towards frameworks can instead lead to actively deciding that "we really shouldn't use SAFe here". Then you risk missing out on valuable knowledge and many strong enablers for effective value creation. Since Scaled Agile constantly collects good ideas and proven ways of working and integrates them into its framework, if you want to avoid everything that can be connected to SAFe on principle, it is unnecessarily complicated.

Therefore, it is as foolish to avoid frameworks entirely as it is to use them as if they were mandatory standards.


Anyone who has decided to do an "agile transformation", or to "implement SAFe" - Stop, step back and think again:

  1. Formulate why you want to change at all and what effects you are looking for
  2. Gather your relevant knowledge of lean/agile principles and working methods. Here, it can be good for you to look at several different frameworks in parallel and compare to really understand the important underlying principles and then jointly decide whether this is something that you think will help you get better.
  3. Understand why your business exists, and the value the business creates for its customers and stakeholders. Understand these value flows and that in the long run no part of the business is completely unaffected by this type of change.
  4. Implement the change with an agile approach using vision and roadmap, but in small steps with flow, trust and short learning loops that allow you to adjust based on the facts relevant to you.
  5. Feel free to use a framework as support and to get a common language. By the time you've gotten this far, you've gained enough understanding to not have to fear the framework. Not even for SAFe…

Previous Insight: The Budget Game Tour 2022

Previous Insight: A changing world requires dynamic control models