guidance-icon

You just have to have the guidance to lead you in the direction until you can do it yourself.

— Tina Yothers

Guidance Articles

 

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
Agile architecture is a set of values and practices that advances the design and architecture of a system while implementing new business functions.

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.

Agile Contracts
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.

CapEx and OpEx
Capital Expenses (CapEx) and Operating Expenses (OpEx) describe Lean-Agile financial tracking practices in a Value Stream budget. This article provides strategies that SAFe enterprises can use to categorize labor costs in Agile development, some of which may be subject to CapEx treatment.

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
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.

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.

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.”

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.

Refactoring
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.

Right-Sizing Features for SAFe Program Increments
One of the key activities that will help make your SAFe program a success is the careful preparation of your Features prior to Program Increment (PI) planning. And one important aspect of this preparation is to slice up any of the targeted features that are too large to be easily delivered within a PI. In this guidance article, we will share some of our experiences in slicing features into smaller ones.

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
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
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.

What’s New in SAFe 4.5
SAFe 4.5 is leaner, more agile, and fosters faster innovation and learning. It helps enterprises get better, faster, business results on a reliable basis. At the same time, SAFe 4.5 is backwards compatible with SAFe 4.0, which means organizations can adopt the new practices introduced in SAFe 4.5 at their own pace to improve their results. This article describes the changes to SAFe that were made in the 4.5 release.


Last Update: 10, June, 2017