This is the second blog in a three-part series in which we explore the “how” and “why” behind scaling agile. There are several scaling frameworks being used in the market today, with differing levels of adoption. Each year, a ‘State of Agile’ report is published that outlines the percentage of the market using each framework. The top 50 percent of the scaling frameworks include:
- Scaled Agile Framework or SAFe (30 percent) is the most highly adopted scaling framework on the market. It is also the most robustly designed and articulated. The design of Scaled Agile Framework is mostly about what happens outside of the team, how work makes its way from a strategic thought in the C-suite, down to work items that teams can execute and deliver. It creates value streams and aligns the execution of those streams into groups of teams called release trains. At the team level, it incorporates big room planning in a Program Increment event that plans out the next 5 iterations of work for all the teams on the train and visualizes dependencies.
- Scrum of Scrums or SoS (16 percent) is intended to allow for several teams to work together, but also limit the communication pathways that take up too much time to maintain. The concept of Minimum Viable Release Team is introduced by SoS and is described as the smallest group of teams needed to deliver the product. Members of each team are designated to join the Scrum of Scrums meeting to discuss and eliminate impediments where possible. To reduce the possibility that impediments are not solvable, an Enterprise Action Team (EAT) is created from more senior leaders in the organization. This is where the Scrum of Scrums can refer any impediments that they are not able to resolve. The intention is to create as little structure as possible beyond what Scrum itself articulates.
- Disciplined Agile Delivery or DAD (7 percent) recommends techniques for managing the end to end IT development lifecycle in three phases: Inception, Construction, and Transition. For this reason, DAD's strengths are in providing more guidance in the areas of architecture and design (Inception) and DevOps (Transition). DAD also provides flexibility in suggesting different process guidelines for four categories of lifecycles: agile/basic, lean/advanced, continuous delivery, and exploratory. The Construction phase of agile/basic is scrum, but DAD, adds recommendations for the Inception and Transition phases. The lean/advanced lifecycle uses processes similar to Kanban, maximizing flow and minimizing work in process. The continuous delivery lifecycle focuses on mature DevOps, continuous integration, and deployment processes for projects that require frequent delivery to stakeholders. The exploratory lifecycle minimizes early planning in favor of fast delivery, gaining feedback, and incorporating that feedback into the next delivery.
- Large Scale Scrum or LeSS (3 percent) is essentially a Scrum of Scrums model. There is a team of product owners that can work with any team to deliver work. It is important that each team is capable of working on anything in the backlog and deliver the end-to-end concept that is being requested. LeSS HUGE is their model for larger organizations and a higher number of teams. Each team, or group of teams, performs a group demo of the work completed. They then perform their own retrospective before coming together as the larger group and performing a group retro to improve how the teams are working together.
- Nexus (2 percent) is similar in many ways to Scrum of Scrums as it is also based strongly on the tenets of the scrum framework. While some of the frame-works identified intend to replace existing structures or streamline organizations, Nexus doesn’t claim to do that. It’s most effective for groups of 3-9 teams working on a single product backlog and is a method for scaling scrum, not rebuilding your organization around agile. The prime difference between Nexus and Scrum at Scale is that the impediment removal team is called the Nexus Integration Team (NIT) and is made up of the Product Owner, Scrum Master, and NIT members pulled from individual scrum teams.
How do you determine the framework?
Key questions to ask:
- How much structure is needed? What is the comfort level for ambiguity? What is causing the consideration of scale? Do teams need to be coordinated? LeSS or Scrum of Scrums may be appropriate options to solve these scenarios because they provide the framework for communication without being overly structured.
- Is a major requirement coordinating work around strategic initiatives and guiding the direction of your entire organization? If so, then a more robust and structured framework like SAFe or Disciplined Agile Delivery would may be appropriate. These frameworks address some of the larger structures and coordination along the customer journey.
- How open is your organization to starting with a very loose plan and figuring out what works for them along the way? Some of the frameworks have more rigor around structures surrounding the team, while others are very loosely structured and allow for maximum flexibility. If your organization is not comfortable with that level of ambiguity, then a larger, more defined, and rigid framework would be a good choice.
As with all questions asked of an “agilist", the answer oftentimes is, “it depends.” This is because it depends on what you want to achieve, but it also depends on the organizational dynamics and the associated people and culture. Sometimes the best approach is as simple as starting off with the smallest framework you can get away with and slowly add in elements as you find you can’t live without them. It is often far easier to add in rigor than it is to remove it later on.
In our next blog in this series, we discuss how to successfully roll out agile. Or check out the first blog in this series where we discuss advantages of agile scaling.
