Contributing Writer: Aaron Roberts
Adopting the principles and practices of agile is a proven way to predictably deliver projects, but what about at scale? What works for a group of 5-7 does not automatically translate to enterprise organizations. Fortunately, there are established approaches and frameworks for scaling agile. You’ve probably heard of some (Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), Disciplined Agile, and more). These frameworks offer a good starting point for implementing agile practices across more than one team and provide excellent guidance on the scaling journey.
Regardless of the framework chosen and the specific details of how it is implemented in your particular organization, what is perhaps most important is the understanding of why Scrum works, and how to avoid losing those benefits as you scale.
Benefits of Scaling Agile
Large companies solve large, complex problems. And with lots of people working on the same or similar problems, there’s a need to organize and coordinate activities. Often enterprise organizations have multiple lines of software products. Commonly, these products share infrastructure, knowledgeable resources, support teams, and therefore compete for prioritization. This widespread setup is especially true for companies that organize departments and teams by competency (i.e., security or DevOps as a central department) vs. those who distribute capabilities within autonomous teams.
The true reasons for scaling agile reliably comes down to a few key drivers:
- Organization-level prioritization and distribution of the work
- Continuous alignment across distributed teams
- Efficient dependency management
Organization-Level Prioritization
Organization-level prioritization means that the organization can effectively compare, rank, and assign initiatives to maximize value. To do this, organizations need multiple teams working in tandem on the same products, which naturally leads to continuous alignment. From there, the work should go to the best team suited to deliver, which is generally the team with the product owner most familiar with the market and/or product needs.
Continuous Alignment Across Distributed Teams
In addition to prioritization from the “top”, a scaled agile approach means a shared vision of success, coupled with a path to it, across the entire enterprise. In order to achieve effective alignment, the organization must distill and distribute vision on a regular cadence. This ensures all individuals and teams are effectively “rowing in the same direction”, thus reducing silos of information and misalignment, and ultimately providing the organization the most flexibility possible to respond to market needs and conditions quickly.
Efficient Dependency Management
Perhaps the most important benefit is an organization’s ability to efficiently manage dependencies. Often companies centralize skills into competency-based teams. There are pros and cons to this, with the pros being clear prioritization, workload management, and assurance in quality. This is especially true for DevOps and deployment. However, the challenge is an increased amount of cross-team dependencies and therefore a heightened need for reliable cross-team communication.
So what’s the solution? How can a company extend the value of team-level Scrum practice across its entire enterprise?
Why Not Just Increase Team Size?
Scrum, as a team-level practice, is at its core a social engineering frameword that works for a couple of key reasons. First and foremost, it forces constant communication and transparency into the process. And second, it establishes a cadence for ruthless prioritization.
A seemingly simple solution is adding to the team size. But, this should be done with caution. There’s a limit to the effectiveness of the daily ceremony communication, a point of diminishing return. As with any interactive meeting, the quality diminishes with more people added.
Generally, team-level Scrum works best when following the “two-pizza” rule, specifically limiting a team to no larger than the number that can be fed with two pizzas – approximately seven individuals. Beyond this, meetings tend to run too long, transparency into task ownership is clouded, and the effectiveness of communication dwindles. Simply put, making your team bigger doesn’t solve problems.
Which Scaling Model to Choose?
Fortunately, there are several models and frameworks designed for scaling agile. Some more popular ones include:
There is no need to go into detail about these approaches. Why? Because in the end, it simply doesn’t matter.
Surprised? Well, here’s a little secret – all of these frameworks work. None are perfect, and none are terrible. Each essentially solves the same set of problems, diverging mildly in how the problems are solved. Each methodology has its fans and all have been implemented successfully by numerous agile teams. This is because it’s not WHICH framework you choose that matters, but rather HOW well it’s implemented.
Furthermore, many organizations select from one or many frameworks and integrate them into their organization’s processes, versus rigidly adhering to any one framework.
Rather than asking which framework to adopt, instead, focus on what the success factors are of each of the following core agile principles.
Core Principles of Successfully Scaling Agile
Regardless of your chosen framework, each methodology adheres to five key agile principles:
- Entrust a chief product vision holder
- Organize teams around domains
- Adhere to the Scrum fundamentals
- Slice vertically
- Coordinate and align on a plan
Chief Product Visionary
Having one chief business vision holder (or chief product owner, lead strategist – the title is not important here) is critical for several reasons. First and foremost, decision making for the direction, prioritization, and cutting of features cannot be effective without “absolute ownership”. There must be a single, accountable, responsible owner for making product decisions. This does not mean other minds in the organization should not be tapped, but it does mean that one person is accountable for the following:
- Maintaining one unified product backlog, including the prioritization of work and initiatives, regardless of which team is executing
- Being a tiebreaker in times of priority gridlock
- Communicating the big picture vision on cadence to keep everyone aligned to the same goal
Just as a team-level product owner (PO) prioritizes a team’s backlog into incremental deliverable slices to maximize value delivery, it’s imperative that this concept happens at all levels of prioritization. With an absolute owner of business prioritization in place, an organization can avoid decision gridlock, duplication of work, and the common pitfall of making some progress on many initiatives, but not actually completing any.
Organize Teams Around Domains
Another key to success lies in how teams are organized. While exceptions exist, for maximum reliability it’s best practice to organize your team around domains, or product knowledge centers versus other options like technology or skillset. There are two components to this strategy.
First, this ensures true domain expertise within the team. Of course, not all team members are going to be domain experts, but it’s critical that the product owners are, and that they are the anchor of the team. This ensures that the guiding star of each team is based in true customer-focused expertise. Embedding a knowledgeable representative at the team level, who can speak to the true priorities of the customer, sets the team up for success because it diminishes the distractions of technology and approach.
Furthermore, by having this market-based perspective embedded, it is easy to ensure that the “next most important thing” from a product capability standpoint remains the goal at all times. This avoids the ever-so-enticing pitfalls of building more than you need before you need it, or picking off backlog items that are easier versus more valuable.
Additionally, the domain-based organization empowers teams. With a critical focus on the customer, each team is fully empowered to do everything needed to deliver the software to the customer, i.e. design, provision tooling and infrastructure, and software deployment. Thus, a team organized by domain experience minimizes dependencies while maximizing effectiveness.
The concept of immunizing cross-team dependencies to gain efficiency is simple enough, so it’s important to take a hard look at the responsibilities of each group. If you have a UI team, a deployment team, and a database team—and because of the arrangement there are ample cross-team dependencies—then it’s worth taking a look at redistribution to maximize communication and efficiency.
Scrum Fundamentals
Scaling agile ultimately results in additional meetings/ceremonies, exposure to more than your team is working on, and a heightened need for cross-team dependency for delivery. In this environment, it’s easy for basic fundamentals to slip. For example, if 3 or 4 teams are working on one large initiative, it might not seem imperative to deliver a working, potentially shippable increment early on. Doing so may feel like overhead for the sake of process, versus what a team may view as more valuable progress as they await other components from other teams.
But this is not just a slippery slope, it’s detrimental to the core principles of agile which guarantee business flexibility. Each and every sprint must produce a demonstrable, shippable product. Without this, predictability and reliability go out the window.
In addition, the social engineering portion of Scrum cannot dwindle. Even though additional communication is needed across development teams and at the organization level, team-level communication and ceremonies are still every bit as important to maintain.
If your team cannot rigorously and consistently adhere to the basic Scrum principles that bring so much success, a team of teams will likewise suffer a magnified lack of this success.
Slice Vertically
A critical concept for success is tied to an organization-level backlog. The “backlog” at any level of the organization should look similar in structure. Specifically, it should be composed of vertical slices. This is true at the theme level, the product line level, the product or feature level, and then, of course, the team level execution stories. By maintaining vertical slicing all the way up through the organization, the same benefits the organization gleans at the team-level – namely flexibility, acceleration of risk and early uncovering of unknowns, ability to pivot with market pressure, and the ability to release on demand – trickle up. Maintaining the same MVP, incremental thinking at all levels of strategic planning ensures a nimble position.
Coordinate
Clear, structured, and on-cadence coordination is a cornerstone of agile, both at the team level and at scale. At scale, there are significantly more coordination points. Specifically, there’s a need for future/look-ahead planning, inter-team dependency, status and progress updates, setback impacts, and go-to-market readiness coordination activities. A solid scaling approach will address each of these coordination needs, ensuring that there’s consistency in the plan, approach, the groundwork for reactionary measures, and reduction in time to market.
There are a few implementation techniques that enhance coordination, such as feature toggles, flags and systems for release activity planning, and automation tooling. Ultimately, organizations should invest in items that make these coordination activities efficient, as they positively impact time to market.
Summary
Agile at scale is not much different than agile at the team level. Simple Scrum frameworks, either off the shelf, or pieced together from best practices, solve the basic needs for scaling: organization-level prioritization and distribution of the work, continuous alignment across distributed teams, and efficient dependency management. With an approach in place for each of these needs, specifically one that maintains the principles of Scrum, enterprise organizations can effectively scale the team-level success to their entire operation.
Are you struggling with your scaling of agile? Feel free to reach out to Ascendle for help.
