Scaling Scrum: Considerations When Getting Started
It’s been a while since Part 1 of this blog series was published. The second blog has been far more challenging to pull together in terms of what I feel is most valuable for you to read. It started out as a random collection of thoughts on scaling from a couple of different coaches, morphed into a change management approach to scaling (which I may still publish in some form) and ended up as the version you’re reading now.
Why is it that capturing my thoughts about starting a scaling initiative is so challenging? After all, I’ve been a participant in and have guided organizations through multiple scaling initiatives over the years. I’ve tried it all, starting with learn-as-you-go approaches before formal scaling frameworks were established, then determining how to apply formal scaling frameworks in context, and now to developing my own approach to guiding organizations through this type of change. My difficulty with getting started on the “getting started” blog simply highlights the complexity of starting a scaling initiative.
The other challenge that contributed to my writer’s block on this topic is what to focus on. I want this blog to be useful to you and yet focused, so as not to overwhelm. My intention isn’t to write the next book on scaling Scrum, although maybe I should keep that in mind for another time? But, I digress... let’s get started!
Considerations When Getting Started with Scaling Scrum
Some factors for organizations to consider when scaling Scrum, which often determine the level of effectiveness of their scaling initiative are:
Moving from Project-centric to Product-centric
Scaling the Product Owner Role
Team Structure
Middle Managers
These considerations aren’t meant to be in any particular order as some may be more critical for the context and maturity of your organization than others. This is also not an exhaustive list, but captures what I have learned about the complexity of scaling Scrum across an enterprise.
From Projects to Products
For decades, work has been accomplished and success measured within the context of projects with a defined cost, duration and team membership. Upfront planning is intended to remove the risks associated with the project and tasks are assumed to occur linearly and sequentially. Projects often progress through defined phases (design, build, test, deploy) and the team disbands once the project is delivered. This mechanism of delivery has served us well in the context of well-known and well-understood work in a slow changing environment. Projects are still useful today in some contexts, but are no longer the best approach in fast-paced, customer-centric environments.
Enter the product. In the product world, teams are no longer formed and disbanded based on a single large deliverable, but exist in perpetuity until such time that the product they create and maintain ceases to exist. When creating product teams, organizations need to be prepared to fund the team for the life of the product, from inception through to sunset. Product teams are meant to focus on the customer needs and are designed to be better equipped to adapt to changing conditions (market, customer, competitors, regulatory, etc.).
The challenge here for organizations scaling their Scrum implementation is evolving their perception of need:
From command and control to decentralized decision making
From removing risk and uncertainty to adapting based on continuous learning
From a defined scope to an emergent scope
From a single point of coordination to cross-team collaboration
From funding deliverables to funding outcomes
Scaling the Product Owner Role
One of the key characteristics of teams and organizations that do Scrum well is the degree to which they create effective product organizations. By “product organization” I mean the combination of the Product Owner role itself, the division of product management and product ownership responsibilities across team members, and maintenance of a healthy product backlog.
One of the first areas that I work on with Scrum teams is ensuring that they have a healthy product backlog as defined by the acronym, “DEEP”. This concept of making the product backlog DEEP was first coined by Mike Cohn and Roman Pichler and describes a healthy product backlog as: Detailed appropriately, Estimated, Emergent, and Prioritized.
The product backlog is the main artifact of communication and collaboration between the Scrum team and their customers and users. It’s the place where needs are discussed, ideas are shared and innovations emerge. Without a healthy product backlog, teams will flounder and deliver products that often don’t meet their customer’s needs - and I’m only talking about one-team Scrum here. Scaling your Scrum implementation often requires multiple teams working off of a single (and the same) product backlog, which can be a difficult task - especially if the product backlog starts out in an unhealthy state.
Which leads me to my second point about scaling the Product Owner role and about which I made a big assumption in my previous paragraph about needing a healthy product backlog before scaling Scrum. Namely, that there is one product backlog per product. As many teams as are needed on a particular product work off of that same product backlog. Sure, there might be different ways to slice and dice that product backlog to give each of the teams a clear view into the part of the product they’re contributing to, but at the end of the day, there is one single prioritized list that the teams use to turn ideas into valuable working products.
“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”
Are you with me so far? The big implication of having a single product backlog per product is that there is also a single Product Owner per product. Product Owners in one-team Scrum with multiple products for one person often feel overwhelmed with all that they have to do: keep customers happy, maintain a pulse on the market, and keep their team focused and on-track. How then, would a single Product Owner be able to do all of that while working with multiple teams off of a single product backlog?
Maintaining focus on the product and customer is critical to effectively scaling Scrum. Whole-product focus prevents sub-optimizing for team output and maintains the view of only an integrated product providing value to customers. What is the key to achieving this whole-product focus, you ask? One Product Owner with a single product backlog per product. Customer-focus is achieved when the Product Owner acts as a connector of teams to customers and users, instead of operating as an intermediary between the two. This frees up the Product Owner to take on more of the outward (market and client) facing activities, while the teams collaborate with their actual customers/users on the product.
Team Structure
There are two main influences that I lean on in determining proper team structure when scaling Scrum:
The agile world has long promoted feature teams over component teams as feature teams are best suited for maintaining focus on delivering a complete product to their customers/users. However, component teams are often still necessary in every product development organization. “Team Topologies”, written by Matthew Skelton and Manuel Pais provides a set of four patterns for team structure, “topologies”, that are necessary for effectively scaling product development efforts in the enterprise.
According to Skelton and Pais, the first topology is stream-aligned teams, which most closely resembles feature teams. The goal of the stream-aligned team is to “deliver customer or user value as quickly, safely, and independently as possible…” Stream-aligned teams are focused on a single continuous flow of work, whether that’s a product or service, a feature, a persona, or customer or market segment. Stream-aligned teams are the primary team structure leveraged in product development organizations.
The second topology for team structure is that of the enabling team, whose primary purpose is to develop missing capabilities needed in the stream-aligned teams. This may be accomplished through learning and teaching new concepts or technologies, research, hiring, etc.
The last two team topologies described by Skelton and Pais are complicated-subsystem teams and platform teams. The purpose of both complicated-subsystem and platform teams is to reduce the cognitive load on stream-aligned teams. Complicated-subsystem teams are formed when highly specialized knowledge is required for delivering part of a product or service. Platform teams are best used to provide “...easy-to-consume services...to enable stream-aligned teams to deliver work with substantial autonomy.”
Generally speaking, create the bulk of your product development teams according to the feature/stream-aligned patterns and leverage complicated-subsystem teams and platform teams to the degree necessary to reduce the cognitive load on feature/stream-aligned teams and support their autonomy. Remember to maintain focus on learning and incorporating new concepts and technologies into your products by sprinkling in enabling teams where necessary.
Middle Management
The considerations described in this blog are as applicable to one-team Scrum as to a scaled implementation of Scrum. And…the potential impact of these considerations increases when scaling. The role of middle management is no different. In initial Scrum implementations, middle managers are often caught in the lurch as their authority and perceived value are diminished with the emergence of self-managing teams. “If the teams are able to lead themselves, what value do I provide?” is a common question (stated or otherwise) that haunts middle managers.
Middle managers move from:
Directing work and managing schedules to removing impediments outside the team’s control
Managing performance to growing team member capabilities through coaching
To successfully make this shift, it is imperative that organizations provide sufficient coaching, training and time for leaders to adjust. Middle managers may now find their value in forming and/or leading communities of practice aimed at sharing knowledge and building team member capabilities within their specialty. Removing organizational impediments is another area where middle managers can contribute, thus optimizing outcomes in the delivery of the organization’s value streams.
My co-founder, Erkan Kadir often says that, “All leaders in an agile organization are asked to show up coach-like”. Middle managers are no different and can increase their positive impact by providing more coaching and less directing of the team members they support. Coaching grows the capability of the team to find creative solutions to addressing client needs and solving other problems that arise in the midst of product development. Together, teams and their leaders partner in looking at challenges and providing space for thinking and questioning. Coaching takes more time and is difficult at first for managers used to providing answers, but grows the capabilities of the team and organization significantly in the long-run.
Conclusion
There are many considerations that organizations need to look at when scaling Scrum - only a few of which are discussed here. It is likely that you’ll run into some of these and many others but be assured that you have tools to overcome them. Follow the principles discussed above with your context in mind and realize value from your scaling initiative sooner.
Check out the third blog in this series as we discuss scaling Scrum as just another change initiative.
References
Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais
DEEP Product Backlog image from: https://www.visual-paradigm.com/scrum/what-is-deep-in-agile-product-backlog/