You just have to have the guidance to lead you in the direction until you can do it yourself.
— Tina Yothers
Agile Development in High-Assurance and Regulated Environments
This white paper describes the use of Agile development in high-assurance (medical, regulated, aerospace) environments. Since Agile is a superior method for ensuring quality and efficacy, it shouldn’t be a surprise that Agile development is recommended here, too. [wpdm_file id=68]
A Lean Perspective on SAFe Portfolio WIP Limits
Although SAFe provides high-level guidance on WIP limits at the portfolio level, there are important nuances that are key to understanding how the portfolio level in SAFe is work in process (WIP) limited. In this article, SPCT Eric Willeke describes four ways in which SAFe provides implicit and explicit WIP limits at the portfolio level.
This article describes an approach to Agile contracting that can better enable Lean and Agile development in a cooperative Customer-Supplier relationship based on trust and transparency.
Lean-Agile thinking is spurring the industry to break down development silos and provide a more continuous flow of value from concept to delivery. 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, what’s needed is not just continuous development flow but continuous delivery, as described in this article by SPC Scott Prugh. Also check out this video on the same topic by Scott Prugh from DevOps Enterprise Summit 2014.
Design for Testability: A Vital Aspect of the System Architect Role in SAFe
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. As this article describes, systems that are “designed for testability” are higher quality, more trustworthy, more easily modified, and more Agile.
Domain modeling is a way to describe and model real-world entities and the relationships between them. As described in this article, domain modeling helps practitioners design systems for maintainability, testability, and incremental development by identifying the primary domain entities and their relationships.
Features and Components
When scaling Agile development, features and components are the key paradigms around which to organize Agile teams. While SAFe leans heavily toward feature teams, as those exhibit the highest short-term velocity, 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 that drive business value and typically cross 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 blobs of work, they must be implemented incrementally to achieve the benefits of agility, as this article describes.
Lean-Agile Financial Planning with SAFe: The Original White Paper
Download the original white paper that spawned Lean-Agile Budgeting in SAFe.
Mixing Agile and Waterfall Development in the Scaled Agile Framework
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 (what is?), but it’s doable, as this important guidance article illustrates. Also see the follow-up article (below), “Technical Strategies for Agile and Waterfall Interoperability at Scale.”
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 important, the courageous people who drive change, and some of the interesting situations they face.
Software grows and ages over time, becoming harder and more expensive to maintain and increasingly unable to incorporate new functionality. This article describes refactoring as the process of restructuring and improving existing code without changing the external behavior. It extends the life of the system, lowers maintenance costs, and increases team velocity. It is essential to the art and discipline of effective Agile development.
Spikes are a special type of enabler story in SAFe. Originally defined within XP, spikes are used for activities such as research, design, investigation, exploration, and prototyping. The purpose of a spike is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.
Technical Strategies for Agile and Waterfall Interoperability at Scale
In this follow-up article to “Mixing Agile and Waterfall Development in the Scaled Agile Framework” (above), Alex Yakyma describes four mechanisms for better linking the teams and the code in mixed-mode development
Test-first is the practice of developing and testing a system in small increments, often with the development of the test itself preceding the development of the code or component. In this way, tests serve to elaborate and better define the intended system behavior before the system is built, thereby enhancing quality.This article describes a comprehensive approach to Agile testing, and testing first, based on Brian Marick’s four-quadrant Agile Testing Matrix.
The Role of PI Objectives
In this article, Eric Willeke describes the role and importance of PI objectives, as well as why teams commit to objectives rather than to features. It also describes three attributes of PI objectives that make them highly valuable in aligning to the business and helping Agile Release Trains achieve better business outcomes.
The SAFe Way to Lean Software Development
In addition to 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 implicit explicit, with the hope that it will further guide those doing this critical work toward the lightest and leanest effective implementations. (Note: this article is based on SAFe 3.0.)
What’s New in SAFe 4.0
SAFe 4.0 is a major milestone for the framework. It incorporates learning from all prior releases (including the SAFe for Lean Systems Engineering branch) into a single, more scalable, and more modular framework. It supports both software and systems development, from the modest scale of well under 100 practitioners to solutions that require thousands of people to create and maintain. This short article describes the highlights of what’s new in SAFe 4.0.
SAFe Requirements Model
SAFe is, itself, a system. Underlying the system is a well-defined set of requirements and test types, artifacts, and relationship 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. This supplemental model provides the technical details about these important elements and their relationships in SAFe.
Last Update: 3 December 2015