The Agile Wilderness: Scaling Agile

The conversation about scaling agile is very complex and nuanced. There are several frameworks out there with SAFe becoming the most popular. The key with any scaling framework is to make sure that you are not just following practices and instill an agile mindset throughout the teams. As the framework gets more complicated such as SAFe (1) the less likely that teams can truly be agile and fall back into some of the pitfalls we tried to move away from in waterfall.

In this article I will cover:

• Some common frameworks for scaling agile
• The pitfalls to watch out for while scaling agile
• Using the agile mindset to overcome the pitfalls of scaling agile

Some common frameworks for scaling agile

As larger organizations have brought agile into the frabric of their teams over the last 20 years, many different flavors of implementation have been created. This started with Scrum and Kanban discussed in my last article (2) and expanded into many different scaling frameworks from there. Here are a few of the most common frameworks out there.

SAFe (1) or Scaled Agile Framework created by Dean Leffingwell is the rapidly becoming the most popular. There are many different variations of SAFe including Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe. SAFe is based on overall business agility model including Lean Portfolio Management, Organizational Agility, Continuous Learning Culture, Lean-Agile Leadership, Team and Technical Agility, Agile Product Delivery and Enterprise Solution Delivery.

Scrum@Scale (3) created by Dr. Jeff Sutherland is built on the same fundamental principles of Scrum, Complex Adaptive Systems theory, game theory, and object-oriented technology. Scrum@Scale helps an organization to focus multiple networks of Scrum Teams on prioritized goals. It aims to achieve this by setting up a structure which naturally extends the way a single Scrum Team functions across a network and whose managerial function exists within a minimum viable bureaucracy (MVB). Scrum@Scale separates these components into two cycles: the Scrum Master Cycle (the “how”) and the Product Owner Cycle (the “what”), intersecting at two components and sharing a third. Taken as a whole, these cycles produce a powerful supporting structure for coordinating the efforts of multiple teams along a single path. Scrum of Scrums reduces the number of communication pathways within the organization so that complexity of communication overhead is limited.

LeSS (4) or Large Scale Scrum created by Bas Vodde & Craig Larman. LeSS has two variations to it including LeSS for up to 8 scrum teams and LeSS Huge for up to a few thousand people. Less is Scrum applied to many teams working together on one product. In LeSS all Teams are in a common Sprint to deliver a common shippable product, every Sprint. LeSS takes each concept and ceremony from scrum and varies it to allow it to scale.

FAST (5) or Fluid Scaling Technology. FAST harnesses the same principles from XP programming and creates an organizing force of the self-organization. FAST combines open space and open allocation to create lightweight, simple to understand, and simple to master agile method that scales. I first heard about this framework at Agile 2021 (6). This is a new framework and for those looking to be on the leading edge.

The pitfalls to watch out for while scaling agile

"Scaling agile" that does not pay close attention to pitfalls will most likely result in a cargo cult where people just follow processes mindlessly without considering their purpose or intention.??Outwardly, your transition may be successful - while inwardly, you will be missing the benefits of the adoption.?(7) Some key pitfalls that folks fall into are:

• Siloed teams which are no longer cross functional and able to have something releasable each sprint. Cross-channel communication and working agreements is key to work through this but ultimately can lead to slowing down overall. These teams can begin to have so many dependencies on each other that you loss the agility as an organization to deliver value frequently and have a slow feedback loop to learn and improve.
• As you increase dependencies within an organization, many organizations take more time to plan to increase efficiency while in the same moment creating processes that hurt our ability to deliver value overall. This leads to a feeling of constantly planning and unable to respond to changes.
• Starting to focus more on contracts and less on the people. You can start to see the process taking over instead of the collaboration across people in the organization. These contracts also lead into more documentation that no one is reading taking time away from building working software.
• Keeping all levels of the organization aligned during the change is key and making sure there is a clear WHY communicated to all teams. (8)

Using the agile mindset to overcome the pitfalls of scaling agile

To avoid pitfalls as we scale agile, we need to make sure we continuously go back to the agile manifesto (9) and principles (10) as we look to implement practices on our teams.

1.??Individuals and interactions over process and tools. As you scale, some organizations begin to let process and tools drive rather than allow the people within their organization collaborate to come up with the best way for them to interact. Specifically looking at how we communicate with each other and in the end show trust with one another. Once we focus on process over how we treat each other, our trust begins to break down and our ability to execute on complex and innovative initiatives becomes more difficult and we may be tempted to go back to strict processes to remove interactions.

2.??Working software over comprehensive documentation. As you scale, some organizations begin to focus more on documentation than getting working software to their customers. Many times, this stems from issues or bugs that continue to arise due to crunched timelines or lack of review by the proper folks. This then leads to creating more documentation which makes the process take longer and again leads back to less working software being built. This becomes complex as an organization grows and you must find the right balance of making progress while collaborating with your business partners on a regular basis to make sure you are on the right path.

3.??Customer collaboration over contract negotiation. As you scale, some organizations begin to fall back into making contracts across teams. Ours teams usually become less cross-functional and begin to have more dependencies across teams to get working software/ value out to our customers. Specifically looking at how often we are delivering working software, how sustainable is the pace of the team, and how our teams are being organized can we good indicators. The team size and the dependencies across teams are things to keep in mind. As we break out teams more to gain efficiency, we may loss overall ability of teams to deliver. The clearest example of this recently being confronted has been around DevOps and if the people with these skills are part of your agile team or part of a separate team.

4.??Responding to change over following a plan. As you scale, some organizations begin to fall back into very large planning sessions that are usually very ineffective and do not allow us to respond to changes as we get into the work. Specifically looking at how we respond to changes in requirements, how often we are delivering working software and how often we are meeting with the business can be good indicators. How much control an organization wants to have and how much we trust our teams to get the job done are things to keep in mind. As we look to control all the moving pieces within a large organization, the less flexibility our teams must deliver working software and in the end delivery value back to the organization.

As you look at the manifesto and principles, some claim that they do not scale. (11) Instead of creating gates, approvals, and management layers, we can choose to descale our organization. This means we have truly cross-functional teams that can deliver features autonomously with a single product owner making decisions. These teams should be long-lived with quality and operations as an integral part instead of resource pools. This also means development stops when the product in no longer valuable.?

Closing

Scaling agile is very complicated and there are a lot of various ideas out there on the proper way to do it. I have found through my experience that each team and organization is different and has different needs. It is important to evaluate the agile mindset and principles as you scale and bring in practices from the scaled frameworks with caution for the pitfalls and a focus back to the mindset and principles. At times a large change may be needed through the organization so make sure you you start small and learn as you go.

As you can see through this discussion, it is important to continue to strive to improve and collaborate across an organization. In my next article I will talk about products vs. projects and the ideas I have been diving into with product management.

About the Author

Jeff Mortimer?(#theAgileMoose) is an Agile Enthusiast with over 10+ years of experience working in various roles on agile teams including business analysis, product owner, scrum master, team leader, and now a technical delivery manager. In additional to his certifications in CBAP, AAC, and A-CSPO, Jeff?has presented at several conferences throughout North America and joined the blogger universe a couple years ago to bring a voice to the everyday agile practitioners. He is currently working on an EMBA with Quantics School of Business and Technology. He is a husband to an amazing and intelligent wife who has her doctorate in math education, father to kids who bring him joy every day, friend that brews beer and plays soccer, and citizen who helps organize volunteers to give back to the community.

Follow #theAgileMoose for the latest insights in the agile wilderness.

References:

(1) SAFe

(2) The Agile Wilderness: Scrum vs. Kanban

(3) Scrum@Scale

(4) LeSS

(5) FAST Agile

(6) Agile Alliance - Agile 2021 Conference

(7) Failfastmoveon - 5 pitfalls when scaling agile

(8) Aspirent - Five common pitfalls when scaling agile

(9) Agile Manifesto

(10) Agile Princinples