Skip to Content

SAFe’s narrow view on projects, portfolios, and operational excellence

Henk-Jan van der Klis
February 6, 2020

Early January 2020, I was studying the version 5.0 content of the popular Scaled Agile Framework (SAFe) by Dean Leffingwell et al to re-certify and obtain a SAFe 5.0 Agilist badge. The framework’s perspective on projects, portfolios, and operational excellence grabbed my attention. Based on my understanding of the project management profession and a background as a business economist, I don’t share that perspective. In this long read, I’ll explain what I mean with a narrow view on reality beyond the organizational agility according to SAFe.

Where did the authors of SAFe get their inspiration?

It is important to know the fundaments to every framework. Every author and thinker stands on the shoulders of previous ones. What are the underlying paradigms and sources of inspiration for the creators of SAFe? These works are listed as recommended reading or sources to thematic articles  in the SAFe Big Picture:

SAFe strengths

The amalgam of Lean, Agile Manifesto, Scrum, Change management, The Lean Startup, Portfolio management, Systems Thinking, and Design Thinking is powerful in:

  • The behavior, principles, and values needed to show leadership in an agile transformation and inspire employees in an organization.
  • Customer-centricity.
  • DevOps practices like continuous exploration, continuous integration, and continuous deployment.
  • Portfolio management.
  • Anchoring the changes in the organizational strategy without impeding the agility and bottom-up innovation.
  • Practice Lean principles.

SAFe and projects

Like many other Agile frameworks that need to prove themselves as the way to survive as an organization in a fast-moving world, the authors of SAFe resist projects and project management in multiple places in the framework and articles.

In the elaboration of the function and goal of epics (note that in a typical backlog management hierarchy an epic sits between themes and features and stories with work for multiple squads in multiple applications for at least three months) SAFe states: “It’s important to note that epics are not merely a synonym for projects; they operate quite differently, as the Figure highlights. SAFe generally discourages using the project funding model (refer to the Lean Portfolio Management article). Instead, the funding to implement epics is allocated directly to the value streams within a portfolio. Moreover, Agile Release Trains (ARTs) develop and deliver epics following the Lean Startup Cycle.” Function and funding are mingled here. That doesn’t contribute to clarity.

I only agree with the statement in the first row in this table and will elaborate on my objections to the other statements.

#2 A definitive start and end date, and scope?

To state that projects, without exception, have a fixed duration and scope that needs to be fully implemented, ignores the notion that during the project lifecycle unplanned changes can happen that impact the scope and limiting the freedom of choice to be flexible on scope (functionality), time, money (costs, budget), quality, benefits, and risks, or fixate parts of these dimensions with tolerances (degrees of freedom, room to maneuver).

#3 Task completion as a measure of progress?

The project management method PRINCE2 is crystal clear about the second and third statements. Task completion doesn’t say anything about progress. The delivered products that were accepted by the customer or end-user count. In PRINCE2 the principles ‘product-based planning’ and ‘continued business justification’ are applied. The Standard for Project Management states: “Value, including value from the perspective of the customer, is the ultimate success indicator and driver of projects. (…) To support value realization from projects, teams shift focus from deliverables to outcomes. (…) Project teams evaluate progress and adapt to ensure the expected value can be realized.”

“Definitive start and end date” in the second statement imply that one cannot modify either one. The Standard for Project Management states on the contrary: “The temporary nature of projects indicates a beginning and an end to the project work. A project ends in one of two ways:

  • The project objectives have been met.
  • The project is terminated because its objectives will not or cannot be met, the cost to deliver exceeds the expected value, or there is no longer a need for the project.”

#4 Always a detailed, quantitative business case?

In the fourth statement, projects are accused to work with an “overly detailed business case, based on speculative ROI.” How detailed a business case should be, needs to be agreed with your audience, and is one of the aspects to be tailored to your project environment. There are many projects with a clear business justification without any extensive calculations in a business case sheet. The return on investment is not an input, as the table states, but a possible result of a quantitative business case. It is up to the organization to determine whether viability is based on return on investment, net present value, payback time, which interest rates and thresholds for payback time, net present value, and returns are used, and which investments and costs need to be included in the calculation.

#5 Waterfall?

Many members of the Agile community think that projects are sequential and a synonym to Waterfall as a kind of common enemy. Lots of Agilist are rooted in IT and software development, and therefore I can understand their misconception to a certain level. The Waterfall model is a sequential system development method with feedback loops in every phase. Since system development typically was organized as a project, waterfall became by accident a description for a software development project. Trace the original article by W.W. Royce in 1970, and only then draw your conclusion. Modern system development methods like RAD, RUP, DSDM, and others within Agile still are based on the inherent order of activities, e.g. analyze – design – build – test. SAFe too contains articles explaining mini waterfalls and the V-model. A system development method is a delivery approach, not a project management method. Projects are unique, and the way projects are managed needs to be tailored. Be careful to think that Big Design Upfront is the only option. Remember that Agile approaches are meant for a volatile, uncertain, complex, and ambiguous (VUCA) environment. Fortunately, not every environment is like that. I don’t need for example SAFe to organize a party for my 50th anniversary or the next summer holiday. Digging a tunnel passage or a series of new houses in our village doesn’t require an Agile framework.

#6 Commitment for the whole project?

This statement contradicts the assumption that all projects follow a stage-gate approach. In the PRINCE2 training, I always explain that the project manager better could be called stage manager since the project is managed stage by stage. Only for the current stage a mandate, budget, and a detailed plan with tolerances is produced, baselined, executed, and managed. With my comments to the second statement in mind, I don’t see the need for a commitment to the whole project is many circumstances.

And what is the value of commitment if your plans are fallible and unrealistic in terms of performance aspects time, costs, risks, quality, benefits, and scope? Stop the project, so PRINCE2 recommends then instead of wasting more resources.

Driven by which value?

SAFe has added a tenth principle, Organize around value, in the 5.0 version. The exposure draft of the 7th edition of The Standard for Project Management on the first page states: “The standard describes the Value Delivery System, of which projects are a fundamental component. The standard identifies principles that guide the practice of project management practitioners, project team members, and other stakeholders who work on or who are engaged with projects. The principles support the achievement of the intended outcomes that ultimately deliver value to organizations and stakeholders.” Value, however, is undefined in SAFe, yet it is in The Standard for Project Management: “the net tangible or intangible result of realized benefits less the cost of achieving those benefits.” and “The evolution of business and the interplay of various environmental forces drive the practice of project management toward a value-based system. The value-based system is a framework for optimizing outcomes by balancing elements such as cost, quality, risk, stakeholder interests, and resources.”

SAFe and portfolios

Although SAFe has spoken about the program and portfolio level for many years, both are undefined in the framework. Since projects don’t exist in SAFe, the definition of a portfolio as in The Standard for Portfolio Management – Fourth Edition cannot be applied, since it defines a portfolio as “a collection of projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives.”

SAFe pays the right attention to Lean Portfolio Management and Lean Budget Guardrails. Portfolio management in SAFe around Solution Trains, Agile Release Trains, Solutions, and Program Increments to realize a Portfolio Vision strives for strategic goals with a set of projects, programs, other portfolios, and operational activities. While the ultimate goal may be the same, the means are different.

SAFe and operational excellence

I have trouble with the relationship between SAFe and operational excellence, in Lean Portfolio Management (LPM) connected via the dimension Agile Portfolio Operations. SAFe presumes that the Agile Program Management Office/Lean-Agile Center of Excellence (APMO/LACE), Communities of Practice (CoPs) for Release Train Engineers (RTEs), and Scrum Masters are active in this dimension.

SAFe considers itself as the organization’s second operating system to service the network of stakeholders with a virtual organization, so that value is added for customers with products and services that fit, whereby speed of innovation counts, without the need to modify the hierarchy (primary operating model, line management that is aiming stability and efficiency), or start anew.

To accelerate operational excellence, SAFe states: “Operational excellence is a process that focuses on continually improving efficiency, practices, and results to optimize business performance. The LPM function plays a leadership role in operational excellence, helping the organization achieve its business goals relentlessly. The LACE, which may be a standalone group or part of the APMO, is often responsible for leading operational excellence. In either case, the LACE becomes a continuous source of energy to power the enterprise through the necessary organizational changes.”

Next to product leadership and customer intimacy, operational excellence is core to considering options for an organizational strategy in the classic The Discipline of Market Leaders: Choose Your Customers, Narrow Your Focus, Dominate Your Market (Traecey & Wiersema, 1995). Traditionally, an organization should excel in one of these three strategies, while keeping the other two on par at least with the competitors. In the digital economy, where electronic products and data are sold – think of Uber, Airbnb, Google, Facebook, and Spotify – cost efficiency is easily treated as operational excellence. Some people state that it’s not necessary anymore to choose between the strategies. That’s quite a shortcut since an efficient organization doesn’t descend from heaven in a blink of an eye. You can argue that the organizations in the given examples aim for product leadership (convenience, access, experience) and customer intimacy (customer self-service, extreme sensitivity to Net Promotor Score and customer feedback).

The Lean philosophy and the more quantitative, empirical Lean Six Sigma approach are rooted in the drive to make production processes as lean and efficient as possible (Lean Manufacturing) by eliminating six forms (Six Sigma). This combination gave Motorola in the United States in 1986 an alternative to the Japanese Kaizen model. It’s fun to see Lean consultants organizing a Kaizen meeting.

The standardized production of automobiles (Toyota Production System) is one of the environments where Lean Manufacturing (often abbreviated to Lean) originates from. If you link Lean, which is the basis for SAFe (compare the Lean Manufactory visual with the SAFe House of Lean) without any context to operational excellence in a SAFe context, some implicit, noteworthy paradigm shifts were made:

  • Agile approaches such as Scrum, one that SAFe applies on the team level, are meant for product development with many uncertainties.
  • Kanban in its original context of the Toyota Production System mentioned before is a signal card to get the attention of assembly line employees. Together, they should solve the solution in the assembly line, fix a broken machine or remove the impediment as soon as possible, to get the production flow restored.
  • Strive for operational excellence by removing bottlenecks in the existing assembly line – note the difference between interventions by contemporary (external) Lean consultants and the self-organized employees who exactly know how machines are working and can be repaired – eliminating waste, applying pull (your car is made once you specified and ordered it) instead of push (everyone will get a black T-Ford), Just In Time supply of resources, may not be served by imposing the secondary, network operating model with all bells and whistles (Agile Program Management Office/Lean-Agile Center of Excellence (APMO/LACE), Communities of Practice (CoPs) for Release Train Engineers (RTEs), and Scrum Masters). The once lean start-up (as described by Eric Ries) can easily result in a machine bureaucracy (from Henry Mintzberg’s The Structuring of Organizations).
  • You can adjust and improve your operations if it’s embedded in an Agile Release Train or in DevOps teams easier compared to working in a secondary operating model alongside the existing organization.

Conclusion

With the recent additions in the 5.0 version of SAFe, a collective denial of the roots of the framework and reality outside the expanded playing field with incorporated roles, rituals, and patterns is likely to happen. The application of terms that are well-defined or have a different meaning elsewhere, misunderstanding instead of an understood common language is fueled. Where SAFe is used to face the enormous challenge to get hundreds of employees to collaborate as well-connected smooth-running trains according to schedule and within budget, satisfying customers, production processes, projects, programs, and portfolios need to be organized and managed as well, each with good practices and approaches from the respective disciplines. No single framework or method is a panacea.