Guidance

Building enterprise class software systems is one of the world’s most complex endeavors. To help address this challenge, the Scaled Agile Framework is broad and deep, and the Big Picture graphic cannot possibly capture every concept that is material to understanding or implementing SAFe. To that end, we offer these pages as additional guidance on topics that deserve additional, focused discussion.

Agile Development in High Assurance and Regulated Environments.  Below is a white paper on the use of Agile development in high assurance (medical, regulated, aerospace) environments. Since Agile is the best method we have found to assure quality and efficacy, it shouldn’t be a surprise that we recommend Agile development here, too. In the white paper, we did the homework necessary to debunk the myth that these environments mandate waterfall development, as nothing could be further from the truth. The attached white paper lays out the case. In addition, as Rally Software commissioned the work, it  shows how tooling can support many of the reports and documents that are typically required in such environments.

 

Capitalization of Software Development Costs. Capitalization practices are well established in waterfall development, as the up-front requirements and design phases represent the stage gates that must be passed before capitalization can occur. In Agile development however, these processes are often continuous and there are typically no such formal stage gates. In its place, this article describes three possible approaches to capitalization in the SAFe context, each with increasing granularity, including Capitalization by Percentage of ART Costs,  Capitalization by Story Points, and Capitalization by Task Hours.

Continuous Delivery. SAFe and Lean-Agile thinking and practices is spurring the industry to break down development silos and provide a more continuous flow of value from concept to tested code. The promise, however, is more than that—the promise is to deliver value to customers faster, not just create internal product inventory at an ever-faster pace.  For this we need not just continuous development flow, but continuous delivery. (Update: also check out this Video on the same topic by Scott Prugh from DevOps Enterprise Summit 2014).

Core Values. SAFe is broad and deep and based on both Lean and Agile Principles. That’s what it’s built on, but what does SAFe itself stand for? In this short article, you’ll see the four things we really value that SAFe helps deliver: Alignment, Code Quality, Transparency and Program Execution. When you do those things well, a lot of goodness will surely follow.

Designing for Testability. If a system can’t be routinely and (mostly) automatically tested and regression tested, development progress will be slow and will likely become continuously slower over time. Systems that are “Designed for Testability” (and refactored as necessary to continuously achieve it) are higher quality, more trustworthy, more easily modified, and more Agile.

Domain Modeling. If you are only going to model one thing in your lightweight and more agile endeavors to build really big systems, surely this is the one you need.

Features and Components. Software systems can be considered from two critical aspects: structure and behavior. Structure describes the components of the software system and the way they are organized into the whole. Behavior describes the features that deliver end user benefit. When scaling Agile development, features and components are the key paradigms around which to organize Agile teams. While Agile and SAFE lean towards feature teams, as those exhibit the highest velocity of value delivery—at least in the short term—this article illustrates how a balanced mix of feature and component teams enables a fast and sustainable flow of value.

Implementation Strategies for Business Epics. Business epics are large initiatives in SAFe that drive business value and typically cross the organizational boundaries (release trains), time boundaries (PIs), or both. It is a key capability of the agile enterprise to properly analyze and sequence business epics for implementation. While it’s easy to think of epics as big, binary, monolithic, committed blobs of work, the reality is they should be implemented incrementally to achieve the benefits of agility. Moreover, once the technology, benefits, and economics are understood, some won’t deserve to be fully implemented, as the initial effort delivers most of the potential business value.

Kanban for SAFe Teams. Originally a technique derived from lean manufacturing, Kanban is a lightweight way of visualizing and managing work of any kind. It’s easy to adopt for software development, and provides sophisticated constructs for continuing improvement as teams master the method.  Kanban provides a granular view of the flow of work through the team, illustrates bottlenecks and delays to be addressed, and increases flow by application of work-in-process limits. This article describes how Kanban can used by SAFe Teams in the content of their Agile Release Train.

Lean Software Development in SAFe. In addition to the primary feedback from practical experience, the underlying theory and principles of SAFe are based on three contemporary bodies of knowledge: Agile development, Lean Systems Thinking, and the Principles of Product Development Flow. While these principles and values are implicit in SAFe, this guidance article makes the explicit implicit, with the hope that it will further guide those doing this critical work to lightest and leanest effective implementations.

Lean-Agile Financial Planning with SAFe: The Original White Paper. In this article, you’ll find some context and be able to download the original white paper that spawned Budgets in SAFe 3.0.

Mixing Agile and Waterfall Development. Agile development delivers better results in quality, productivity, employee engagement and time to market. But it takes time for an enterprise to get there. In the meantime, Agile development programs will need to coexist, and even be dependent on, programs using the traditional waterfall method. It’s not easy, (but what is?) but it’s doable, as this important guidance article illustrates.

Mixing Agile and Waterfall: Technical Strategies for Interoperability at Scale. In this follow up article to the above, Alex Yakyma describes four mechanisms for better linking the teams and the code, in mixed-mode development.

Pacific Express, In this short story, Alex Yakyma describes the launching of a (mostly) fictional Agile Release Train as part of an initial SAFe adoption and, most importantly, the courageous people that drive change and some of this interesting situations they face.

Supplemental Models

SAFe is itself, a system. Underlying the system is a well-defined set of requirements and test types, artifacts, and organizational models that tie it all together. This “semantic backplane” is used by those implementing SAFe for managing investments, defining and tracking requirements, implementing test automation and test coverage, implementing tooling and traceability, and providing for reporting and metrics. The following Supplemental Models provide the technical details on these important elements and their relationships in SAFe.

Agile Software Requirements Model. When you want to scale Agile development, you’ll need requirements abstractions that provide for understanding investments, and requirements terms that can carry just-the-right-amount of specified system behavior for Teams, Programs and the Portfolio, as well as defining the testing terms and practices you’ll need to assure quality at all three levels. The Agile Software Requirements model provides this for SAFe.

 

Last Update: 20 August, 2014

Leffingwell et al. © 2011-2014 Scaled Agile, Inc.

Information on this page is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.


XSLT by CarLake