Practical Ideas for Scaling Agile
If you work in a large organization and have the need for teams of teams to work in an agile way, you’re going to need some way to scale agile processes. As an agile coach, I feel the need to remind people that we should step back and ask ourselves what problems we’re solving first. (Blindly adhering to any framework is generally not a good idea, in my opinion.) There are many options in terms of how to scale agile, but let’s first identify WHY we need to do it in the first place.
Large Body of Work Needing Multiple Teams
Most obviously, some products or collections of work require more than one team. So scaling the process here simply involves the coordination of multiple teams working together sharing a backlog, addressing dependencies and risks, and working together as a team of teams to deliver value to customers.
There are three frameworks that I recommend to solve this particular problem of multiple teams collaborating: Large Scale Scrum (LeSS), Nexus, and PI Planning (from SAFe). There are, of course, many other ways to scale. (See Willem-Jan Ageling’s article “Assessment of 6 Approaches to Scale Scrum” for more and the additional references at the bottom of this article)
Large Scale Scrum and Nexus are perfectly viable solutions should you have a reasonable number of teams and, very importantly, are able to create one comprehensive and centralized backlog for the product. Furthermore, your teams should have some level of capability in test driven development, automation, and continuous integration in order to maximize the impact of having multiple teams working together to produce coordinated value every sprint. This can be a very big stumbling block for large organizations still early in their path to maturity.
Some organizations that have a challenge creating one backlog will find they are not, in fact, working on one product with multiple teams but instead a slightly-related portfolio of products, components, and platforms. In this case, one should examine more closely why they are scaling and whether there are actual dependencies on the product-related work. Organizational complexity often masks the true reason for dependencies. They may find there is less reason to force the scaling challenges of working as one large team and some teams may be able to operate more independently on their separate products, components or platforms with a less formal way of collaborating ad hoc.
For this reason of masked complexity, I quite like the approach of using a Product Increment approach over 12 weeks as described by PI Planning in SAFe. (Yes, I use the term Product Increment because it feels more agile than the clumsily named Program Increment that SAFe uses.) This scaling approach allows each team to have their own backlog and act independently, which is often how transformations evolve organically, but still forces some scaling concepts and structure that helps teams collaborate, plan, identify dependencies and risks, and ultimately deliver value to customers as a collective group on a larger time scale. And should an organization have the capability to deliver value to customers after every sprint, even better. But, PI Planning allows for some flexibility here.
The differences between frameworks to pay attention to are how Product Owner and Scrum Master roles change slightly and in crafting an appropriate leadership team for the team of teams in PI Planning to help coordinate and guide the process. Generally, the PO and SM roles likely need to be stronger, more mature individuals in order to handle the scope and breadth of scaling frameworks like LeSS and Nexus, whereas in PI Planning some of that is offset by the servant leadership roles supporting the team of teams.
What About Kanban?
You may notice that most scaling articles and advice centers on Scrum, because well, Scrum is defined as a single-team focused framework. When Klaus Leopold, renowned Kanban pioneer, was asked about scaling Kanban he explained, “Scalability is an inherent part of Kanban and therefore one cannot scale Kanban. Scaling in a Kanban context means: Doing more Kanban.”
That said, there are some fantastic perspectives on how to “do more kanban” by, for example, applying Kanban principles at different layers of the organization (sometimes called Portfolio Kanban or Enterprise Kanban). I love how Fin Goulding describes how to utilize an Executive Portfolio Wall to apply agile principles and create flow when working to wrangle transformational complexity. (Watch “Flow: Taking Agile Forward”)
Aligning Company Objectives
Scaling, when done well, also involves the alignment of work across multiple teams to an overarching strategy, often connected to some sort of executive level vision, roadmap, or set of quarterly objectives. We need additional process here to help a large number of teams to work in a collaborative way on the right strategic items in a meaningful way. This set of overarching priorities will complement and need to be integrated with whatever team level scaling processes you adopt. (i.e. strategic inputs from business sponsor stakeholders)
I strongly recommend Objectives and Key Results (OKRs) to create this kind of alignment between executive or organizational division level plans and the teams doing the work. And while you may augment or create additional clarity through the use of outcome-oriented product roadmaps (See Teresa Torres, inventor of “Now Next Later” product roadmaps and her Continuous Discovery TED Talk), I believe the strongest way to create strategic alignment from the highest level of the organization to individual team members is through using cascading OKRs. The company defines OKRs at the highest level then each division and each team of teams beneath that craft their own OKRs for how their portion of the company will fulfull those strategic objectives. A team of teams will then align the epics and stories of their work to move the needle on these strategic imperatives. This way, every single person in the company knows how they are connected to the strategic goals of the company!
Learn about the power of OKRs in this TED Talk by John Doerr, author of the book Measure What Matters.
Consider Your Philosophy About Scaling
Again, instead of blindly following a framework, I believe it is important to think about the reasons why we scale and what problems we’re trying to solve. This thought process, will help an organization develop some guiding principles and values to follow to help them navigate the mirky waters of scaling people, process, and technology alongside their organizational complexity.
As a starting point, I strongly suggest reading the Scaling Manifesto (by Paul Boos, Andrew Jarding, Dane Weber, et al). This is a simple set of values, much like the original agile manifesto, to help create some clarity around how to make trade-off decisions and where the greater purpose lies. For example, one of the values of the Scaling Manifesto says to build “Shared vision over aligned processes”; in other words be true to your company’s purpose and don’t let building the perfect processes get in the way of that. Similarly, it says to focus on a “High performing organization over high performing teams” which may seem counter-intuitive, but when forced to choose, we should always favor what is “good for the company”, even if it means making sacrificies at the individual team level.
There are of course many other reasons you may need to scale. What I hope you will do in your learning journey is to step back and think about what problems you are solving before you apply process changes. The answer, in my opinion, is always to find the path with the least amount of process to solve the problem adequately, so you can focus on the real work of delivering value to your customers and iterate from there.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
