Due to its prosperity in the software industry, Agile no longer needs an introduction: in the past decade or so, seemingly everyone has been talking about this modern framework. Having recognized the success that small and mid-sized companies are realizing by using Agile, a growing number of large enterprises are also looking to adopt this framework. Their only concern tends to be that Agile’s very definition seems to go against everything that enterprises hold dear. The clunky business of plans, processes, tools and documentation are all abandoned by Agile, leaving global organizations wondering how they could reap the benefits of Agile/Scrum without unleashing chaos among their neatly controlled teams.
The Challenge of Scaling Agile
Worshippers of “true” Agile argue that scaling this framework (and those that build on it: Scrum, XP, etc) is actually pretty simple: you should just let your self-organizing teams and units decide what’s best for them, and trust them to improve their own work. While this may actually be true, it’s understandable that most managers are wary of letting go of all control. For them, various approaches and frameworks have been devised that let enterprises make the transition to Agile in a painless and (more or less) structured process.
Large-scale Scrum (LeSS)
Large-scale Scrum (LeSS) was created by Craig Larman and Bas Vodde in 2005 to help organizations implement Scrum in their development. It includes two frameworks, the first of which applies to smaller companies (up to 10 Scrum teams, with 7 members each), while Framework-2 works for up to a few thousand people on one product.
LeSS can be thought of as regular Scrum applied in multiple levels to suit large-scale development: it is a minimal framework that offers a high degree of flexibility at implementation. It is non-prescriptive, and merely gives suggestions. LeSS builds on “basic” Scrum in that it recommends organizing several feature teams under one Product Owner (PO). Framework-2, also referred to as LeSS Huge, then adds further APOs (Area POs) to enable scaling. Teams are coordinated with Sprint Planning meetings, and further meetings may be added to help collaboration.
LeSS is a great choice for small organizations that are growing quickly, and are looking for a framework that helps scale Scrum along with their organization. It allows flexibility over rules, which is both its advantage and its major risk factor: large enterprises may shy away from it in favor of a more structured framework.
Disciplined Agile Delivery (DAD)
Let’s start with a basic definition: according to the framework’s homepage, “Disciplined Agile Delivery (DAD) process decision framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.” Disciplined Agile Delivery is a recent method (developed between 2006-2012) based on the book with a similar title by Scott Ambler and Mark Lines that aims to fill in the process gaps that Scrum ignores.
Hybrid, in this case, means that DAD is practically a modification of Scrum with elements added from a variety of other methods: Agile Modeling, Extreme Programming (XP), Kanban, Lean, and other Agile-related approaches. It splits the process of development into phases of Inception, Construction and Transition, and recommends to appoint an Architecture Owner.
Consequently, DAD has its strengths in architecture, design and DevOps. On the other hand, it’s considered vague in some areas – more specifically, some argue that DAD’s documentation is lacking coherence and fails to answer the ‘how’s, thus it doesn’t really help the implementation process.
Scaled Agile Framework (SAFe®)
SAFe® is probably the most well-known of these three methods. Developed by Dean Leffingwell, the Scaled Agile Framework is a highly structured and prescriptive method that helps large enterprises set out on the road to Agile. While it has been getting a lot of attention lately following successful implementation by a number of companies worldwide, SAFe® has had to face criticism by renowned Agile experts.
Most critics argue that SAFe® lacks dedication to true Agile values: they claim that it merely adds a layer of Agile on a preexisting organizational hierarchy. Thus, it lets managers make decisions instead of those who actually understand the problem as they are working on it. As a consequence, some believe that the Scaled Agile Framework isn’t actually true Agile.
That said, SAFe® is in fact an increasingly popular framework that is successfully and efficiently used by companies in various industries. It is the go-to option for large, software-intensive projects where teams are highly interdependent. Even its critics tend to agree that some Agile is better than no Agile: SAFe® shouldn’t be though of as the goal of a company’s Agile efforts; rather, it’s a first step on the way to the enterprise-wide adoption of Agile.
The Scaled Agile Framework differentiates between Team, Program, and Portfolio levels. At the Team level, SAFe® is not that different from simple Scrum extended with a few XP practices. The Program level aligns the teams to form an Agile Release Train, while the Portfolio level aligns the ART with the strategic goals of higher management.
codeBeamer ALM is the first proven implementation of SAFe®. Its advanced features support the processes of all three levels identified by the Scaled Agile Framework. codeBeamer’s demand management functionality helps identify, prioritize and track requirements across departments, its features support collaboration to help align the teams that form the Agile Release Train. Developers on the Team level will benefit from its integrated requirements management, development management, and QA & test management features.
SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile Inc.
SAFe® 4.0 Introduction – Overview of the Scaled Agile Framework® for Lean Software and Systems Engineering