The prevalence of Agile methods in the software industry today is obvious. All major defense contractors in the market can tell you about their approaches to implementing the values and principles found in the Agile Manifesto. Published frameworks and methodologies are rapidly maturing, and a wave of associated terminology is part of the modern lexicon. We are seeing consultants feuding on Internet forums as well, with each one claiming to have the "true" answer for what Agile is and how to make it work in your organization. The challenge now is to scale Agile to work in complex settings with larger teams, larger systems, longer timelines, diverse operating environments, and multiple engineering disciplines. I recently explored the issues surrounding scaling Agile within the Department of Defense (DoD) with Mary Ann Lapham, Suzanne Miller, Eileen Wrubel, and Peter Capell. This blog post, an excerpt of our recently published technical note Scaling Agile Methods for Department of Defense Programs, presents five perspectives on scaling Agile from leading thinkers in the field including Scott Ambler, Steve Messenger, Craig Larman, Jeff Sutherland, and Dean Leffingwell.

What is Scaling?

Many people understand Agile concepts through the illustrations offered by widely adopted methods such as Scrum. These team-focused development processes embody patterns of Agile behavior and offer concrete implementation examples. If you want to achieve success with Agile methods in large-scale development efforts, you might be tempted to view the challenge as simply a matter of tailoring Scrum to work with larger groups of people. What we are learning from the experiences of major DoD programs is that this view oversimplifies the real work to do.

Below I present attributes that we have found significant in successfully applying Agile methods in DoD programs. These attributes deserve attention as organizations architect the way their programs will implement Agile processes:

• Team size. Keeping teams small can enable every member of the team to have all the information needed to effectively contribute to the work.
• Specialization of roles. Limiting the extent of specialization among team members is something that most Agile proponents strive for. Agile program managers are instead encouraged to move away from a team structure where people focus only on one specialty
• Iteration length. Iteration length has received much attention among those adopting Agile practices. The challenge of implementing shorter iterations may be one of the biggest challenges in scaling Agile to build larger, more complex software systems.
• Synchronized cadence. Coordinating the contributions of multiple teams to a single product delivery cycle can be hard, no matter what development method you choose. If your teams use different iteration lengths, you will want to look for ways to synchronize the end points of iterations. If teams deliver product features or components (or slices of the architecture) at different times, the cascading effect of rework as integration occurs with each new arrival can lead to a chain of rework-driven cycles that amplify over time. Postponing integration while lagging teams finish their work may lead the early finishing teams to move on to other work without the benefit of potentially course-correcting feedback from the work they've just completed.
• Release definition. At scale, most Agile development efforts are structured into a series of releases, each built up from a number of iterations. Typically people set a release to contain four to six iterations, which often fit into a calendar quarter (e.g., four iterations of 3 weeks each, or six iterations of 2 weeks each lead to a 12-week cycle). When scaling Agile methods it is useful to consider synchronizing with business cycles (e.g., quarterly reporting requirements or cadence driven by earned value management systems), as budget cycles and other external dependencies may follow these patterns.
• Batch size. In scaling Agile, the long wait for feedback is a bigger problem than the heavy weight of documentation. The priority focus should thus be on work in small batches, prioritized by value, with rapid feedback for the user.
• Product owner role. The product owner role in Scrum is a pivotal element to successful implementation because it provides the development team with a single voice of the business. Even among teams not using Scrum, we are seeing a product owner role--or some variant of it--used to communicate priorities based on value for users.
• User role. Agile development relies on collaboration with the users of the system (or someone who represents the user base) in a way that many other development styles do not. Rather than basing all work on an up-front comprehensive requirements specification, engage the users to help refine the development team's understanding of what is needed--at a time when that discussion will have the most beneficial effect.

Five Perspectives on Scaling Agile

Publications and commercial training that help you apply Agile concepts in practice are plentiful. A rapidly growing community of practice exists, with mature products (including training, tools, and work aids) to support adoption of Agile principles using patterns and practices cataloged in reference books and well-curated web content. We interviewed five thought leaders in this space who discussed their frameworks and offered references and advice. The remainder of this post provides highlights of those interviews, which are presented in full in our technical note.

Disciplined Agile Delivery (DAD) with Scott Ambler. To describe DAD as a scaling framework may not tell the whole story--though the authors clearly intend DAD to support scaling. Ambler and Mark Lines, in the central book on this topic, position DAD as a foundation that extends and integrates other Agile methods to provide a more robust solution for implementing Agile. Their emphasis on being "enterprise aware" appears to focus more on doing Agile well, than on scaling practices, per se. The authors do offer an explicit discussion on scaling, listing specific tactical scaling factors to consider (on page 22 of their book), including

• geographical distribution
• team size
• regulatory compliance
• domain complexity
• technical complexity
• organizational distribution
• organizational complexity
• enterprise discipline

One of the main points of emphasis for DAD is that it explicitly addresses initiation of a product to its release, not just the "construction" phase (readers familiar with the Rational Unified Process may recognize this terminology) as the authors describe it. In addition, on the authors emphasize IT solutions, rather than embedded systems or software-reliant product development--though clearly, the information found in DAD can inform those contexts. Scott Ambler explained that the fundamental strategy was to provide a decision framework anchored to a set of process goals (or capabilities). It is presumed that the user is making process decisions by selecting among alternative practices or supplying their own, to meet those goals. The authors are emphatic about their intent to avoid prescribing particular methods and also make their case for avoiding particular practices.

Dynamic Systems Development Method (DSDM) with Steve Messenger. The DSDM Agile Project Framework (previously known as Atern) was established in 1994 (well before the Agile Manifesto was signed). DSDM emerged from Rapid Application Development (RAD) to create an independent RAD framework. Some of its proponents were signers of the Agile Manifesto. In fact, DSDM helped shape the Agile Manifesto.

DSDM can be used both for IT and non-IT projects because it addresses the whole product lifecycle. DSDM is organized as a model that can be used with other methods or a wrapper to ensure the whole lifecycle is addressed. It can integrate with other methods, such as Scrum and XP.

Because DSDM is an iterative approach, you can revisit any previous step in the DSDM process as needed, so the idea is to finish only enough in one step so you can move on to the next step. DSDM is also considered a convergent approach where basic foundations (architecture) are agreed upon at an early stage.

Incorporating Agile and Lean principles, DSDM implements the 80/20 rule--asserting that 80 percent of the solution is done in 20 percent of the time. This framework assumes that nothing is built perfectly the first time and proposes building simpler solutions that are fit for purpose. As the lifecycle evolves, maintenance can be treated as a future increment.

DSDM can be scaled by configuring and calibrating it for larger projects that need stronger governance. This scaling is achieved by configuring the lifecycle for a specific project and appropriate level of formality with which the DSDM products are defined, created, and approved. If necessary, specific techniques, such as workshops for planning at scale, can be designed to help make large-scale development a reality without conflicting with DSDM philosophy and controls or compromising innate Agility. Essentially, the organization will be refined to support multiple teams and products. The solution architecture definition, development approach definition, management approach definition, and delivery plan and time box review records can be more elaborate and formal.

Large Scale Scrum (LeSS) with Craig Larman. The LeSS Framework was developed to scale Scrum upward based on the insight that "Scrum hits the sweet spot between abstract principles and concrete practices". Thus, Larman and Bas Vodde reason, to scale Scrum upward, similar balance must be achieved: "For large groups, LeSS hits the sweet spot between defined concrete elements and empirical process control." During our interview, Larman emphasized the critical need to understand and evolve the organization.

Focusing on differences between the espoused goals of an organization and the goals implied by the behavior of the staff leads to a deeper understanding of how structure drives culture.

In scaling, Larman and Vodde advocate

• Simplicity. The authors advise avoiding the addition of roles, artifacts, and process. LeSS seeks to avoid providing a defined process, and rather having the product group empirically create necessary process.
• Scaling Scrum. Larman and Vodde emphasize that rather than using Scrum as a building block in a framework, it is necessary to examine each element of Scrum, analyze its purpose, and determine how that purpose can be achieved on a larger scale.
• Scaling up instead of tailoring down. The authors posit that when scaling process development for larger organizations, it is common to define a universal framework and then allow contextual tailoring. The assumptions associated with tailoring the framework lead to bloated processes, as participants often believe that all of the overarching framework is required in each context.

Modular Framework for Scaling Scrum with Jeff Sutherland. The Modular Framework for Scaling Scrum, from Scrum Inc., provides a basis for iterative and incremental adaptation of successful Agile patterns within an enterprise. Rather than focusing on a particular solution--expressed as a comprehensive pattern to be instantiated--this framework aids in the decomposition of work needed to successfully use Scrum at scale. As Sutherland explains, the context in which a company operates drives the focus on areas that need to change.

Pre-recorded webinars available on the company website, as well as numerous online conference presentations, provide a great deal of free information for further study of this framework.

Our interview with Sutherland covered a lot of ground including his most recent experiences working with large organizations. First and foremost, Sutherland wanted us to understand that scaling Agile is not about an implementation, but rather the values in the Agile Manifesto. The emphasis on speed and identifying impediments that slow teams down dominated the conversation. Sutherland told us that a single common backlog, which can then be partitioned into the work done by contributing teams, is an essential element of success. To achieve this, the leadership in the organization must be able to provide clear priorities. In the successful companies, Sutherland also told us that shorter iteration length is associated with a greater completion rate. An iteration length of one week is what he is striving for, with the goal being a continuous flow of working software--integrating multiple times per iteration.

Cautioning us about the detrimental effect of evolving team membership, Sutherland advises that forming stable teams (of no more than nine individuals) is important--to a greater degree than is the focus on generalists. His experience suggests that working to reduce specialization of individual talents should come after you gain experience with maintaining stable teams delivering working code in short iterations.

Another pattern of concern is the detrimental effect of deferring work into later sprints. Sutherland indicated that when tests slip into the next sprint, it can take as much as 24 times longer to deliver working code.

Scaled Agile Framework (SAFe) with Dean Leffingwell. The Scaled Agile Framework (SAFe) is widely viewed through the web interface that presents an overview image, with clickable links to articles that describe the selected topic.

A collection of Agile teams (each consisting of five to nine people) make up what is called an "Agile release train (ART)," which comprises 50-to-125 people. ARTs build solutions that realize the intent of what are termed portfolio "value streams." ARTs apply a nested incremental development cadence of two-week iterations, aggregating value and time into 8-to-12 week "program increments." Lean and Agile principles are referenced throughout the material available on the website and in the training curriculum. SAFe espouses four core values:

1. quality
2. program execution
3. alignment
4. transparency

These values drive choices in how to implement concepts in your particular setting. Along with the concepts accompanying the so-called "House of Lean and Agile Manifesto," SAFe also offers nine principles that underlie the design of SAFe:

1. Take an economic view.
2. Apply systems thinking.
3. Assume variability; preserve options.
4. Build incrementally with fast, integrated learning cycles.
5. Base milestones on an objective evaluation of working systems.
6. Visualize and limit work in process (WIP), reduce batch sizes, and manage queue lengths.
7. Apply cadence; synchronize with cross-domain planning.
8. Unlock the intrinsic motivation of knowledge workers.
9. Decentralize decision-making.

Leffingwell explained that SAFe is designed to scale Lean and Agile concepts from the team level to the program level to the portfolio level with a "sweet spot" initially in the 300-500 person range (per SAFe portfolio)--and can grow to include more than 1,000 people who need to collaborate. Organizations of this size will likely build larger systems and have existing architectures and legacy environments that help to define the systems they build/maintain. Roles and responsibilities that accommodate such things are described in SAFe.

In addition, SAFe 4.0 features an entirely new value stream level, intended to support those building the largest software and cyber-physical systems. Leffingwell emphasized how the so-called "requirements and design-freeze milestones" seen in many major development efforts force a too-early stake in the ground and a commitment to a specific implementation before the team knows enough about the system they are building.

Looking Ahead

While a number of published frameworks are available, each has strengths and weaknesses. The challenge faced by many in the Agile community today is how to scale Agile to work in complex settings, with larger teams, larger systems, longer timelines, diverse operating environments, and multiple engineering disciplines.

We welcome your feedback in the comments section below.

Additional Resources

Read the SEI technical note from which this post is excerpted, Scaling Agile Methods for Department of Defense Programs that I coauthored with Mary Ann Lapham, Eileen Wrubel, Suzanne Miller and Peter Capell.

Read our collection of blog posts detailing efforts to help government organizations adopt Agile methodologies.