Agile is a development approach that presents solutions for delivering working increments on a timely basis. Pure agile works best with teams of five to nine members. When companies attempt to use agile approaches to meet enterprise-wide demands or to execute a large, complex project, they may run into problems if they don't execute a systematic framework to incorporate best practices in large-scale agile implementation.
This paper examines the principles of scaling agile, including the concept of the scrum of scrums. It examines the unique features and the pros and cons of the three leading frameworks (Scaled Agile Framework, Disciplined Agile Delivery, and Large-Scale Scrum), and presents guidelines to help choose a scaled solution that will fit your team and project's needs.
Introduction
Many companies implement agile by testing the waters with one or two teams on a small- to medium-size project. When they decide to scale agile across the enterprise, they often find that what worked well for a team of five to nine people does not scale well without modifications. Teams are not always aligned with the needs of agile, which makes successfully implementing agile on projects with larger teams and greater complexity more difficult. In addition, enterprise factors, such as a lack of specialized resources (including user experience design specialists, security specialists, and other IT specialists) and lack of stakeholder support can pose challenges.
Companies, whether small or large, can solve this problem by implementing a framework designed to scale agile. There are numerous choices to scale specific agile and scrum practices in order to produce benefits across the enterprise. In the last five to ten years, the number and prominence of frameworks has grown, prompting the creation of an organization known as Agile Scaling, which has established a knowledge base for comparison and contrast of frameworks (Agile Scaling, 2014). While there are numerous frameworks listed in this knowledge base, three frameworks, in particular, are the focus of this paper: Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), and Large-Scale Scrum (LeSS).
The primary principle of scaling agile is that team size does not increase, but rather, the number of teams increases and frameworks introduce more ways to organize them. Scaled agile approaches often use the concept of a “scrum of scrums,” in which each team sends a representative to a meeting of all teams at least twice per week to engage in higher-level planning. The scrum of scrums can scale further as needed, becoming a scrum of scrum of scrums as the situation warrants. While the scrum of scrums approach is effective by itself in many cases, some companies will need more rigor out of a scaling approach.
Determining Agile Fit
It is assumed in this paper that companies seeking to scale agile have already assessed their fitness level for agile adoption. Companies are encouraged to make this assessment and seek executive-level support to confirm institutional backing for agile adoption. Through agile coaching and consulting, RefineM has defined several criteria to evaluate whether agile is a good fit; companies or projects not meeting these criteria may want to consider waterfall or other approaches (RefineM, 2013):
- The leader/sponsor has a clear vision, but project scope is not known in its entirety.
- Project requirements are expected to evolve as planning proceeds.
- Changes are expected, even welcomed, late in the project and can be processed informally.
- Time and cost are fixed, but scope is flexible.
- The client will accept fewer features at the end, but whatever gets delivered should be usable.
- Stakeholders are eager to consume “low-hanging fruits” in the form of small and frequent deliveries of working software components.
- Customers are highly involved in the project; they participate in the project almost every day.
Evaluate Your Needs and the Desired Outcome
With the number of available options, choosing a framework can be difficult. Because the transition to a framework for scaling agile is a significant business commitment, it is critical to perform a self-assessment to understand:
What is the business strategy, and how has agile helped to achieve it so far?
- How many agile projects are planned, and how many teams are available to execute them?
- Are current agile teams skilled enough to maintain high performance in a scaled environment?
- What is the average size and complexity of agile projects?
- What additional benefits are possible with a scaled solution?
- What are the critical success factors of the scaled agile transition?
Taking time to think through these questions will help build a foundation to select a framework that best fits the needs of their team and project. Considering company strategy and culture is a more effective starting point than beginning with a comparison, since developing this knowledge provides stronger criteria for choosing a solution. Comparing frameworks will not be useful without the self-knowledge and resulting criteria; there is too much information and too many available frameworks to be able to make an effective choice without developing criteria.
A survey conducted by VersionOne, a developer of agile lifecycle management software, illuminates five common lessons learned from scaling agile, ranked by response rate and presented as tips in Exhibit 1.
Exhibit 1: Top five tips for success in scaling agile.
It is clear that a successful scaling agile transition depends on solving problems involving both processes and people. Not only is effective process transition important, but also getting executives on board and ensuring teams have resources is critical. Reviewing company strategy and developing internal knowledge will aid company decision makers by providing greater clarity to their final decision. Blindly trying any of the approaches is likely to waste time and money. There can be a lot of overhead involved in implementing a method to scale agile, especially if people need to be trained and certified in how to implement the solution. Conducting research to develop internal knowledge will help decision makers get more out of tools available online, such as the Agile Scaling knowledge base (Agile Scaling, 2014).
The following sections describe Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), and Large-Scale Scrum (LeSS). In addition, specific instances of companies adopting a particular framework are shared to illuminate the situations in which companies have scaled agile. Exhibit 5 provides unique features and the pros and cons of each framework.
Scaled Agile Framework (SAFe)
Scaled Agile Framework, or SAFe, is a solution created by Dean Leffingwell based on his writing on software scaling agility from as far back as 2007. SAFe incorporates planning at the levels of team, program, and portfolio, so that organizations can build a solution for the whole enterprise, rather than one team or project. SAFe pioneered the concept of Agile Release Trains (ARTs) to organize teams around value streams and a common delivery cadence. It is a common framework used in scaling agile, with 19 percent of respondents in VersionOne's survey reporting that they have used it (VersionOne, 2015).
At the team level, teams use Scrum and XP practices to define, build, and test working software every two weeks (Pinna, 2013). Team members adopt many of the roles that one would expect to find in agile: a product owner, developers, testers, and a ScrumMaster. Teams develop in cadence to match up with the ART.
At the program level, each value stream has an ART that includes around 5-10 teams and that delivers a Potentially Shippable Increment (PSI) every 10 weeks (5 iterations). The Release Train Engineer is a role unique to SAFe that manages teams and release logistics, acting as what Pinna calls an “Uber-ScrumMaster” (Pinna, 2013). The product manager role, similar to the product owner, has deep expertise of the value stream. A program manager or senior project manager could fill the role. Finally, the release management team helps manage each release to a customer, and includes members from various functions such as marketing, development, and quality.
Shared resources also exist on the program level to provide consistency to teams’ releases. UX designers, security specialists, and database specialists are three examples of resources that would be shared across teams. The shared resources approach helps teams who might otherwise run into issues from lacking necessary expertise on their own team, and also helps prevent specialized roles from becoming overloaded.
Finally, at the portfolio level, investment themes last 6-12 months and drive the budgeting process from the top (Pinna, 2013). To support the investment themes, there are customer-facing “business epics,” and “architectural epics” that are focused on technical solutions. The presence of Agile Release Trains to deliver consistent PSIs across value streams helps teams work to complete their business and architectural epics, which, in turn, helps fulfil investment themes.
SAFe's emphasis on separating what needs to happen at the team, program, and portfolio level is one of its highlights. As Ron Jeffries points out in his article critiquing SAFe, agile approaches, particularly Scrum, don't provide a lot of guidance on how to handle the program and portfolio level (Jeffries, 2014). Since SAFe provides this guidance, it can be useful for managing programs and portfolios across the enterprise.
The emphasis SAFe places on value streams is another benefit, since this activity helps companies eliminate waste and focus their thinking on the activities that provide the most value. The concept of sharing resources among teams can help to ensure consistency in development and address resource problems, as long as the shared resources are scheduled in a way that prevents idleness or delays.
Many aspects of SAFe are rigid compared to other frameworks. For example, two-week iterations and ten-week Potentially Shippable Increments (PSIs) are required. In addition, Jeffries (2014) argues that SAFe provides more rigor, but also more overhead, than what most companies and projects require. For these reasons, SAFe may not work as well for companies developing their agile knowledge and practices. Many new agile teams struggle to deliver in two-week iterations due to time spent learning processes and ceremonies. The level of rigor provides additional overhead that may compound this struggle. Companies with the size and capability to effectively adopt SAFe will find a useful framework able to meet enterprise-wide demands. One company that adopted SAFe, John Deere, was able to reduce time to production and time to market by 20 percent each (Holdorf, 2011).
Several certifications are available for those who want to learn more about SAFe. These include the SAFe Agilist (SA) SAFe Practitioner (SP) and SAFe Product Manager / Product Owner (SPM/PO) for practitioners, and also Program Consultant (SPC) and Program Consultant and Trainer (SPCT) for those who wish to teach others how to implement SAFe (Scaled Agile Academy, 2015).
Exhibit 2 provides an overview of the portfolio, program, and team levels.
Exhibit 2: SAFe portfolio, program, and team levels.
Disciplined Agile Delivery (DAD)
Disciplined Agile Delivery, or DAD, is a people-first approach to agile delivery that emphasizes roles over processes in scaling agile. It was created by Scott Ambler and Mark Lines, who published the book Disciplined Agile Delivery in 2012, based on their experiences developing the framework for IBM.
In DAD, the primary team roles—team lead, product owner, team member, architecture owner, and stakeholders—are always present, regardless of size (Disciplined Agile Delivery, 2015). Many of those roles are familiar to project teams. The architecture owner is a unique role that is responsible for solution design decisions (Disciplined Agile Delivery, 2012). Secondary roles include specialists, domain experts, technical experts, independent testers, and integrators. These special roles support scaled solutions as needed, and may otherwise go unfilled.
While many scaling frameworks focus on how enterprises deliver working software at scale, DAD emphasizes a full delivery lifecycle based on consumable solutions (Ambler, 2013). Consumable solutions include not just the working software, but also documentation and anything else that supports providing value to the customer. DAD's delivery lifecycle includes the following:
- Inception: Teams develop the project vision and plan the project.
- Construction: Teams incrementally build a consumable solution.
- Transition: Teams release the consumable solution.
In contrast to SAFe, DAD is more goals driven and less prescriptive. The authors argue that a goal-driven approach makes DAD more flexible and easier to scale (Disciplined Agile Delivery, 2015). They recommend that companies scale agile based on what factors deliver the greatest customer value. In other words, by determining what the goals are, companies can choose to scale in a way that supports the goals.
Certification is also available for practitioners, which follows the “shuhari” learning path that is often used in martial arts. Similarly to lean certifications, DAD certifications range from white belt to black belt, as practitioners go from learning the basic concepts to being able to break them in specific situations, and, finally, to being able to teach the same concepts (Disciplined Agile Consortium, 2014).
Exhibit 3 depicts scaling factors for DAD (MacIsaac, 2012). Based on these scaling factors, it is clear that DAD provides scaling flexibility, making it appealing to smaller- to medium-sized enterprises. Because DAD is still fairly new, its adoption rate is still low; VersionOne's survey listed DAD usage at 4 percent (VersionOne, 2015). This limited usage means that finding coaching or consulting to help implement DAD may be difficult. Despite the low adoption rate, there are examples of DAD in use; Mark Lines, one of the creators of DAD, has released a case study of how DAD was implemented at Panera Bread by getting senior executive buy-in, using an agile champion, and carefully selecting pilot projects (Lines, 2014) As DAD continues to spread, and more agilists obtain certifications, the framework may see wider use.
Exhibit 3: Disciplined agile delivery scaling factors.
Large Scale Scrum (LeSS)
Large-Scale Scrum is adapted from the book Practices for Scaling Lean and Agile Development, by Craig Larman and Bas Vodde. It is defined as regular Scrum plus “a set of additional rules and the set of tips that we have seen work in large multi-team, multisite, and offshore agile development initiatives” (LeSS Company, 2014a). In other words, it is Scrum applied to large-scale development.
The two levels of LeSS – regular LeSS and LeSS-Huge – are built using teams as the organizational building block. LeSS teams follow typical rules of agile teams and are also dedicated, with members spending all their time on the same team. They are also co-located, and long-lived (rather than temporary) to support stronger bonds and improved performance (LeSS Company, 2014d).
Regular LeSS is for 2-8 teams, while LeSS-Huge is for over eight teams (LeSS Company, 2014b). In LeSS, ScrumMasters perform their role full-time for up to three teams at a time. Teams work on their sprints concurrently and share one product owner, product backlog, and definition of done for their shippable product. Each team has its own sprint backlog and retrospectives, with one common “Overall Retrospective” and sprint review. LeSS Huge adds “Requirement Areas,” which are related clusters of customer requirements. Each cluster has its own product owner and group of 4-8 teams, allowing each team to focus on its particular area.
LeSS also enforces a reduced management role. The product owner decides what the team will do, and the team itself decides how they will do it. Under LeSS, the role of management shifts to building capability, which means removing impediments and coordinating with senior management to adapt the organization to teams’ goals (LeSS Company, 2014c).
LeSS focuses effort on what the customer wants and enforcing the principles of scrum to help teams achieve it. Its key features, including the requirement areas, team makeup, and role of manager, support the idea that scaling successfully depends on first following scrum principles correctly.
LeSS is a simple solution for expanding scrum, yet robust enough to offer more than simply using a scrum of scrums approach. Companies that do not use scrum practices, however, will not find LeSS useful. Like DAD, LeSS is also new, and its adoption rate is also low; three percent of respondents in VersionOne's survey used it in their companies (VersionOne, 2015). Like DAD, even though the adoption rate is low, specific case studies of LeSS implementation are available; for example, Nokia Networks has adopted LeSS Huge for two products (Kohvakka, 2014).
Exhibit 4 is a diagram provided by the LeSS site from Practices for Scaling Lean and Agile Development, which exemplifies the LeSS process.
Exhibit 4: LeSS diagram.
Exhibit 5 is a table with comparisons of the three scaling agile frameworks that have been discussed.
Exhibit 5: Comparisons of scaling frameworks.
Scrum at Scale
Some approaches offer both a ready-made framework and the means of adapting pieces to form a custom framework. One example is Scrum at Scale, which was introduced in mid-2014 by Jeff Sutherland and Ken Schwaber. Rather than provide a set framework for scaling Scrum, Scrum at Scale provides a set of modules, based on past implementation experiences, that companies can choose from to construct their own solution. Sutherland and Schwaber proposed a solution to scale Scrum based on its core principles so that any company can size it for any project (Sutherland, 2014). They advocate a modular scaled approach for greater versatility, ease of incremental deployment, and greater adherence to the modular nature of Scrum. Companies can choose either the ready-made framework or adapt pieces from the modules in the pattern library to construct their solution for scaling agile.
Like LeSS, Scrum at Scale is not as effective for companies that do not use scrum, but the idea of adapting from patterns is useful to anyone seeking a custom-fit solution. The framework itself is relatively new, and did not rank in VersionOne's study (VersionOne, 2015), so finding coaching or consulting could be difficult. Even without the framework itself, the ideas presented by Scrum at Scale are useful in advancing the conversation of agile scaling.
Conclusion
Over the past two decades, agile approaches have been shown to markedly increase the productivity of software development teams. The pathway to carry over these benefits across the enterprise; however, is often less clear.
Companies have a variety of options to scale agile—from the three frameworks discussed in this paper to the adaptation of existing techniques to build a custom solution. When selecting a framework, it is important to perform self-discovery to evaluate your needs and goals, including:
- Current agile process: What works well and what needs improvement?
- Current agile experience: How well do your teams know agile?
- Current agile capability: Can your teams perform well in a scaled environment?
- Benefits realization: What benefits can be realized and how can you attain them?
- Key transition components: What does a successful transition look like?
- Potential risks of a transition: What risks could stall progress and how can you mitigate them?
With a clear understanding of this picture, you will be prepared to locate—or develop—a scaled agile approach that will help your company maximize the benefits of agile, regardless of your team size, project size, or project complexity.
