What is the Scaled Agile Framework (SAFe)?
The Scaled Agile Framework, or SAFe, is an agile framework developed for development teams. Most importantly, SAFE’s foundation consists of three metaphorical pillars: Team, Program, and Portfolio. Furthermore, SAFe gives a product team flexibility. Moreover, it helps manage some of the challenges larger organizations have when practicing Agile. SAFe consists of a broad knowledge base of proven best practices. Likewise, product teams use SAFe to deliver successful software products.
What’s the History of the Scaled Agile Framework?
In 2011, the SAFe framework gain recognition in the product world. Software-Industry veteran Dean Leffingwell, the author of Agile Software Requirements, originally called the SAFe framework the “Agile Enterprise Big Picture.” The “Big Picture” described how to leverage existing agile frameworks such as Lean, Kanban, Scrum, and XP—and apply them at the Team, Program, and Portfolio.
Today, SAFe’s entire catalog of knowledge and success patterns is all available for free. SAFe remains one of the most popular agile frameworks.
What are the SAFe Agile Principles
Above all, SAFe is grounded in ten foundational tenets:
SAFe Project Management
Project management in an organization using SAFe happens at three levels. At the individual team level, it’s basically Scrum business as usual.
Small teams have specific goals and areas of responsibility. Therefore, they release iterations after each Sprint. Moreover, a Scrum Master typically leads the charge. The only significant change is that these small teams now roll up into programs.
The program level is where SAFe’s benefits begin shining through. This is where each team’s output must stitch together with everyone else’s into something complementary, cohesive, and consistent.
Under the guidance of a Release Train Engineer, they come together as part of a Agile Release Train. The synchronicity provides the work of a group of individual Scrum teams. After five or so, Sprints, a Potentially Shippable Increment undergoes a complete round of testing. The process represents a departure from more traditional Scrum and Continuous Delivery. In this case, code ships much frequently.
At the highest level, portfolios comprised of multiple programs are defined with longer-term visions spanning multiple quarters or even an entire year. This is where budgeting and epic-level milestones are defined and set, and where strategic planning and project planning intersect.
Scaled Agile
Agile wasn’t originally conceived with scale in mind. The goal was unschackling developers and engineers, empowering them to tackle implementation independently using their own best judgment, incorporating learnings from one iteration into the next.
That unfettered independence doesn’t work as well when there are multiple teams off doing their own thing, particularly when their individual projects must interoperate, share a common interface, rely on a shared architecture, etc. Things can quickly escalate into a free-for-all.
Therefore, leveraging the advantages of Agile while recognizing the need for coordination and compatibility demands more structure, organization, and oversight. Agile at scale must have more rules and controls to ensure the finished product not only functions but works seamlessly across various sub-components, and that product suites look and act like they were built by the same company.
The various Microsoft Office apps, for example, all perform their individual functions well, but what makes the suite even more successful is how seamlessly users can move from one program to the next with a limited learning curve thanks to a common UX. If the Word team and the Excel team operated 100% independently, it wouldn’t be long until each one behaved quite differently.
Scaled Agile provides that layer of management and coordination to build complex solutions that are too big and complicated for a single Scrum team to tackle. This may be driven by urgency to get a solution to market, or simply because the product itself is too large and sophisticated.
Scaled Agile also creates a more predictable release schedule. Because of the coordination required, it’s clearer when certain projects, products, components, and features will ship, enabling enterprise software companies to make customer commitments and line up sales, marketing, operations, and customer service to support these launches.
View our webinar on tying your roadmap strategy to agile planning:
SAFe Versus Scrum
SAFe and Scrum aren’t at odds with each other. Rarely does someone pick one over the other. It’s more a question of environment and objectives for implementing Agile principles.
Scrum is a highly efficient way of delivering a project using a small team. It’s flexible, transparent, and light on overhead. It requires lots of communication between those small team members to operate at a high level.
Scrum is not, however, a great way to run a large organization with multiple products and projects being run simultaneously. It’s the scrappy, Special Ops approach to quickly reaching discrete goals through iterative development.
Managing the complexities, interdependencies, and multiple teams required to operate at scale necessitates a more robust structure to avoid everything devolving into chaos. It’s stepping up from a niche boutique to assembly-line scale coordination.
SAFe’s Agile Release Train doesn’t run on time without a middle-management level of oversight conducted at the program level, with multiple products or projects under that umbrella. And, at the highest levels of the organization, an even broader scope of oversight falls within specific portfolios.
While SAFe does limit the dynamism of Agile’s potential by requiring more planning and rigidity, it does so for the right reasons. The individual pieces of the puzzle must ultimately fit together and larger organizations need a greater degree of standardization to enable resource flexibility and component compatibility.
What are the Strengths and Weaknesses of SAFe?
SAFe’s strengths include:
- Helps cross-functional teams collaborate more effectively
- Helps organizations achieve greater transparency
- Aligns all aspects of a project to the broader business goals
SAFe’s weaknesses include:
- Firstly, some believe the framework is not pure agile, because requires too much upfront planning and process definition
- Also takes more of a top-down approach rather than a team-based approach
SAFe Agile Certification & Training
SAFe training modules typically run two-to-four days depending on the subject area. After completing the course, some additional study and preparation gets potential practitioners ready for a multiple-choice certification exam in their chosen discipline.
SAFe offers a host of certifications available to almost anyone working with the framework. One can become a Certified SAFe Agile Product Manager or a Certified SAFe Product Owner/Product Manager to learn the best practices and techniques for managing products in a SAFe Agile environment.
Becoming a Certified SAFe Lean Portfolio Manager, Certified SAFe Agilist, Certified SAFe Practitioner, or a Certified SAFe Program Consultant prepares people to practice, implement, and introduce SAFe in organizations at a more holistic level. And for more technical staff, there are certifications for Architects, Scrum Masters, Train Engineers, Software Engineers, and DevOps.
Should You Use the Scaled Agile Framework?
SAFe is most-popular among enterprise organizations as many of its facets focus on eliminating the common challenges teams face when scaling agile.
In other words, if your company is just beginning to transition to agile, SAFe might be a viable option to bridge that gap because of its more prescriptive approach than, say, Disciplined Agile (DA), which offers more flexibility and customization but also requires an organization fully understand the agile philosophy already.
But, it is worth noting, however, that SAFe’s top-down approach to decision making and project management can undermine some of the core agile principles—such as collective ownership, adaptiveness, and less fixed roles—that might have attracted your team to agile in the first place.
See also: Scrum Agile Framework, Agile Values, Agile Transformation, Disciplined Agile (DA)