A world may seem to separate the "soft-power" intentions of the Agile Manifesto from the hegemonic marketing that has turned Scaled Agile and its SAFe methodology into the "most widely used scaled model in the world," especially since the former is more aimed at teams, while the latter is firmly directed towards executive committees. As a practitioner of agility for several years, observing SAFe in an environment transitioning towards agility, I had the opportunity to obtain the SPC (SAFe Program Consultant) certification, and I would like to share my reflections on the subject.
At the outset, it doesn't start too well...
Let's not deny it; SAFe is conceived as a "training toolbox" that bases its business model on deploying its system throughout the organization through training. Following a mechanism similar to classic certifications (Prince, CMMI, 6 sigma, ITIL, etc.), it aims to train the entire organization in its way of thinking, relying on the classic modality of change: a sense of urgency, a radical transformation "in one week," etc. This hegemonic inclination provides a sense of security (or the illusion of security) to transformation stakeholders and a promise of "proven" effectiveness by other major stakeholders. Nobody ever got fired buying IBM. But, apparently, there isn't much agility in all of this!
However, quickly, some pleasant surprises!
My first (pleasant) surprise was to see that my fellow SPC (SAFe Program Consultant) trainees were all (and all for 10% of the cohort) practitioners of agility models on a scale beyond that of the team. I also found that the two English trainers were seasoned SAFe experts with several dozen programs deployed in many European countries. The second pleasant surprise: while the training often refers to the SAFe canvas, designed as a clickable mind map that allows concentrating a large amount of information and concepts on a schema (here), it must also be acknowledged that it relies heavily on the fundamentals of the Agile Manifesto and the deep contributions of Lean Management (Toyota). And Lean-Agile concepts are not there just to look "nice"; they are at the heart of the devices and promises of achieving results. As various training sessions emphasize: without the Lean-Agile foundation, SAFe will not work!
Third pleasant surprise: SAFe takes into account, in large projects, what can be called the "upper floor" of decision-making in a sensible and applicable way. Through the analysis of "value streams" that respond to the needs of customers, stakeholders can easily prioritize features that can be amalgamated into high-level solutions (capabilities). This prioritization system, by and for stakeholders, using the creation of value for the end user as a decision metric, applies equally well at the team level, at the program level, or more broadly at the organizational level. Prioritization (budgetary) is indeed the key challenge of resource distribution, with, in the classic world, top management that "demands" precise predictive studies [thus false in 80% of cases] to make decisions that will constitute a strict [and untenable] roadmap, guaranteeing frustration and mistrust throughout the [slipping] project duration. The agility of SAFe, therefore, relies on the ability to take long-term positions with decisions that are frequently renewed to adapt to market changes. And that's quite agile!
SAFe offers a mix of organization and self-organization of teams by limiting the time impacts of decisions and thus allowing continuous adaptation through learnings in iterations. Of course, like any framework or tool, it can be used with a more or less marked degree of agility or even be misused by limiting its use to keywords that serve as a smokescreen. You gather 6 teams for half a day? And there you go! That's a PI (Program Increment)! We prioritize (but driven by the political issues of stakeholders who don't talk to each other)? And there you go! That's a backlog. We don't follow the SAFe approach? "Well... that's it, being agile is about adapting the rules!" (Sighs...) There is, therefore, a real risk in SAFe; that of adding an unnecessary organizational layer to those that may already be present. Managers become POs but continue to behave like managers; PMs remain project managers, etc. This amounts to applying only the non-binding criteria rather than using the binding criteria to "encourage" (permission/protection) the organization to pivot from budget-driven management to value-driven management. And therefore, missing what I consider to be SAFe's major injunction: "Stop chasing the money, chase the value."
One of the difficulties of the model lies in the necessary training of all actors. In this sense, SAFe comes from across the Atlantic with deployment methods that are culturally applicable there (everyone must be trained before joining the famous "trains"). While in France, things don't always happen that way. Training? But we don't have time; we are already so overwhelmed!
SAFe is a tool that can be used well or poorly (cf. the hammer analogy) and is certainly not the only way to promote the deployment of the lean-agile mindset in an organization. However, I think it would be a mistake to automatically categorize it as a model that hinders the deployment of agile values.
Its main advantage is also its main problem; because it speaks a language understandable by large organizations, it can easily be twisted into a pyramidal system that reproduces organizational difficulties rather than helping to solve them. However, by introducing iteration, prioritization, and delivered value, it gradually introduces the cultural elements that will help organizations renew themselves.
Yes, SAFe can give the illusion of an alternative to a classic process and be used as such. But the frustration it produces can help make the underlying issues visible. And here's already a starting point for a path... whose continuation will (or will not) be in the implementation of agile behaviors: transparency, humility, inspection, courage, focus... And we are no longer dealing with framework questions but with those of values permitted and deployed in the organization.
SAFe? Like other "frameworks," it is only useful if it enables experimentation and the deployment of new regulations that will lead to renewed business dynamics. Therefore, it seems to me that its proper use is that of a framework for learning... which, at the very least, requires that the fundamental challenges of this learning are understood and shared among the actors!
This is not so obvious when we observe the current lack of substance and meaning in so-called agile transformations. The training and posture of agile coaches contribute to this debate... A topic that will probably be the subject of a future post, continuing the reflection initiated on this subject by Christophe Keromen in this excellent article and resonating, among others, with the reference work on coaching by Reine-Marie Halbout, "Savoir être coach".
* personal definition of agile = a global business approach designed for complex environments, focused on creating value for the customer through the emergence of multi-disciplinary and self-organised team practices, with iterative, adaptive and incremental objectives.