Is Agile Still Agile When You Scale it?

By: Dennis van der Spoel

Any company working with more than, say, 80 people on the development of a single product or solution will not manage with just Scrum as a guideline for an agile way of working. Fortunately, several frameworks have been developed to make agile ideas workable in larger companies. Sometimes small concessions have been made to the autonomy of individuals and teams for the sake of coordination. This has led to discussions about what is still agile and which framework should no longer be allowed to wear that predicate. The framework that is most popular and also the most under fire is the Scaled Agile Framework® (SAFe). Is that rightly so?
 
If we look at frameworks such as Nexus, LeSS and especially SAFe, the criticism mainly focuses on the alleged lack of space for people to find their own way of working and the alleged lack of simplicity. Those frameworks have caused this themselves. For example, the SAFe Reference Guide consists of 800 pages, where Scrum fits on just 17 pages.

At first glance, therefore, SAFe seems 40 times more complex than Scrum. But that is not the whole story. It is precisely the lack of 'guidance' that inhibits the adoption of Scrum (and therefore agile) within larger organizations. Scrum does not offer a solution for every context. The idea is that Scrum teams themselves discover an optimal way of working. That works well with a single team. With two or three teams that is often fine too. However, once you really start scaling, cooperation between teams no longer comes naturally. Consultants and coaches, as yours truly, build their entire business model on this issue. But that is not sustainable.
 
Forgive me for the detour that I am about to make in my reasoning. At the end of this article I will come back to the criticism of the most important agile frameworks in general and SAFe in particular.

​Blends

In practice, I often saw that only software development teams adopted an agile way of working, and that organizations need some form of overarching coordination and financially oriented reporting.
 
A practical interim solution arose in the form of a blend of traditional methods to manage projects and an agile way of working within the teams. A familiar blend, which I have often used successfully, is PRINCE2 with Scrum teams. Nowadays there even is a separate PRINCE2 Agile in which this way of working is documented. This means that initially the PRINCE2 roles 'Change Authority' and 'Team Leader' are replaced by the Scrum roles 'Product Owner' and 'Scrum Master' respectively. Later, the role of Senior User is also filled in by the Product Owner, and the role of Senior Supplier is later adopted by the scrum team, including the Scrum Master. We have to make sure that people who play these roles have the necessary mindset and competences. But, PRINCE2 says nothing about how a team should work, so Scrum is fully acceptable in PRINCE2. And voilà, the first step towards an agile way of working has been taken.
 
Agilists often dispose of PRINCE2 as a waterfall method, but that is not correct. PRINCE2 is remarkably agile in principle, but it is often misapplied by organizations that work in a waterfall way. We call that PINO; PRINCE2 In Name Only.
 
Scrum, in combination with a correct view of PRINCE2, possibly supplemented with MSP (Managing Successful Programs) and MoP (Management of Portfolios), can be an excellent intermediate step to introduce agile to larger organizations using a structure that they largely recognize, and which still feels somewhat intuitive. An alternative that I have often tried is AgilePM, possibly supplemented with AgilePgM and AgilePfM. These are DSDM-based (Atern) frameworks of the Agile Business Consortium that largely correspond to the counterparts just discussed.
 
With both intermediate solutions you will sooner or later hit the ceiling. As long as you organize around unique assignments (projects and programs), everything is temporary. This also means that the teams that work on these projects are of a temporary nature. That sooner or later becomes a problem. Teams with a reasonably stable composition will eventually be better attuned to each other. If you then disassemble them when their performance level is at its highest, it will have disastrous consequences for the organization. It becomes more difficult to motivate and retain employees. And there is always the temptation to assign various tasks to employees in addition to their work for the project. In fact, the project work often turns out to be a side-activity to the regular work. That is detrimental to productivity. So, at some point there is a need to tilt the organization and to have products routinely developed by multidisciplinary teams in a fixed composition. Horizontals become verticals and vice versa. Value streams become the new primary organizational units, departments become communities of practice. Thus change becomes business as usual and projects and programs become a thing of the past.

​Permanent Change Framework

This creates the need for a permanent change framework for organizations that have little experience with agile. This explains the growing popularity of frameworks such as Nexus, LeSS, SAFe and Spotify. People who are familiar with agile frameworks primarily see the similarities between these frameworks. People who are less familiar with agile frameworks are easily confused because each framework takes a different angle and uses somewhat different jargon. The core of each framework is predominantly formed by the Agile Manifesto and the Scrum Guide. In order to coordinate several teams, one or more extra coordination layers are usually required, where selected people from the layer below and/or a separate group of people are burdened with these coordination tasks. They perform their coordinating work according to the same agile principles. It’s kind of a scrum team for scrum teams.
 
At every level there is a derivative role of the 'product owner', who prioritizes the work. There is also a 'scrum master' at every level, who safeguards the way of working, makes sure issues are resolved, and facilitates the meetings. In addition, there are, of course, the people who carry out the work for that level.
 
It is easy to scale agile this way and this principle is therefore applied in most frameworks. Most large organizations require two or three levels of a framework. I rarely see organizations that need the most extensive configuration.

​Alignment

The misconception that I sometimes encounter is that there is (or should be) top-down control over what is produced and delivered. It is true that there is a certain degree of alignment, but it is not imposed. Each level periodically passes a prioritized list of requirements to the level below but is aware that this is only a part of the workload that is added to the backlog of the underlying level. Incentives for change come from all directions and from all levels of the organization and beyond. Locally, the ultimate priority is determined independently based on available information. The organization's interests are paramount here. It is logical that the management wants to have a say in the prioritization, but this is done by continuously raising awareness for the product vision and strategic intentions and not by making decisions that are best made at a lower level.
 
When you work with a lot of people together on the same objective, a certain degree of mutual attuning is also needed. Some frameworks opt for fixed moments at which this coordination takes place. This creates a fixed cadence, to which all teams conform. With agilists, this may well encounter resistance, because it is customary for independent teams to determine their own way of working and heartbeat. However, if you work on something with several teams, it is more convenient to run synchronously. For example, after each iteration the integrated product or solution can be tested and demonstrated rather than its separate components. This is particularly important when, in addition to software teams, there are also hardware teams working on the product. Within that cadence teams are largely free to choose their own way of working. It generally does not matter if development teams use Scrum, Kanban or whatever else. Only the integration points and joint planning moments are fixed.

​"Which Framework Should I Choose?"

"Why are there so many different frameworks to make agile scalable?" This is a question I often get, followed by "and which one should I choose?"
 
In the beginning there were no good frameworks for scaling agile. Several teams across the globe started to develop their own practices. Each group documented and codified its own best practices and now wants to monetize their discovery. In doing so, they are competing for a place in the spotlight.
 
Which framework works best for you depends on your situation. Agile purists often find that you have to find and develop your own way of working, and therefore have to stay away from these frameworks. My answer is that it does not matter much, although I have a slight preference for SAFe. I agree, in part, with the purists. A framework provides a reasonable starting point from which you can iteratively develop your own methodology. It prevents you from having to take the path that the first pioneers had to take. They have sometimes experimented for years before they found things that worked best. And they are still experimenting and evolving their framework. By adopting a framework, you can catch up quickly. But never see a framework as a goal in itself or as a final destination. At best, it is a base station at the foot of the mountain. 

​SAFe

Why am I expressing a slight preference for SAFe? I think it is important that a framework offers enough support for my clients. An agile transition is difficult enough. We need all the help we can get. Some frameworks are more extensive than others, and some frameworks are more practical or more organic than others. Many prerequisites for an agile way of working, such as DevOps and Continuous Delivery, are already included in the SAFe framework. This also applies to a number of XP practices for software development. A purist would say that prescribing practices is not agile. My position is that it offers an excellent starting point for developing your own way of working. Without automated testing and deployment, you cannot become agile; so why not include it in your framework?
 
One of the benefits of SAFe over other frameworks are the recurring large-scale two-day planning meetings. At first there will be a lot of resistance against such interventions. “Why plan and coordinate with so many people every quarter? Can't this be done more efficiently?” In my experience, such a joint alignment-effort is many times more effective than coordination through delegation. In a big-room session energy starts flowing and everyone gets the same information firsthand. Questions are answered immediately, and the wisdom of the entire group is used to resolve bottlenecks on the spot and to investigate and mitigate dependencies. Moreover, everyone gets the opportunity to indicate how much confidence they have in the attainability of the goals for the coming period. This creates ownership, if done right.
 
In coordination through delegation, which is the choice of many frameworks, I often see that the envoys move between teams after planning to clarify matters and seek alignment. Also, team members do not always own the plan that they have been committed to by someone else. That does not benefit productivity.

​Framework: Goal or Stepping Stone?

​Ultimately, nothing stands in the way of starting with a random framework and finding your own way of working from there onwards. However, your context is very important for the choice. Compare your context with the context the framework originally evolved in. For example, I would rather opt for the Spotify model when developing a new mobile app or data-driven platform. SAFe, for instance, is designed for situations where firmware, hardware and software need to be integrated into a single solution.
 
“Is it very complicated to learn how to use a framework?” Well, even an extensive framework like SAFe restricts itself to two days of training for most roles. However, the timing of the training and mentoring by experienced coaches and consultants is crucial during the first period, regardless of framework chosen. It is also important that senior management actively participates in the cultural change. Yes, we are starting a culture change. By repeating the new practices endlessly and consistently, new habits and new behavior arise; and with that a new culture (and often a new structure). Expect a lot of resistance in the beginning, especially by those with vested interests in the status quo.
 
Let’s return to the question of whether agile is still agile when you scale it up. It all depends. If you see the framework as a goal in itself and approach implementing it dogmatically, it is contrary to the agile philosophy. If you see the framework as the first step at the start of your journey, then it will certainly pay off.

A Final Word

​This article appeared earlier in print (Dutch) in 'Projectie', magazine for project management of ipma-nl and online at issuu.com with the tags IPMA Nederland - Vakblad Projectie #5 / 22 October, 2018. See below.
 
The full Dutch version can be found here.
 
Dennis van der Spoel Consulting helps organizations to become more agile without chasing hypes. Our firm specializes in the transition to a modern way of working with respect for the existing practices. Direct your questions to us via the contact form on this website.