Find people who share your values, and you’ll conquer the world together.
—John Ratzenberger
The four Core Values of alignment, built-in quality, transparency, and program execution are the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.
SAFe is broad and deep and based on both Lean and Agile principles. That’s its foundation—but what are its beliefs?
SAFe upholds four Core Values: alignment, built-in quality, transparency, and program execution. These values are illustrated in Figure 1 and described in the following sections.
Like cars out of alignment, misaligned companies can develop serious problems. They are hard to steer, and they don’t respond well to changes in direction [1]. Even if it’s clear where everyone thinks they’re headed, the vehicle is unlikely to get them there.
Alignment is needed to keep pace with fast change, disruptive competitive forces, and geographically distributed teams. While empowered Agile teams are good (even great), the responsibility for strategy and alignment cannot rest with the combined opinions of the teams, no matter how good they are. Instead, alignment must rely on the enterprise business objectives. Here are some of the ways how SAFe supports alignment:
It starts with strategy and investment decisions at the portfolio and is reflected in Strategic Themes and the Portfolio Backlog. In turn, this informs the Vision, Roadmap, and backlogs at all level of SAFe. Continuous Exploration gathers the inputs and perspectives from a diverse group of stakeholders and information sources to ensure that the items in the backlogs contain economically prioritized and refined work that is ready for teams to implement. All work is visible, debated, resolved, and transparent.
SAFe is supported by clear lines of content authority, starting with the portfolio and then resting primarily with the Product and Solution Management roles and extending to the Product Owner role.
PI Objectives and Iteration Goals are used to communicate expectations and commitments.
Cadence and synchronization are applied to ensure that things stay in alignment, or that they drift only within reasonable economic and time boundaries.
Architectures and user experience guidance and governance help ensure that the Solution is technologically sound, robust, and scalable.
Economic prioritization keeps stakeholders engaged in a continuous, agreed-to, rolling-wave prioritization, based on the current context and evolving facts.
Alignment, however, does not imply or encourage top command and control. Just the opposite, in fact: Alignment enables autonomy and decentralized decision-making, allowing those who implement value to make better local decisions.
W. Edwards Deming famously said, “Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.”
Built-in Quality ensures that every increment of the solution reflects quality standards. Quality is not ‘added later.’ Building quality in is a prerequisite of Lean and flow; without it, the organization will likely operate with large batches of unverified, unvalidated work. Excessive rework and slower velocities are likely to be the unhappy results. There can be no ambiguity about the importance of built-in quality in large-scale systems: It is mandatory.
Put simply, ‘you can’t scale crappy code.’ The Agile Manifesto certainly focused on quality: “Continuous attention to technical excellence and good design enhances agility” [2]. Addressing software quality in the face of rapid change requires evolving effective practices, and Extreme Programming (XP) inspires much of the framework’s guidance:
Test-First: Test-Driven Development (TDD), Acceptance Test-Driven Development (ATDD), and Behavior-Driven Development (BDD)
Continuous Integration and Continuous Deployment
Refactoring
Pair work
Collective ownership
Coding concerns aside, no one can scale crappy components or systems, either. Hardware elements—electronics, electrical, fluidics, optics, mechanical, packaging, thermal, and many more—are a lot less ‘soft.’ Errors here can introduce a much higher cost of change and rework. To avoid this, the following practices are recommended:
Frequent design cycles and integration [3]
Collaborative design practices
Model-Based Systems Engineering (MBSE)
Set-Based Design (SBD)
Investment in development and test infrastructure
Eventually, different components and subsystems—software, firmware, hardware, and everything else—must collaborate to provide effective solution-level behaviors. The following practices support solution-level quality:
Frequent system- and solution-level integration
Solution-level testing of functional and Nonfunctional Requirements
System and Solution Demos
Enterprises use SAFe to build some of the world’s largest and most important systems, many of which have unacceptable social or economic costs of failure. Protecting the public often requires applying extensive regulatory or customer oversight and rigorous compliance requirements. To that end, SAFe enterprises that build high-assurance systems define their approved practices, policies, and procedures in a Lean Quality Management System (QMS). Such a system is intended to ensure that development activities and outcomes comply with all relevant regulations and quality standards, as well as provide the required documentation to prove it.
In contrast, most Agile development teams typically do not create the same formal artifacts. Instead, they use the team backlog, persistent test cases, and the code itself to document system behavior. However, in the compliance context, it is clear that an organization needs to develop and maintain a Software Requirements Specification (SRS) to support verification and validation without it. The mere fact that an SRS is needed does not necessarily mandate that it be created up-front, in a large batch. That is, the required documentation and artifacts can be incrementally built by Agile teams, as part of the regular flow of work, using Agile tooling and automation, whenever possible. For example, Agile tools can be used to generate an SRS or traceability matrix.
Solution development is hard. Things may go wrong or not work out as planned. Without openness, facts can be obscured and result in decisions based on speculative assumptions and lack of data. No one can fix a secret.
For that outcome, trust is needed, because without trust no one can build high-performance teams and programs, or build (or rebuild) the confidence needed to make and meet reasonable commitments. Trust exists when one party can confidently rely on another to act with integrity, particularly in times of difficulty. Without trust, working environments are a lot less fun and motivating.
Building trust takes time. Transparency is an enabler of trust, provided through several practices:
Executives, portfolio managers, and other stakeholders can see the Portfolio Kanban and program backlogs, and they have a clear understanding of the PI objectives for each ART or Solution Train.
ARTs have visibility into the team’s backlogs as well other program backlogs.
Teams and programs commit to short-term, visible commitments that they routinely meet.
Inspect and Adapt workshops with all relevant stakeholders create a backlog of improvement items from lessons learned.
Teams and Agile Release Trains (ARTs) can see portfolio business and enabler epics. They have visibility into new initiatives.
Progress is based on objective measures of working solutions.
Everyone can understand the velocity and Work in Progress (WIP) of the teams and programs; strategy and the ability to execute are visibly aligned.
Of course, none of the rest of SAFe matters if teams cannot execute and continuously deliver value. Therefore, SAFe places an intense focus on working systems and business outcomes. History shows us that while many enterprises start the transformation with Agile teams, they often become frustrated as those teams struggle to deliver more substantial amounts of solution value reliably and efficiently.
That is the purpose of the ART, and that is why SAFe focuses implementation initially at the Program Level. In turn, the ability of Value Streams to deliver value depends on the ability of the ARTs and Solution Trains.
Fortunately, with alignment, transparency, and built-in quality on the team’s side, they have a little ‘wind at their back.’ That enables a focus on execution. And if they struggle—and they will, because complex solution development is hard—they can rely on the Inspect and Adapt workshops to close the loop and execute better and better during each Program Increment.
Of course, program execution cannot just be a team-based, bottom-up thing. Successful Lean-Agile development at scale requires the active support of Lean-Agile Leaders, who couple their leadership with an orientation toward customer results. In turn, that creates a persistent and meaningful context for the teams and their stakeholders.
That’s the way the successful teams and programs are doing it, and that’s why they are getting the many benefits—employee engagement, productivity, quality, and time-to-market—that Lean-Agile enterprises so enjoy.
LEARN MORE
[1] Labovitz, George H., and Victor Rosansky. The Power of Alignment: How Great Companies Stay Centered and Accomplish Extraordinary Things. Wiley, 1997.
[2] Manifesto for Agile Software Development. http://AgileManifesto.org.
[3] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
