Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Scaling Agile using nine SAFe principles

There is no step-by-step recipe for scaling Agile, but with solid principles the software development team will have the ingredients to create high-quality enterprise software.

Although Agile originally was created with small teams in mind, its success and popularity has caused offshoot...

methodologies to evolve that describe how to best use large-scale Agile in enterprise environments. One such methodology for scaling Agile that's growing in popularity is Dean Leffingwell's Scaled Agile Framework (SAFe). In this article, we'll explore the nine principles that form the basis of the SAFe model.

One of the basic ideas of an Agile approach is that it be adaptive to a team's needs and is continually improving. As such, it's important for methodologies to stay away from being overly prescriptive, defining exactly what practices a team should be using. SAFe provides a framework and guidelines, but depends on Agile team members, like gourmet chefs perfecting a recipe, to tweak as needed. To help guide their choices, SAFe offers nine fundamental tenets for scaling Agile, that when taken into account, will lead to high-quality software.

1. Take an economic view

The first value evolved from lean principles and requires delivering value to customers in the most efficient way. Everyday decisions should be made with economic context in mind. It's important for knowledge workers to understand the cost of delay and to be empowered to make decisions without the need to escalate to management.

2. Apply systems thinking

Systems thinking was introduced by Edward Deming and applies to all types of systems, including manufacturing, social, management and government systems. Taking a larger view of the complex interactions within a system is key to improving processes and quality. Within the SAFe context, systems thinking is applied to the product under development and the enterprise developing the product -- and it requires a new approach to management.

3. Assume variability; preserve options

Although systems thinkers tend to want to minimize variability, this principle reminds us that we don't want to eliminate variability too early. Rather than honing in on a specific design that may not be optimal, a better approach, called set-based design, starts with multiple design options, eliminating the weaker ones over time, until the optimal design emerges.

4. Build incrementally with fast, integrated learning cycles

This principle is one of the primary characteristics of any Agile methodology -- iterative development. Teams use short timeboxes to build working software, gather feedback and continue to improve to meet the needs of the customer. Integration points are used to merge the elements into an integrated whole and test for viability. These points provide for learning and improvement so the more frequent, the faster the learning.

5. Base milestones on objective evaluation of working systems

This principle emphasizes evaluating small working systems developed incrementally rather than the traditional phase-gate milestones used in a Waterfall approach. Milestones should be based on objective evidence of working software using the integration points described in the fourth principle.

6. Visualize and limit WIP, reduce batch sizes and manage queue lengths

Using a task board or Kanban board, work-in-progress (WIP) can be visualized and needs to be limited in order to maximize flow. One way to reduce WIP and increase flow is to reduce the batch size of work items. Handling smaller batches can be done by attention to automation and continuous integration.

7. Apply cadence, synchronize with cross-domain planning

Cadence provides a predictable routine for those functions and events that can be routine, allowing knowledge workers to focus on those tasks that have variable parameters and require more innovative and creative thinking. Synchronization is used to integrate multiple perspectives. In SAFe, the release planning event is when the stakeholders meet to assess the current state of the solution, realign to a common vision and plan and commit to the next program increment.

8. Unlock the intrinsic motivation of knowledge workers

Managers need to establish an environment that provides knowledge workers with intrinsic motivation by empowering them to make economically sound decisions, gather frequent feedback and continue to learn and grow in their skills. As pointed out in Daniel Pink's book, Drive, knowledge workers have a need for autonomy and to be part of a high-performing team. Leaders should provide a mission and strong vision and minimize any constraints on the implementation of requirements.

9. Decentralize decision making

Although some strategic decisions for scaling Agile still must be made at the management level, empowering knowledge workers to make most decisions will increase flow and enable faster feedback cycles. An organization will benefit from establishing a decision-making framework to provide guidance on decision-making criteria.

These nine principles based on proven lean-Agile concepts provide the key to the SAFe model. There is no step-by-step recipe for developing complex software; however, with a solid set of principles, the software development team will have the ingredients to create high-quality enterprise software.

Next Steps

How to make the transition to Scrum

Overcoming large-scale Agile concerns

Large-scale Agile product management

This was last published in July 2015

Dig Deeper on Building Software Project Teams



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Which of the SAFe framework nine principles for scaling Agile do you find most useful?
Probably #9, decentralize decision making. In my conversations with a few thinkers I respect, one thing we tend to agree on is that if you start with retrospectives and empowerment, and give the teams support to learn the tech practices/experiment, most teams can learn/discover/invent/figure out the rest themselves.

On the other hand, if you don't let the team retrospective, and push "agile" top down, you'll likely encounter resistance and struggle.
1.  If you don't take a whole system approach to building a system, then be eready to deal with bad technical debt decisions later.
I probably have the most question about 3.  I worry about that approach being not sustainable going forward.  it seems to me, devs can try a few approaches when they work on most stories, big architectural changes, can be decoupled to an extent, but it still seems like a lot of work.