Scaling – The lean and agile approach

When learning about the SAFe methodology one might come to a conclusion that in order to achieve agility in large organizations there is a need to add roles, artifacts, processes, etc. Recently the SAFe institute even published the “SAFe essentials” trying to answer the question “What is the minimum subset of practices beyond which SAFe isn’t safe?” and feel free to read it yourself and judge. I would say that the list is far from being minimal.

The common reasoning behind this approach is that the bigger the organization is, the more complex it becomes to effectively align the entire organization towards a shared goal.

And indeed it is hard. Very hard. And complex.

Based on my understanding SAFe suggest a solution that is based on the assumption that if something is difficult, we need to have a pre-defined role or process to make sure that the problem is being addressed. Even before we have encountered the problem.
For some, this is indeed a valid approach, however it is not lean, definitely not agile and it goes against the basics of systems thinking.
Below are a few examples to make my point.

Why is SAFe not Lean enough?

Let’s go back in time to the year 1911: This is the year when fredrick taylor coined the term “scientific management”. This theory is targeted at increasing organization’s effectiveness assuming (amongst other ideas) that in order to maximize the potential of the organization, the managers need to focus on planning and decision making, while the “regular” employees need to focus on performing their tasks efficiently.
At the time this theory probably made a lot of sense and resulted in more effective organizations. It is important to notice that at the time, most organizations were lo-tech, assembly line type of organizations in which many of the employees were ignorant, lacked proper education and basic skills. Luckily we are now at 2016.

Toyota, the originator of the lean approach, states that there are two pillars that hold the entire lean structure: “Continuous improvement” and “respect for people”.
Let’s examine the “respect for people” pillar: it means for example that teams and individuals are encouraged to design and use their own practices and processes in order to deliver high quality results. This concept is also reflected in the agile manifesto’s first value – “Individual and interactions over processes and tools”.

What SAFe chose to do is to have a fair amount of pre-defined processes and roles.
In my opinion this is not only disrespectful and undermines people’s ability to design and control their own work, it also clearly goes against the lean concept of Kaizen, and one of its practices which is eliminating waste and specifically over-burden waste and over-processing waste. (see types of waste)

So. SAFe is not lean enough.

Why is SAFe not Agile enough?

Let’s examine principle number 1 from the agile manifesto “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.
Given that this is indeed our highest priority, why would we ever prescribe in any agile framework a mechanism aimed at optimizing inter-team technical integration?
Why would we prescribe at least 2 dedicated roles that supervise (the guide uses the word facilitate – but give me a break…) this integration work?

Here is a nice example: One of the responsibilities of the RTE (SAFe’s Release train engineer) is to “provide input on resourcing to address critical bottlenecks”, what does that lead us to think?
That resourcing is the typical way of overcoming bottlenecks? (Hint: the answer is no) Even more troubling is that this person(s) is by definition a bottleneck. How could that person overcome herself?

Principle no. 4 of the agile manifesto claims that “Business people and developers must work together daily throughout the project”. Well how does that work in SAFe exactly? based on what i read, each team has a backlog, and a product owner, which is not the “business people”, it is a team member that is responsible for prioritizing the backlog?! In addition we have the product managers which are responsible for identifying the customer needs but does not seem to have the ability to collaborate with the teams. I could not find any statement in the SAFe guide about teams actually working with the customer 🙁

Principle no. 9 encourages us to use simplicity whenever possible, and SAFe… well….

So. SAFe is not Agile enough.

Why do i think LeSS is preferable?

Primarily because LeSS assumes less, it is leaner and thinner and encourages the organization to think more, to experiment and to build a solution that is focused on the big picture and is found empirically suitable for the specific realities and challenges this specific organization has.
This means that organizations that decide to adopt the LeSS framework demonstrate real commitment, buy-in and attention to doing so, which are anyway prerequisites for succeeding with a large scale agility endeavor. Adopting a prescribed solution in a complex environment is simply not good enough.

I am not trying to claim that LeSS framework is the silver bullet or even anything remotely similar to that.
LeSS (just like Scrum btw) tries to find the balance between a defined framework and contextual practices while remaining lean and agile, focusing on principles and experimentation.

So after implementing LeSS, will the organization stop using “quick fixes” to solve systematic issues?
Probably not. Yet these will not be “supported” by the framework, and until solving them for real, the framework will surface those quick fixes and the problems they create so they echo. They will keep bothering us as a reminder that the problems that these quick fixes are meant to overcome need to be addressed at their root.

I would like to invite you to learn more about LeSS, either in one of our upcoming “certified LeSS practitioner” training or in other places.

As always: May the force be with you.

Share on print
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email