“Simplicity -- the art of maximizing the amount of work not done -- is essential.”

Agile Manifesto

In its original form, agile was built for speed and not scale. Simplicity is a key driver of speed, which is why the above statement appears in the Agile Manifesto. Small teams delivering limited batches of functionality — unencumbered by a lot of rules and processes — are capable of achieving great things. But as the popularity of agile has grown, organizations are using it to execute larger, more complex projects. This changes the whole “small and simple” dynamic — which is where scaled agile comes in.

Pure agile works best in teams comprised of 5-9 members. Staying small and keeping things simple allows for quick decisions and seamless communications across the team. But as project size and complexity grows, the natural tendency is to increase team size, add more of them, or both. Doing so requires coordination to ensure that the teams are kept in sync. That often takes the form of the dreaded “M” word…management. It also creates what Ken Sutherland, one of the founders of agile, calls “decision latency.” This can be defined as time wasted waiting on decisions, which is a productivity killer for teams. The challenge: how can agile be tweaked to achieve scalability while still maintaining its core value proposition? 

What Is Scaled Agile?

Scaled agile or “agile at scale” is a systematic framework to facilitate big agile implementation. The intent is to provide just the right amount of structure and governance necessary to facilitate larger teams working on complex projects. Too little could result in a free-for-all, but too much can reduce the primary benefit of agile: speed. Striking this balance is very important.

In a recent study about the state of application development, 57 percent of respondents with senior IT responsibilities said that the speed of application delivery was a KPI for their IT organization. Sixty percent indicated that their organization had primarily invested in agile to speed up application delivery. The key takeaway is that delivery speed is critical, and agile is seen as the key to achieving it. While structure is important, this cannot be at the expense of speed.

At the heart of any scaled agile program is the concept of “scrum-of-scrums”. The idea is that, in addition to the processes and activities agile teams already do, there are additional tasks added with the sole purpose of bringing separate teams together to resolve overlapping issues. For example, practically all scrum teams conduct daily stand-up meetings to address issues within the team. Having an additional scrum-of-scrums meeting to pull representatives from multiple teams together to discuss points of integration can be a really good thing.

One potential objection to using a framework is that the application of agile is no longer self-governing. This does not need to be the case. Scrum-of-scrum meetings are usually done with existing team members and minimal extra effort. In that sense, it can be viewed as a logical extension to agile. For a small setting (2-3 teams, moderate complexity), this may be all that is needed to ensure inter-team coordination and communication. It gives stakeholders an opportunity to learn about potential issues early so they can take action before it is too late.

Scaled Agile - State of App Dev report  

Scaled Agile Frameworks Options

For environments requiring a bit more structure, the good news is that there are multiple scaled agile frameworks already in place. They range from light to heavy, and they all have their relative pros and cons. For that reason, there is no clear winner for every situation or one-size-fits-all approach. It is also important to note that some assembly is required with each of them. These are toolkits that can and should be adapted to your existing environment. Picking the right one and starting slow is very important to minimize the friction and disruption associated with the implementation of the framework. 

With that in mind, let’s take a look at some of the most popular options available.

Nexus

Nexus is a framework consisting of roles, events, artifacts, and rules. These bind and weave together the work of approximately 3-9 scrum teams working on a single product backlog to build an Integrated Increment that meets a goal. The Nexus framework is focused on addressing common scaling challenges, like reducing cross-team dependencies, preserving team-self organization, maintaining transparency, and ensuring accountability.

  • Best with fewer scrum teams
  • Single product backlog shared across all teams
  • Nexus Integration Team (NIT) coordinating works, especially dependencies, of scrum teams
  • Nexus sprint planning and sprint review ceremonies include work across scrum teams

Large Scale Scrum (LeSS)

Like Nexus, LeSS is a framework that adheres very closely to scrum. There are two variations — LeSS and LeSS Huge. LeSS is for groups of 3-8 scrum teams with no more than eight people in each. LeSS Huge can scale up to a thousand people on one product. Either way, most of the scaling elements of LeSS are focused on directing the attention of all teams onto the whole product instead of “just my part.” In LeSS, all teams are in a shared sprint to deliver a common shippable product every iteration.

  • Best with < 8 scrum teams (LeSS Huge for > 8 teams)
  • Single product backlog, product owner, and definition of done for all teams. In LeSS Huge, functionality is grouped into requirement areas with separate product owners and teams for each
  • Existing teams coordinate work, especially dependencies, through enhanced communication
  • Includes additional ceremonies such as a combined product backlog review

Scrum @ Scale (S@S)

S@S is a framework that believes the time necessary to make decisions is the primary driver of project failure and budget overruns. As more teams are added to a project, the more this occurs. Consequently, the emphasis of S@S is reducing decision latency. To this end, it focuses on achieving a minimum viable bureaucracy (MVB) by introducing three new structures to Scrum. The goal is to achieve scalability by enabling multiple teams to operate as efficiently as a smaller group.

  • Best with 3-9 scrum teams, but can scale higher
  • Three new structures:
  • 1. Scrum of Scrums - to discuss common/integration issues
  • 2. Executive Action Team - which owns organizational structure and performance
  • 3. Executive MetaScrum - owns enterprise priorities, revenue, and profitability

Disciplined Agile Delivery (DAD)

DAD is a hybrid approach which extends scrum by incorporating best-of-breed elements from a number of different frameworks including: Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, SAFe, and LeSS. Instead of being a prescriptive methodology, DAD takes more of a pragmatic, goal-driven approach. DAD adopts practices and strategies from existing sources and provides advice for when and how to apply them together. 

  • Due to its hybrid nature, DAD can scale anywhere from 3 to a very large number of scrum teams
  • People first. While not prescriptive concerning processes, DAD does recommend a robust set of roles for agile solution delivery based on the parameters of the project

Scaled Agile Framework (SAFe)

SAFe is a well-known and widely utilized framework for scaling agile across the enterprise. There are over 450,000 certified SAFe professionals worldwide, and over 70 percent of US Fortune 100 companies have them. Similar to DAD, it combines best-of-breed elements of different approaches. But unlike DAD, it is highly structured and prescriptive. SAFe provides very specific structure and guidance for all levels of the enterprise that are actively engaged in solution development: Team, Program, Large Solution, and Portfolio. Mastery of the five core competencies for the Lean Enterprise included in SAFe empowers organizations to successfully navigate the transformation to Lean, Agile, and DevOps.

  • Best with > 6 scrum teams.  Can work for smaller groups, but probably not worth it
  • Establishes Center of Excellence (CoE) roles and responsibilities
  • Different governance tiers from simple (Essential SAFe) to highly sophisticated

Choosing the Right Scaled Agile Framework

As you evaluate these scaled agile framework options to determine which is the best fit for you, here are some key considerations:

  • Age/maturity of the platform
  • Level of use/adoption
  • Complexity/rigidity (both to learn and apply)
  • Degree of standardization
  • Scalability potential (from mid-sized projects to very large ones)
  • Availability of trained/knowledgeable resources
  • Resource sharing potential (more the better)
  • DevOps compatibility

The relative weight of each factor should be based on the size and sophistication of your environment. This means what is a good fit for one may not be for another. For instance, if you are just getting started with agile, it is prudent to go with a lighter approach. Remember, you want to apply just enough structure to make a difference without adding unnecessary overhead to the mix. For that reason, it may be best not to go with a heavier platform such as DAD or SAFe unless this is warranted.

Interestingly, a number of the benefits that can be achieved through scaled agile can be further amplified by using a low-code platform for development. In addition to speed improvements, low-code also offers automated governance, and tight support for DevOps. Low-code and scaled agile together can really enhance and supercharge your environment. To that end, here’s an excellent blog post with best practices for adapting agile to build products using low-code.

If you are doing low-code development with multiple teams, it can be really beneficial to use a framework to ensure communication and coordination. Since the development itself takes place so fast, decisioning also needs to occur quickly in order to keep things moving forward.

Whatever you choose to do, a best practice is to start by selecting a relatively small project with seasoned teams and run a pilot test. This will allow you to work out the kinks, make sure that the approach is right for you, and gain executive buy-in. As the initiative gathers momentum, it will be easy to expand later.

Good luck on your scaled agile journey. Enjoy!