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 whitepaper on the use of Agile development in high assurance (medical, regulated, aerospace) environments. Since Agile is the best method yet we have found to assure quality and efficacy, it shouldn’t be a surprise that I recommend Agile development here, too. In the whitepaper, 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 whitepaper 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 and 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.
Core Values. SAFe is broad and deep and is 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, al 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 (PSIs), 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.
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 Whitepaper. In this article, you’ll find some context and be able to download the original whitepaper 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.
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
© 2010-2014 Leffingwell, LLC. All rights reserved.