Is SAFe^® really agile?

Currently, there are many ways to introduce agility into the company with the help of frameworks or methods. One framework that receives great praise and is criticized at the same time is SAFe - the Scaled Agile Framework.

SAFe is a framework that draws on the knowledge of many other methods in an attempt to develop solutions with multiple agile teams. The questions I get asked more often in the process: Don't the many methods and structures slow down the agile idea? Do we need longer for our transformation with SAFe?

From structure to responsibility

It is difficult to give a short answer to these questions. First, I would argue that structures make sense and we definitely need them when implementing agile mindsets. Once we have managed to apply them with success, we can minimize structures and move more into ownership - but that takes time. So working agile doesn't mean we can work without structures, rules or plans. In the beginning, these things are extremely important, although they could be minimized depending on the maturity of a team or the organization. Does this mean that we need longer to become truly agile? And then is it really agile at all?

SAFe puts the focus on solutions

In addition to enterprise development, the Scaled Agile Framework also focuses on providing solutions that are developed by multiple agile teams simultaneously. This means: Agile teams should already be in place. Mindset and rules within the teams should be known and lived. A change of mindset within a company needs time, which is not given to this process in some companies.

When we talk about structures and hierarchical roles within SAFe, this does not mean that we are here in "outdated" decision-making structures. Rather, it is trying to focus on the solution to be developed and consider how many agile teams (Scrum Master, Product Owner and Developer) are needed to deliver this solution incrementally in high quality.

Besides these agile teams, the Scaled Agile Framework tries to introduce roles to coordinate and improve this development from "above" (e.g. Release Train Engineer & Product Management). With the hint to adapt roles according to the maturity level of the teams, it is possible to use well-trained Scrum Masters who can supervise several agile teams. Likewise, it always depends on which goal is to be achieved with the framework and thus on which level of SAFe is used.

Transparency, decision making and accountability in SAFe

In my opinion, many companies set their own focus incorrectly. Too many roles inhibit development and decision-making between levels. But even with few roles, the exact same thing can happen to us. What's my point? Try to put your focus not only on the roles, but also on frameworks that are supposed to facilitate the work of these roles, e.g. transparency, decision-making or self-responsibility.

Transparency and proper decision making can help us lose less time in our development. Often, results are already "there" but still need to be entered into a formal report, for example. Rather, I recommend a platform or tool where we try to map relevant and up-to-date information. This information is transparent to key roles and stakeholders and accessible at all times. Also try to consider which decisions you need to make yourself and which decisions teams can make independently. This will achieve faster decision-making processes while building trust and motivation in teams. These are just a few frameworks that the Scaled Agile Framework also addresses.

Personally, I come to the conclusion that SAFe is agile for me. We just have to pay attention to how agile the company already is, otherwise the implementation of the whole thing can of course take longer and the agility we hope for cannot be achieved.