The evolution of agile approaches to projects and other organizational endeavors brought with it the emergence of approaches to scaling agile. My intent in the overview and discussion that follows here is to provide exactly that – overview and discussion. I’m focusing on three approaches to scaling agile, specifically Scrum, that are relatively well known. There are three main approaches to scaling agile that are particularly important to know – Large-Scale Scrum (LeSS), Scaled Agile Framework (SAFe), and Scrum@Scale.
Understanding the key components and being aware of the pros and cons of each of these approaches can help practitioners and their organizations select and implement the scaling approach that could work best for your organization and scenarios. Understanding the key elements of each will also help the practitioner working within organizations that are implementing or already have implemented one of these three frameworks.
Each of these approaches to scaling agile has strengths and weaknesses depending on your particular situation. They are also detailed and substantial on their own and are best enjoyed after the practitioner develops a strong foundation in agile frameworks – in the case of LeSS and Scrum@Scale, particularly Scrum. I recommend that a practitioner interested in learning more about one or more of these approaches do some reading and get some hands-on training after developing that foundation in agile and scrum.
Large-Scale Scrum (LeSS)
LeSS was developed by Craig Larman and Bas Vodde in 2005. It deliberately leverages the core elements of Scrum that define how a single team uses Scrum to deliver a potentially shippable increment of a product during each sprint and scales them to work across multiple teams. Larman and Vodde have a fine book on LeSS called Large-Scale Scrum: More with LeSS in which they detail the practices and philosophies behind LeSS. Much of this section is based on my reading of their book.
LeSS provides a framework for multiple teams to leverage Scrum and work together to create completed work elements and then contribute these multiple elements to a single shippable product. For example, two or three Scrum teams could use LeSS to coordinate, combine, and deliver features to a single software product, either in a release or through continuous delivery.
According to Larman and Vodde, in the LeSS framework, large can mean up to as many as five teams, possibly working at one or two locations. Scenarios in which a LeSS framework is being considered for hundreds of teams and overall larger scenarios where these teams could span multiple locations are referred to as LeSS Huge (Larman & Vodde, 2016).
Key Practices of LeSS
Uses the core practices of Scrum as is and applies them to larger scenarios and should not be misinterpreted as a new or improved version of Scrum.
Does not introduce new roles, artifacts, or processes to the basic Scrum framework. LeSS retains Scrum’s focus on self-managed and highly accountable teams leveraging the Scrum framework.
Offers constant and iterative improvement. Like Scrum, it leverages the ongoing and evolutionary cycle of learning to improve the product and the team’s practices.
Uses a plan-do-check-act cycle to constantly strive toward creating better products, faster, less expensively, with high quality, while meeting the needs of customers.
Uses lean approaches such as managers as teachers, respect for people, seeking to improve, and fixing defects as they are found (Larman & Vodde, 2016).
Product and Process Focus
Relies on transparency through truly done work products, short time-boxed iterations, teamwork, and an environment where experiments are encouraged and mistakes are not punished.
Focuses on the entire product, that is, there is a single backlog, product owner (PO), product, and sprint regardless of the number of teams.
Focuses on determining the value customers need to receive through solved problems, as with Scrum.
Incorporates systems thinking and requires an understanding of and focus on the entire system with an eye toward optimization of the system as a whole, as opposed to any specific subcomponent or individual.
Relies on empirical data to evaluate and control the process. It relies on the actual outcomes from every sprint to determine how to adjust and improve processes and the product.
Requires an understanding of how queued processes work in scenarios where research and development is being performed and how to account for the limits of work in progress and the size of the work components (Larman & Vodde, 2016).
Practices That Are Important to Success with LeSS
There are some LeSS practices that are critical to successfully using LeSS to scale agile and scrum. For example, LeSS relies on a full-time scrum master (SM) to work across the LeSS teams. Like Scrum, LeSS functions best when the performing organization commits to having long-lived teams.
It is most effective when the teams are co-located rather than teams being distributed. This does not mean distributed teams cannot work, but co-location is preferred. LeSS relies on independent teams working on a single goal without relying on direction from a program or portfolio pushing work down to the teams. LeSS requires cross-functional teams and does not rely on shared services such as separate integration or architectural teams. In LeSS, these shared services slow teams down. Manager roles exist in LeSS purely to ensure teams have resources and learning that they need to be successful, and not to dictate how the teams perform their work (Larman & Vodde, 2016).
When to Use LeSS
LeSS works best when applied to a single product because the framework assumes a single PO, a single backlog, one scrum master working across the teams, and one sprint and release cadence that multiple teams will use. Multiple products and multiple backlogs indicate a scenario where basic LeSS is not the best approach.
For example, a software company with a single product and one team that has grown too large to effectively use basic Scrum would use LeSS as follows: They would maintain a single product backlog managed by a single PO. It would maintain one sprint and release cadence rather than allowing the teams to operate on different cadences. One scrum master would work with the two or perhaps three newly formed teams to help them leverage Scrum and LeSS effectively.
Scaled Agile Framework (SAFe)
SAFe is a framework of processes that can help larger organizations scale agile practices. SAFe considers the needs and special challenges faced by larger organizations as they seek to scale agile over multiple products, portfolios, programs, workstreams, and teams. SAFe is more complex and adds more roles and structure as compared to Large-Scale Scrum (LeSS) or Scrum@Scale.
The origins and development of the foundations of SAFe are credited to Dean Leffingwell, who founded and leads a company that owns and provides the SAFe content. Much of this section is based on my reading and review of SAFe materials in order to evaluate it for my own understanding as well as to teach about it at an awareness level in my courses. It is a substantial framework, and those seeking to use it should seek additional information and perhaps one of the SAFe certifications that are available.
Key Practices of SAFe
At its foundation, SAFe is based on the core tenets of agile, lean product development, and systems thinking. SAFe itself has four core values, which are alignment, built-in quality, transparency, and program execution.
Alignment refers to the alignment of the company at its strategic product and portfolio levels. This ensures that lower levels of the framework, most critically the product owners (POs), understand the strategic direction of the organization and make informed decisions and provide guidance to teams based on this alignment.
Built-in quality is a core tenet of agile practices. With SAFe, having quality built in to all processes, from architecture to design and development, is especially important. As an organization scales, the opportunities for quality issues to impact multiple elements of a product, program, or portfolio are multiplied.
Next, transparency means that, as with all agile practices, all information regarding priorities, progress, improvement opportunities, portfolio and program objectives, and strategies are visible to all.
Finally, program execution ensures that agile teams are indeed executing and delivering at a coordinated program level. Organizations often begin with individual agile teams but are challenged in scaling these up in a coordinated way (“Scaled Agile Framework – SAFe for lean enterprises,” n.d.).
Core Competencies of SAFe
The core values of SAFe are supplemented by core competencies that can help to make SAFe a successful approach. These core competencies are lean-agile leadership, team and technical agility, development operations (DevOps) and release on demand, business solutions and lean systems engineering, and lean portfolio management.
Lean-agile leadership refers to the responsibility of the organization’s leaders to create the environment and drive the changes in which SAFe can succeed by leveraging lean and agile leadership practices and values.
Team and technical agility are the ability of the organization’s teams and their technical practices to use various agile practices and methods to consistently deliver their work in sprints while coordinating with other teams. In SAFe, this framework is called the agile release train (ART) where work is delivered by individual teams, coordinating with each other and contributing to the larger whole.
DevOps and release on demand are technical capabilities that are necessary for an organization to use SAFe effectively and maximize rapid value delivery. DevOps is an organizational mindset and technical framework that aligns development, production, security, and business operations processes. This, in turn, enables an organization using agile and SAFe practices and ART to be able to release working software at any time in the cycle, thereby delivering value as rapidly as possible.
SAFe is used by large organizations to deliver large and complex solutions and systems. Despite the size and complexity of these solutions, SAFe uses lean systems engineering and agile practices to design and build incrementally, avoiding large planning efforts and phase gates. Instead, it focuses on delivering value while retaining flexibility to learn and adapt.
The same lean and adaptive principles used to deliver large technical solutions in a coordinated way are also applied to the management of the portfolios to ensure investment decisions that support maximum value to the organization, whether to customer-facing products or to internal business process that in turn support the goal of value delivery to customers (“Scaled Agile Framework – SAFe for lean enterprises,” n.d.).
How to Determine If SAFe Fits
SAFe is designed for larger organizations that must scale agile practices across multiple products, programs, and portfolios. SAFe assumes or requires the presence of supporting structures such as automated testing and deployment systems, architectural roadmaps and runways, and various shared services necessary to support multiple ARTs and value streams.
SAFe is a good choice for larger enterprises with more than 500 people and potentially hundreds of teams that have already achieved scale in their business operations and want to move their enterprise to more efficient and effective models of agile delivery at that scale.
SAFe is not a good choice for smaller organizations, startups, or organizations that do not have or do not need the level and scale of management structure that SAFe requires or implies.
Scrum@Scale
I attended Scrum@Scale practitioner training in 2018. I wanted to get formal training in one of the scaled approaches to Scrum, and it was also a great opportunity to learn directly from Scrum co-creator Dr. Jeff Sutherland. This section draws heavily on my training and the related materials as well as the Scrum@Scale website.
Scrum@Scale is an approach to scaling Scrum developed by Dr. Jeff Sutherland, the co-creator of Scrum. Sutherland has been scaling Scrum since the mid-1990s and introduced Scrum@Scale as the logical extension of core Scrum practices to scaled scenarios. Based on my in-class questions, Sutherland states that he also introduced Scrum@Scale in response to shortcomings he believes are present in LeSS and SAFe (Sutherland, J. Personal communication, July 2018).
Scrum@Scale is a framework in which coordinated Scrum teams can scale to address complex scenarios and deliver products and solutions of high value, whether these are software, hardware, systems, or services. Scrum@Scale uses the kind of scale-free architecture often found in biology, such as neural networks, to enable organizations to effectively coordinate an unlimited number of Scrum teams (Sutherland, 2018).
Scrum@Scale Practices
For its foundation, Scrum@Scale requires consistent and effective use of basic Scrum processes as prescribed by the Scrum Guide. Scrum@Scale leverages proper execution of these practices and uses the framework to coordinate and scale across teams, constantly improve and remove impediments, ensure ongoing prioritization and planning, ensure constant transparency to metrics, and enable regular delivery of value through potentially shippable increments of product.
Scrum@Scale focuses on two of the core roles of Scrum – the scrum master (SM) and the product owner (PO) – and their cycle of work and services to the Scrum teams. The Scrum@Scale framework applies the natural cycle of these roles and scales them organically to coordinate the activities of multiple scrum teams.
One of the core tenets of Scrum@Scale is the comparison to the traits of a cellular organism to describe its scale-free architecture. Much like a single cell in an organism contains all the specific processes for that cell and interacts with other cells to grow and create a larger organism, Scrum@Scale Scrum teams contain specific processes and leverage the framework to scale these processes (Sutherland, 2018).
Key Practices of Scrum@Scale
Scrum of Scrums (SoS) – A team of Scrum teams that coordinate to deliver an increment of value at the end of a sprint. In very complex scenarios, this scales to a scrum of scrum of scrums.
Scaled Daily Scrum (SDS) – A method used to coordinate the SoS and ensure impediments are removed and learnings shared to achieve the sprint goal.
Executive Action Team (EAT) – A team that aligns evolution of the organization to a change strategy, monitors metrics, and removes high-level impediments, and ensures decisions and priorities are addressed constantly, as decision delays are a common killer of productivity in agile settings.
The Agile Practice – A cross-functional team that works across the organization to coach and train on Scrum practices to support Scrum@Scale and is a source of continuous learning for Scrum professionals.
The MetaScrum – A team of POs, led by a chief product owner (CPO). It is responsible for constantly refining the product vision into a single backlog to maximize value to stakeholders through the work of the SoS. A key event is the regular MetaScrum backlog refinement meeting in which the organization aligns around a single backlog and priorities are set for multiple teams (Sutherland, 2018).
How to Determine If S@S Fits
In theory, the Scrum@Scale framework can be applied to any size or type of organization due to its scale-free architecture. In practice, there are key factors to examine to ensure that Scrum@Scale is a good fit to use as a scaling framework.
The most important factor is existing good Scrum practices. Scrum@Scale relies on the consistent and rigorous practice of Scrum as a foundation to scale. Organizations that are not truly agile will struggle with Scrum@Scale. As with Scrum itself, co-located teams are important to the success of Scrum@Scale.
Scrum@Scale is more likely to work well in organizations that have flatter organizational structures and are already accustomed to making decisions quickly. It can provide the framework for rapid prioritization and decision making but will also reveal impediments to this in more bureaucratic organizations.
Scrum@Scale is beneficial for organizations that focus on teamwork and reward collaboration. At the same time, it will reveal dysfunctional organizations focused on the individual and top-heavy structures built at the expense and loss of overall value delivery to the enterprise.
Determining If Your Organization Is Ready to Scale Agile
Attempting to scale any business practice should be carefully evaluated, and approaches to project management are no exception. Assuming that your organization has already had some success with agile, you may be thinking about whether it is time to consider scaling up your practices and processes. Perhaps you are a small firm who had been operating one scrum team, but you realize that this team has grown too large to continue as a single team. Maybe you work in a larger organization that has adopted agile in an ad hoc way, or with a degree of coordination, and now the senior leaders in the organization recognize that agile practices could serve the organization if coordinated intentionally and purposefully.
Maybe your organization has been experimenting with agile on one project using a large team and realized that one large team is not as efficient as leveraging three smaller teams on the same project but working on a single backlog. Or, perhaps you work in a government agency seeing funding cuts but with no reduction in your mission. These are just a few scenarios that I have worked in that required the organizations and their practitioners to consider one or more approaches to scaling their agile practices. There are many factors to consider.
Readiness to Change and Other Factors
Leadership support – Leaders in an organization play a part in successful use of any scaling approach. They must be onboard with the change and accountable for supporting the work necessary.
Common understanding – The organization should train its teams in agile practices with a common curriculum. A common agile language within the organization is a key when scaling agile. A common basis in training is critical.
Quality and rigor of existing agile practices: The organization should already be using agile and Scrum practices with a high level of rigor and adherence to core agile and Scrum tenets.
Product owners (POs) – Any organization considering scaling agile and Scrum should have embraced and implemented the concept of dedicated POs.
Recognition of the need – Organizations that want to scale their agile practices should recognize the need for themselves based on empirical data and observations.
The presence of a collaborative and servant-leadership culture in midmanagement. A culture that does not support or may even oppose key practices of agile will certainly not support any approach to scaled agile.
If some or many of these factors are missing, consider doing the work or analysis necessary to close the gaps before proceeding further with scaling agile in your organization.
Assessing Organizational Fit
LeSS is best suited for smaller to medium-sized organizations because it scales well for up to five teams at up to two sites. SAFe is better suited for large organizations, while Scrum@Scale is theoretically able to scale to any sized organization.
LeSS helps organizations delivering a single product optimize multiple Scrum teams to coordinate multiple components for a single integrated product. SAFe is designed to address the agile scaling needs of organizations with multiple products, portfolios, and programs. Scrum@Scale adapts to organizations using Scrum for developing and supporting a single product as well as to organizations delivering multiple projects with a single customer for each project.
LeSS inherently values flatter organizations and calls for a reassessment of many managerial roles as part of its implementation. SAFe acknowledges the more hierarchical models present in larger organizations while outlining ways to align the structure and agile practices to achieve scaled efficiency. Scrum@Scale scales out the Scrum model of scrum teams, scrum masters (SMs), and POs. Scrum@Scale can leverage an existing senior management structure through the creation of the EAT. Middle manager roles become less about directing work and more about supporting the teams and ensuring skills and knowledge growth for people in their functional areas.
When examining organizational models, it is also important to consider organization by product or service versus functional specialties. Organizations that are already organized along product and service lines with technology teams embedded in these lines will adapt and scale agile more easily.
Agile inherently assumes strategic input will be sought and used constantly and is designed to allow an organization to adapt to rapid change. LeSS, SAFe, and Scrum@Scale may fit better with different approaches to strategic planning. Given its likely application in smaller organizations and to a smaller number of teams, LeSS is more tolerant of shorter cycles and more frequent changes in strategic planning.
By contrast, SAFe assumes a considerable degree of architectural runway and portfolio planning. Therefore, an organization with immature strategic planning practices is not likely to realize the full benefits of SAFe. Scrum@Scale adapts to process predictability versus adaptability as well as convergence or emergence of product design. Therefore, the organization considering Scrum@Scale must consider its understanding of these aspects of its own strategy.
Consider a company early in the adoption of agile and Scrum practices and not rigorous or disciplined in its use of agile and Scrum. No scaling should be attempted until this organization gains maturity and consistency in using agile methods.
Consider a rapidly growing company that has used agile from the very beginning. LeSS or Scrum@Scale could work well, but this enterprise is too early in its life cycle for SAFe or may find the SAFe structures stifling.
Consider a large national telecommunications company with 100 scrum teams delivering on many products and programs. This organization could leverage its existing scale to benefit from SAFe’s structure, whereas LeSS may not be the best approach because of the multiple products and portfolios. Scrum@Scale might be theoretically possible, but likely not as good a choice as SAFe.
Consider a recently acquired, early stage software company using agile effectively and growing its development team beyond 15 people: LeSS is a good choice because this organization is ready to split the team into two or three teams and can maintain a single PO and backlog. SAFe would not fit. Scrum@Scale would likely work, but not as well as LeSS.
Summary
Scaling your agile practices is an important decision. Recognizing when in the development and adoption of agile as a practice within your organization it is appropriate to begin scaling depends on a number of factors. Selecting the right approach is also critical. Depending on the type of company, the scale of your company, and where you are in overall maturity, one of the three approaches described here could be appropriate. Perhaps a different approach, including a hybrid approach, could be right or wrong. It may also be appropriate to look at each of these methods along with other project management and program management techniques to create a hybrid model that works for your specific situation.