Helping Dolphins understand SAFe

Wolfram Müller “the BlueDolphin”
by Marshall Guillory, Scaled Agile SPCT 
Thursday, February 24, 2022

Punching the card

This is my annual commitment to SAFe2 apologetics on a public forum. I consider it a waste, but necessary. So, let’s move this bottleneck where it should be fairly shaken out.


SAFe is still the market leader!

With 37% market share3 the Scaled Agile Framework for Lean Enterprises (SAFe 5.1) is the clear and demonstrable market leader. The next closest anything near this is 3%.

Think about that for a minute.

There is a reason why. It is the highest quality product in the market that aggregates the battle proven and thoroughly vetted practices, patterns, and values that drive the world’s most innovative and successful organizations to greater heights.

Let’s compare the scaling agile industry to the automotive industry in the United States for fun, if not for a serious analysis of the disparity and view into the success of the SAFe as an enterprise agile and scrum framework. The total automotive market in the US in 2021 was roughly $83B dollars1. The top manufacturer was General Motors who sold 2.269M units. Followed by Toyota and Ford, respectively, selling 2.234M and 1.892M units. The shares of the total sales equate to 15% each for GM and Toyota and 13% for Ford. The big three automakers market share standard deviation is 1.4% (sd-0.0139).

When we compare the market share of the top three scaling frameworks, SAFe, [email protected]/SoS(a whole story in of itself), and Enterprise Scrum from the late Mike Beedle we get a much different story. We all intuitively understand one of the success factors in business is capturing market share. Which can be used in different strategies to further progress towards business goals in the market. The standard deviation of the top three scaling frameworks market share is 17% (sd-0.1709) or 12 times that of the comparison industry! That is a huge gulf and shows a clear market leader that is producing a far superior product.

Want to know a not so secret dirty little secret that SAFe bashers don’t like to discuss? Most of what is in the SAFe is also part of the practices, patterns, and value systems in the competing products. Just like automobile’s all the frameworks have propulsion engines or motors, wheels and tires, windshields and seats. The differences lie in performance, quality, overall packaging, et cetera — like all products.

It’s fascinating to watch the fumbling. Real hard hitting, fair, and accurate criticisms are rare. Very rare indeed in the public forum.


The truth will set you free

Wolfram Müller “the BlueDolphin recently posted this LinkedIn post attacking the merits and content of the SAFe. Let’s unpack his spurious claims with an open mind and common sense.

Claim #1 Little – SAFe hast batches/cadences, accepts backlogs and 100% load – there is a lot of Work-in-Process … this is against Little

-Wolfram Müller “the BlueDolphin”

The average waiting time and the average number of items waiting for..a service in a service system are important measurements for a manager. Little’s Law relates these two metrics via the average rate of arrivals to the system. This fundamental law has found numerous uses in operations management and managerial decision making.

-MIT4

I suspect all that I should do is point out SAFe Principle #6Visualize and limit WIP, reduce batch sizes, and manage queue lengths. Little’s Law is included in the SAFe courseware since the beginning.

To quote Wolfram directly from his article, “I call Little’s Law “the law of lead time (or time to market).” This is curious when cast as a criticism because the SAFe directly has a stated5 business benefit to “reduce time to market.”

Figure 1. SAFe business benefits derived directly from case studies written by SAFe customers

© Scaled Agile, Inc.

Wolfram’s commentary suggests that batches and cadences are bad, along with those evil backlogs. And then the icing on the cake… the claim that SAFe guidance says teams must load capacity 100%. All of which is incorrect.

SAFe actually suggests in the guidance that teams must optimize batch size and specifically recommends against 100% utilization. Reinertsen’s book, “The Principles of Product Development Flow – see QUEUEING PRINCIPLES” comes to mind and the explicit suggestions that a system operating at 100% is an economic disaster waiting to happen. That book is a cornerstone in SAFe. So I find this analysis very puzzling.

Batches are inherent in any manufacturing or production system. You cannot get rid of the batch. But teams should absolutely relentlessly improve their continuous delivery pipeline to optimize batch sizes while managing queue lengths to the economic/business/technical benefit of the system given the constraint(s). Sure, tear down the monuments! But don’t destroy productive capability unnecessarily. That’s waste if it isn’t tied to an optimized system improvement.

Here are a couple of big things in SAFe that are a rather unique way for organizations to address complexity and the issue of too much WIP. SAFe PI Planning and the Innovation & Planning Iteration (IP Iteration/Sprint).

PI Planning has a stated outcome of “creating alignment to a shared mission and vision…” The benefits to the business are very clearly stated. One of the several ways in which SAFe guidance addresses the challenges of impediments to flow, managing queues, reducing batch sizes is through Lean Thinking and queuing theory context is through the process of PI Planning. SAFe also employs the power of Scrum. It is woven into the framework as a fractal – implying empiricism at the team, program, large solution, and portfolio contexts.

Scrum Guides (scrumguides.org)

Scrum has backlogs, both Product and Sprint. Per the Scrum Guide, “The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.”

Scrum implements Lean Thinking and so does the SAFe.

Teams work from prioritized a ART backlog that has itself gone through a synthesis and orchestration of refinement to optimized batch sizes. This includes special attention to architectural concerns with the construction of an architectural runway that is prepared ahead of the ART so that pace and cadence of change (architecture) can be managed given the variabilities in the system.

Scaled Agile, Inc – scaledagileframework.com

The IP Iteration is literally constructed to address Little’s Law. Managing queue lengths to avoid the tyranny of the urgent in an empirical product development system is critical. We know from many decades of lean manufacturing that running at system at full capacity is not sustainable. The I&A sprint allows time and space for teams to re-group, learn, innovate, and plan – which would otherwise just be another sprint grinder.

It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.

-© Scaled Agile, Inc.

Visualizing and limiting work in process are no brainer things to do in modern IT, software and business teams. I don’t understand this attack at all as the SAFe explicitly recommends that teams LIMIT work in process using WIP limits and all of the common features of a true kanban system like classes of service, buffers, policies, exit/entry criteria, et cetera. Clearly “for” Little’s Law, not against it. In fact, Little’s Law is part of the courseware!! There is literally an entire principle in SAFe dedicated to this concept. How did you miss that one?


Claim #2 Goldratt – SAFe relies on independent value streams – in practice, they are often coupled – networks – then a constraint must be visible … it is there in SAFe, but you don’t see it

-Wolfram Müller “the BlueDolphin”

Did you know that Alex Yakyma, Dean and other founders and contributors to the framework geek out on Goldratt and have integrated his learnings into the SAFe? That Dr. Mik Kirsten’s Flow Framework was carefully curated and integrated into the SAFe?

SAFe Principle #3 – Assume variability; preserve options

© Scaled Agile, Inc.

SAFe value stream identification, DevOps, and the development of the continuous delivery pipeline (CDP) actually teaches businesses to learn how to see flow. To develop an understanding of the value stream chain upstream, downstream and the network connections – to decompose the silos and de-scale the organization using Lean and Systems Thinking theories.

SAFe Business Agility, Organizational Agility, Systems and Lean Thinking requires that the organizational design consider system-wide optimization. Moving the constraint to an economically preferable location is part of the thinking process and a goal of creating the change and organizational design hypothesis. The illustrative features in SAFe are the operational value stream, development value stream, team topologies, ART topologies, ARTs, and business agility value stream concepts. Again, SAFe inherently supports Goldratt’s theories and his books are required and/or recommended reading for SPCTs. So, a second checkmark for SAFe.

SAFe as an operating system with DevOps when used properly exposes the constraint(s) in the system and the entire value stream (upstream and downstream). It allows the teams to remove the constraint, or move it to a more economically/technically feasible position in the delivery pipeline. Relentless improvement follows… The constraint moves, or another constraint becomes the bottleneck. Rinse and repeat. Inspect and adapt. Apply #TOC, Lean and Systems Thinking – this concept is included in the SAFe guidance.

Speaking of #TOC and #Lean Thinking… SAFe includes these thinking tools, values and practices. It’s literally everywhere in the framework. Lean is in the name. Moving on.


Claim #3 Ashby – SAFe is a pure production system, but the ability to manage projects is just left out … so SAFe is under complex – less complex than the world – half fail

This is a non-sequitur packaged in a straw man argument. SAFe guidances helps teams and businesses implement “product” thinking for the world’s largest and most complex cyber physical systems – by design.

Scaled Agile Framework – Scaled Agile, Inc.

The proposition in SAFe is to use the practices and guidance in the framework to create better business outcomes when work is within the complex domain (complexity theory). SAFe does not say anything about an organization not using or using project management in other domains. It is unnecessary. The PMI and Prince2 has that covered.

Also, SAFe is and has been regularly used for systems integrators operations & maintenance, and support type work along side production/enhancement/product work since the beginning. It’s guidance. Good consultants apply the best practices for the clients benefit. SAFe certainly appeared “software centric” in the early days — but that never stopped any of us from using the good things for other things.

Adaptive organizations learn how to use project management, Lean, Agile where appropriate to the greatest benefit to the customer and the goals of the organization. We do not throw away tools or practices. We use the right tool for the job.


Claim #4 Conway – here I think SAFe has some merits – there is a lot of communication in several layers and possibilities – it’s for thinking complex systems

Well, a gift here. He sees the elements of Conway’s Law weaved into the framework. It’s almost like Dean was thinking about Conway’s Law and ways to address organizational design, complexity, social constructs, and communication when he built SAFe.


Claim #5 Shannon – SAFe relies on cadences/sprints/PI cycles – these all slow down the communication frequency … today you normally communicate relevant signals in real-time – SAFe is too slow to signal important critical signals

We have two principles and some design to consider here. First, there is Principle #7 Apply cadence, synchronize with cross-domain planning that specifically addresses the issues around communication and job role and duties that are aligned to enable flow. SAFe in my experience does exactly the opposite of Wolfram’s claim…it speeds up communication and makes it more efficient, effective and of much higher quality. Teams are self-organized around the vision for the development value stream. They use Scrum and Kanban systems. They practice the lean-agile values and principles.

The teams in SAFe gain the same benefits of any well practiced and high performing Scrum team. The fractal and roles in SAFe are the glue in the network and enable the operating system. There are programmatic events too, and portfolio events that enable the balanced and effective signaling Wolfram refers to in his article with regard to the Shannon–Hartley theorem. Teams are limited in size, and teams of teams are also limited to 50-125 people (Dunbar’s Number). For each addition to complexity and the number of people involved, the system needs efficient mechanisms to maintain alignment to the vision. The Agile Release Train concept and Solution Train concepts in SAFe also address the Shannon-Hartley theorem. SAFe also conceptually recognizes Lean concepts, value streams, and portfolios with complex enterprises.

This all works in part because of SAFe Principle #9Decentralize decision-making where the traditional ivory tower of decision making is dismantled to move those decisions to where the information is. This enables real-time communication with the dynamics of smart and motivated people and teams to drive a sustainable pace.



Claim #6 Haken/Schiepek – to use self-organization, you need two things (1) an organization in underload (fails s. #1 and #2), and you need one signal out of the flowing element (projects, epics, stories) that is used for all as a priority signal … there is no such thing in SAFe

Again, I can sense a clear lack of understanding of fundamental concepts in SAFe. Principle #10: Organize around value and the empirical feedback loop hook: RE-ORGANIZE around value are included in SAFe.

Other parts of SAFe reply loudly here too – the enterprise backlog model, WSJF, and the connected backlogs, Scrum, Agile, Kanban, Lean, Systems Thinking, the roles, the events, the principles, the core values, the philosophy, and the communication that occurs within the social construct and networks within the business agility, operational and development value streams.

El ARADO: Plausible Effective Change Models for Yahoo & Microsoft Merge
https://en.wikipedia.org/wiki/Virginia_Satir

Once again, SAFe is very explicit about limiting WIP and one of the things that is often the most revealing in the early stages of the Satir change model in a SAFe implementation is that hidden things all of a sudden become very visible and transparent. These are SIGNALS in the system showing where the constraint is and where it will move to soon after an improvement. We know that SAFe works best in the “complex domain” or when trying to bring order to chaos (see Cynefin and Systems Theory).

Closing

So what I see in the SAFe when implemented properly by qualified consultants and coaches is a framework that FULLY embraces the concepts of Lean and Systems Thinking, and the great thought leadership provided by Dr. Mik Kersten in the Flow Framework.

Flow is inherent in a properly designed SAFe value stream network. SAFe gets all six check marks by my analysis and understanding.

  1. https://www.statista.com/statistics/200002/international-car-sales-since-1990/ and https://www.zippia.com/advice/automotive-industry-statistics/
  2. scaledagileframework.com
  3. https://digital.ai/resource-center/analyst-reports/state-of-agile-report
  4. http://web.eng.ucsd.edu/~massimo/ECE158A/Handouts_files/Little.pdf
  5. https://www.scaledagileframework.com/safe-for-lean-enterprises/