Reflections on the Scaled Agile® Framework

Following my SAFe® Agilist course and study for the exam, I took a more comprehensive look into the Scaled Agile® method and framework. I have decided to share my reflections, hope you enjoy it, and please, do not hesitate to comment.

The SAFe® 5.0 Framework (https://www.scaledagileframework.com/#) is an approach developed to implement agile principles in the whole organization. It was initially conceptualized by Dean Leffingwell in his book “Scaling Software Agility Best Practices for Large Enterprises” (2007) and he later developed the framework as “The Agile Enterprise Big Picture” in his book “Agile Software Requirements Lean Requirements Practices for Teams, Programs, and the Enterprise” (2011). From there it evolved through versions 2, 3, 4 and finally 5.0 in 2019.

The SAFe® Framework is based on two foundational approaches: Agile and Lean.

Agile was initially developed for small autonomous teams working on discrete endeavors (projects). The Agile Alliance (www.agilealliance.com) was created in 2001 by IT practitioners working in an iterative development context (Scrum, UP, Evo, XP…). Out of their initial meetings came the Agile Manifesto with its 4 values and 12 principles (https://www.agilealliance.org/agile101/the-agile-manifesto/).

Lean was initially applied as a manufacturing process derived from “The Toyota Way” developed in the 1930’s. The term Lean was first coined by John Krafick in 1988 (https://en.wikipedia.org/wiki/John_Krafcik). Womack and Jones (1996) later defined Lean as "...a way to do more and more with less and less [..] while coming closer and closer to providing customers exactly what they want". They identified 5 stages to lean management: 1) specify value, 2) identify the value stream, 3) create flow, 4) let the customer pull, and 5) pursue perfection

The other underlying concept in SAFe® is that of “scaling agile to the enterprise” (Leffingwell, 2007) or to large groups, beyond the agile team (Larman & Vodde, 2009). The concept of scaling is related to that of complexity, where a pattern can be repeated (infinitely) at different levels, i.e. a similar decision process repeated from operations to strategy.

Scaled Agile® seems to have started with that concept but evolved towards a different, more complicated, model. Although elements of scaling are applied in the framework (e.g. continuous delivery, backlog), there are also numerous examples where those elements are emergent (e.g. Enterprise Solution Delivery, Large Solution SAFe) rather than scaled (an entity that has properties its parts do not have on their own). This means that, version 5.0 in particular, is more complicated than I would have expected After consulting other sources, including earlier versions, I managed to better understand how the Framework had been structured and when I became more fluent with the vocabulary, it started making more sense.

I understand that the Scaled Agile® approach and its implementation in organisations is complex, but all the literature on, and our own experience with, complexity show that complexity is better resolved with simplicity than complicatedness. Over time, all large systems are subjected to emergence and eventually become complicated if there is not a conscious effort to eliminate redundancies and keep them simple.

The other element that, in my opinion, is debatable is the 12 steps implementation roadmap (https://www.scaledagileframework.com/implementation-roadmap/), which shows how to implement Scaled Agile® in an organization. In my experience organizational change is complex and iterative, not linear, and the roadmap diagram does not reflect this. The PMI®s “Managing Change in Organizations: A Practice Guide” (PMI, 2013) shows a more iterative picture of change (p.20, Figure 2-5 and p.28 Figures 3-3 & 3.4) that, in my judgment, is closer to reality.

Concerning the Framework itself, I really liked the ease of navigation to its different elements (https://www.scaledagileframework.com/#). It was quite easy to look up each of them and I used that feature extensively to study for the exam. But what was particularly difficult as first-time users is the slew of principles, core values, steps and other methods that are promoted within SAFe®; each of those adds to the complicatedness and requires that newcomers learn new vocabulary. There are also many acronyms that are not defined; it seems to be assumed that readers had a prior knowledge of the language, which is not always the case.

All in all, I really like to concept that underlies Scaled Agile® and plan to combine several elements with change and program management as well as strategy implementation. Because the framework shares elements with agile and lean, I have, through my practice of iterative processes, change and value management, experienced many of them successfully.

I plan to share some of these ideas in further posts.

References:

Larman, Craig, and Bas Vodde (2009). Scaling Lean and Agile Development. Upper Saddle River, NJ: Addison-Wesley.

Leffingwell, Dean. (2007) Scaling Software Agility, Best Practices for Large Enterprises. Pearson Education. Google Books Edition.

Leffingwell, Dean. (2011) Agile Software Requirements (Agile Software Development Series). Pearson Education. Kindle Edition.

Womack, James P.; Jones, Daniel T.; (1996), Lean Thinking: Banish Waste And Create Wealth In Your Corporation, Simon & Shuster, UK.