The impact of agile development practices in modern software development cannot be overstated. The traditional “waterfall” software development methodology was characterized by complete, upfront design prior to coding, and deferred product testing to the end of a lengthy development cycle. Waterfall approaches have been associated with software project delays, inability to adequately react to changing requirements and poor quality software. The agile approach still most succinctly summarized in the 2001 “Agile Manifesto”broke this logjam of waterfall software development by expecting and embracing changing requirements, emphasising working software rather than extensive documentation, preferring collaboration to contracts, and encouraging self-organizing teams rather than detailed explicit processes.
In Scrum, the most widely adopted agile process, teams typically deliver increments of potentially shippable product in short two- to three-week sprints. This potentially allows software to be shipped at any time since there always is something ready to ship and allows course corrections during the project, as each sprint is relatively self-contained and not predetermined in scope. Today, it’s unusual to find a professional software development organization that is not using some form of Scrum.
As successful and influential as agile has become for software development, it is still somewhat at odds with the broader business lifecycle in which it resides. Business leaders and product managers generally still expect to create a master plan for a product, marketing departments expect to have advance notice and firm commitments on product features, and sales organizations often want to provide accurate guidance to customers regarding future product features. And, of course, there are multiple stakeholders at every level who want to sign off on every feature. These forces tend to result in scrum/agile processes becoming embedded in what is effectively a waterfall business process.
The Scaled Agile Framework (SAFe) provides a recipe for adopting agile principles at the enterprise level. It defines a set of processes and roles that are inspired by the agile development process, but have clearly defined roles and responsibilities for all the players in the enterprise. A diagrammatic representation of the process can be found at scaledagileframework.com. SAFe was originally developed by Dean Leffingwell, founder of Scaled Agile Inc., a company that promotes and provides commercial support for the process.
Scaled Agile Inc. provides case studies on the use of SAFe in many significant organizations, including Lego, Telstra, Accenture, BMC, and John Deere. A recent report on global quality assurance from Capgemini noted that 42% of its customers who have adopted agile also have adopted SAFe at some level.
SAFe defines three levels of process: portfolio, program, and team
The portfolio level provides strategic direction, investment and governance. It defines Strategic Themes that provide business context for lower layers, as well as oversight of high-level execution. The strategic themes drive investment into various value streams, and help define Business Epics that describe how these streams combined to achieve strategic objectives. The portfolio process is managed by a Kanban methodology that resembles Scrum, but without a sprint structure.
At the program level, value streams are fed into long-lived Agile Release Trains. These release trains resemble Scrum sprints, but deliver larger, more complete business solutions. The release train periodically delivers a business level shippable increment. While a Scrum sprint typically takes two to three weeks, a release train spans multiple sprints and may take about 10 weeks.
At the team level, smaller teams work using traditional Scrum and agile methodologies, delivering fully tested product increments every two weeks.
Few of us working in the software industry would dispute that agile methodologies represent a superior approach to older waterfall-style methods. However, many software developers would agree that older enterprise-level processes often interact poorly with the agile methodology, and long for agility at the enterprise level. SAFe is an attempt to define such an Agile Enterprise.