The Long Con of Scaled Agile
Since the start of the industrial revolution in the 18th century, standard approach to increasing the efficiency and profitability of business has been to standardize and automate systems and processes.
Standardization and automation are pretty good tools, particularly for mechanical processes. But once you start looking at knowledge work and professional practices, it becomes much more challenging to determine what can be standardized and automated.
Computers and software have been growth industries precisely because they have allowed for the automation of processes that were once only in the domain of people. The knowledge processes that are automated with technology are only automated retrospectively.
Innovation is still solidly in the domain of human beings, and likely will be for some time to come. Any knowledge process that is automated with technology has to first be innovated and developed by someone. Only after someone has developed a standard process that's been shown to be effective, can someone else develop the software to automate it.
Agile Manifesto
The real value is in the innovation. The faster you can innovate, standardize, and develop, the more value you can create to drive growth and profits.
Focusing on just this issue, accelerating technological solution development, a group of colleagues published the Agile Manifesto in 2001. Along with the manifesto were 12 principles that are ensconced in a number of development processes such as Scrum and Kanban.
Of course, agile sounds great, as does digital transformation. What company would want to be agile and transformative? And there has been no shortage of consultants and billable hours to assist companies in becoming agile.
Scaled Agile, etc.
Scaled Agile, along with a number of other organizations touting the ability to assist companies with their digital transformation, has outlined a process that nominally aligns an organization with the goals of the agile process that focuses on small teams.
The idea that there should be a standardized process to implement agile at scale should be seen as ironic given that the agile manifesto asserts "Individuals and interactions over processes and tools."
Additionally, using an agile process doesn't actually make you agile. Agility is in the results not the process. You can be 100% waterfall with two week sprints and stand-up every morning. If you're not delivering incremental, but functional, solutions to customers on short timescales, you're not agile.
If your small teams actually are agile, and they are innovating and delivering solutions, then the process rarely has an issue with scaling.
Innovation, Talent, and Results
Before companies start down the process and expenditure of an enterprise agile process, they should really ask, have we successfully implemented agile at any scale.
Maybe out somewhere is a company with 20 or more scrum teams delivering new results to customers every couple of sprints, but somehow this isn't working for the organization as a whole, but I've never seen one, or read about one for that matter.
What I have seen and read a lot, are companies with 20 or more scrum teams that can't ship anything reliably, even on a quarterly basis, and a business that doesn't understand why they aren't delivering more to their customers. Then when you look at why those teams aren't delivering, you find all the typical problems: low interaction with customers, unclear objectives, lack of organizational strategy, and the inability to make decisions and self-direct.
If an organization cannot facilitate the activities that allow a small team to innovate, they will not innovate at scale, regardless of the money spent on process consulting.
Ultimately, innovation is driven by talented people who are given the agency to solve problems and deliver solutions, and there is no process that can create agency or replace talent.
It is yet another in a long list of business process ideas that assert they can solve inductive problems with a deductive process.