Despite all the criticisms, SAFe? is a mirror to Organisational Impediments that enables Flow and Value Delivery.

After spending a week with Andrew Sales, Chief Methodologist of Scaled Agile Inc., I found it refreshing to witness the shift in focus from SAFe? towards Flow and its significance.

However, this experience also prompted me to reflect on the criticisms that SAFe? receives, particularly from the Agile community, mainly from individuals who?may?not have fully understood and immersed themselves in the framework.

Admittedly, SAFe? is not perfect; some may even argue that it appears overly bloated. Nevertheless, it has evolved into a comprehensive body of knowledge for Lean and Agile practices, incorporating models, practices, and tools from various domains. Furthermore, there are numerous original contributions developed within SAFe? that others have also adopted.

Let me delve deeper into this subject.

While the Agile manifesto was primarily aimed at making software development safe (pun unintended) for software developers, I don’t believe it was ever anticipated by the 17 Agile thought leaders in Utah that Agile would scale in large corporate organisations. I believe Agile, Scrum, XP, and similar methodologies were primarily designed for small software development teams.

Now, my experience lies primarily within these large corporations. When I began my journey of helping organisations adopt Agile Ways of working, we initiated with Scrum at the team level, which yielded mixed success. We encountered various challenges, mainly due to solutions requiring collaboration with other teams or departments, resulting in a need for extensive coordination and project management to sequence the work for delivery. As Evan Leybourn aptly puts it, an organisation's agility is only as strong as its least Agile team.

Moreover, the context of these organisations must be taken into account. They typically deal with complex business and technology architectures, existing legacy siloed organisational structures, and challenging cultures, making it difficult for Scrum to thrive.

Now, let's return to SAFe?.

I have several questions that I would like readers to think about:

• Is it beneficial for multiple teams that need to build solutions to plan together?
• Is it a good idea to prioritise and sequence the backlog of work to deliver value to the customer?
• Is frequent and regular integration a valuable practice?
• Should we prioritise frequent feedback loops through integrated system demos and avoid leaving integration testing to the end?
• Is organising around value a wise approach?
• Is it a good thing for teams to learn together through inspect and adapt?
• Should we measure maturity, performance (flow), and outcomes?

In my opinion, the answer to most, if not all, of these questions is a resounding "yes."

Here's my view: SAFe? provides the practices necessary to embrace these valuable principles when building solutions at scale required for larger organizations (and not small independent software teams).

During all our sessions with Andrew, one thing resonated with me profoundly: SAFe(R) (and Agile) do not claim to have all the answers or solve all your problems. Instead, they act as a powerful mirror, reflecting the systemic impediments that leaders need to address in order to improve the flow of value for their teams.

In conclusion, the organisations I have had the privilege of working with, which have adopted SAFe?, have found themselves in a better position than when they started. For these large organisations, that's a remarkable achievement, and I am more than happy with that.

Let's shift our focus away from worrying about frameworks and instead concentrate on getting things done and delivering value.