You just have to have the guidance to lead you in the direction until you can do it yourself.
— Tina Yothers
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.
Agile Architecture is a set of values and practices that support the active evolution of the design and architecture of a system, concurrent with the implementation of new business functionality. With this approach, the architecture of a system, even a large system, evolves over time while simultaneously supporting the needs of current users.
Agile HR with SAFe
Lean-Agile development with SAFe reinvents the way we develop systems and helps build an engaged, talented, and vigorous workforce. But it also highlights the disconnect of traditional practices with the realities of 21st Century people and organizations. This short guidance article summary and downloadable whitepaper describes six basic themes on how to implement various aspects of more contemporary Lean-Agile People solutions with SAFe.
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.
Building High-Assurance Systems with SAFe 4.0
Many software and system enterprises build “high assurance” systems, systems that have an unacceptably high social or economic cost of failure. Most of these systems are subject to regulatory or industry standards and compliance, including design assurance and verification and validation. Can these be addressed with Agile, Lean, and SAFe? Assuredly.
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.
Continuous integration is a practice whereby team members integrate and validate their work frequently; in the case of software, this can occur at least daily or even multiple times per day. Where possible, integration is verified by automated build and test environments that quickly identify integration problems and defects.
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.
Essential SAFe is a subset of the complete SAFe Big Picture that describes the ten minimal elements necessary to be successful. If you are incorporating these ten essential elements into your Lean-Agile transformation, you’re well on your way to realizing the full benefits of SAFe.
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.
Invitation-based SAFe Implementation
Yuval Yeret explains how invitation-based implementation can solve the Agile imposition of implementing Agile by imposing ways of working on programs and teams. The guidance article provides ways to invite leaders and team members to understand SAFe, while leaving the timing and details of the changes in their hands.
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.
Portfolio Planning Tool
Given the criticality of the Agile Release Train to value delivery in SAFe, SAFe has always provided fairly extensive guidance on PI Planning. With 4.0, we introduced planning for larger Value Streams that require multiple Agile Release Trains. However, SAFe hasn’t yet provided much guidance for the actual planning process that occurs at the Portfolio Level. This article fills that gap a bit. In so doing, it also introduces a simple tool to help facilitate the portfolio planning process.
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.
Role of SAFe Program Consultant
SAFe Program Consultants (SPC) are change agents who combine their technical knowledge of SAFe with an intrinsic motivation to improve their company’s software and systems development processes. SPCs are integral and critical to successful SAFe implementations. This guidance article provides an overview of the role of the SPC in implementing SAFe.
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.
Six SAFe Practices for ‘S-Sized’ Teams
Can SAFe be applied efficiently to smaller development shops? In a word, yes. In this Guidance article, experienced SAFe practitioner Juha-Markus Aalto describes the benefits of applying SAFe to a growing, entrepreneurial, new technology venture.
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.
Last Update: 2 December 2016