SAFe Requirements Model (v6) - Program Level

What is the Scaled Agile (SAFe) Program Level?

The SAFe Program Level is where Agile teams and stakeholders collaborate to deliver fully integrated, potentially shippable increments of a system or product.

The Scaled Agile Framework (SAFe) Program Level is the second level of the SAFe model, where multiple Agile teams come together to deliver value through working, tested software. The Program Level operates under a construct known as an Agile Release Train (ART), which is a long-lived team of Agile teams that plans, commits, develops, and deploys together in synchronized iterations or Program Increments (PIs). This level provides the organizational structure, roles, and practices necessary to amplify the power of Agile development, enhancing cross-functional collaboration and alignment and delivering significant systems and solutions.

What are the SAFe Program-level Objectives?

The SAFe Program level has the following 6 Objectives:

1. Sustaining the Vision and Roadmap: Constantly defining and communicating the program’s Vision while maintaining a Roadmap so that teams work towards a shared goal.
2. Release management: Coordinating the efforts of multiple teams to develop release increments based on the enterprise’s chosen development cadence.
3. Quality management: Ensuring the combined results (the system) of the teams are consistently integrated; that performance, security, reliability requirements, and any imposed external standards are met.
4. Deployment: Since teams might not have the ability, scope, or authority to deploy systems to end-users, this crucial activity must be managed at the Scaled Agile Program level.
5. Resource management: Adapting resources to address constraints and bottlenecks in the program’s capacity to deliver value promptly.
6. Eliminating impediments: Program leaders and managers are accountable for resolving obstacles that arise from teams—critical issues beyond the team’s control.

We must introduce additional resources and processes to achieve this broader objective at this level. We’ll explore these practices in this post.

How does SAFe organize multiple teams?

A basic question for organizing agile teams is optimizing value delivery. In smaller enterprises, teams naturally form around products or applications, and agile team establishment involves defining roles and providing training.

At scale, however, determining who works on what and where is challenging. Team organization could be based on features, components, product lines, services, or other factors. No simple answer exists, but this must be addressed as numerous agile practices, including backlog management, communication of vision and features, and team coordination for larger solutions, depend on this decision.

What is the difference between Feature teams and Component Teams?

Feature teams deliver complete customer-centric features across components, while Component teams work on specific parts of a product’s architecture.

Feature teams and Component teams represent different organizational structures in Agile development. Feature teams are cross-functional and have all the skills to design, develop, test, and deliver end-to-end customer-facing features. They work across different product components, aligning their work with customer needs and customer value. On the other hand, Component teams focus on specific subsystems or components of a product’s architecture. Their work can be technical and might not directly deliver customer-facing value. While both have their uses, Feature teams are generally preferred in Agile for their ability to deliver complete increments of customer value.

What are Component Teams?

Component teams are specialized groups focused on developing specific subsystems or components of a product.

Component teams in SAFe are specialized in developing and maintaining a specific subsystem or component of a product. Their work is often technical and may not directly deliver customer-facing value. While these teams can provide deep expertise in their area, the component-based focus can sometimes lead to challenges with coordination, integration, and achieving an end-to-end flow of value. They are often necessary when certain product areas require deep technical expertise.

Component-based organizations can be efficient in agile enterprises for the following four reasons:

1. They may already be organized around specialists with similar skills and interests.
2. Teams might be co-located, simplifying communication and reducing data handoff.
3. Technologies and languages may differ across components, complicating feature team collaboration.
4. Single-user features can impact multiple teams at scale, making feature-based organizations vague.

What are Feature Teams?

Feature teams are cross-functional groups that work on customer-centric features across a system’s components.

In the Scaled Agile Framework (SAFe), Feature teams are cross-functional groups that can deliver complete, customer-facing features from beginning to end. They consist of all necessary roles and skill sets to analyze, design, develop, test, and deliver a feature. By working across the different components of a product, these teams can better align their work with delivering customer value, thereby improving efficiency, reducing hand-offs, and enabling faster feature delivery.

The almost universally favored approach for organizing agile teams is to arrange them around features.

Deploying feature teams have the following five benefits:

1. Teams develop expertise in the system’s actual domain and usage mode, generally accelerating the value delivery of any given feature.
2. There is less overhead since teams don’t have to exchange backlog items to ensure a feature is implemented, and there are significantly fewer interdependencies between teams.
3. Planning and execution become leaner.
4. The team’s core competence shifts to the feature (or set of features) rather than a single aspect of the technology stack.
5. The team’s backlog is simplified, simultaneously focusing on just one or two features.

This approach undoubtedly promotes the rapid delivery of high-value-added features!

Which is better, Feature Teams or Component Teams?

Considering the advantages and disadvantages of each approach, the answer isn’t always evident. However, with Agile’s emphasis on immediate value delivery, there is a natural inclination toward feature teams.

The Best Answer Is Likely a Mix. In larger enterprises with numerous teams and countless features, and one should consider the factors mentioned earlier and choose the best strategy for your specific context. In most cases, as you can see, the answer will likely involve a mix of feature and component teams.

Given that a mix is most likely appropriate, two main factors influence the mix: the practical limitation of the degree of specialization required and the economics of potential reuse.

What is a system team?

System teams provide technical support and assistance to other teams, facilitating integration, testing, and DevOps practices.

System teams in the SAFe context are specialized teams that support the development environment, assist in integration and testing, and facilitate DevOps practices. Their primary role is to ensure the smooth operation of the Continuous Delivery Pipeline and the release of solutions. They work across Agile Release Trains (ARTs) and Solution Trains, aiding in a solution’s construction, testing, deployment, and operation. They’re not tied to specific features or components but support the overall system’s performance.

At the Scaled Agile Program level, individual teams might not have all the necessary capabilities to integrate, test, and deploy a complete solution. As a result, an additional supporting team, known as a system integration, QA and deployment, release team, or system team, addresses these needs, working at the same pace and handling specific system-level responsibilities.

• System-Level Testing: The system team develops skills for end-to-end testing of larger features and use cases, as individual teams may struggle to test within the entire system context.
• System Quality Assurance: The system team tests nonfunctional and quality requirements against various customer-supported platforms and environments, as many teams lack the necessary specialty skills.
• System-Level Continuous Integration: For large systems, teams may struggle to provide daily utility for complete system builds independently.
• Building Development Infrastructure: The system team ensures commitment, visibility, and accountability for configuration management, automated builds and deployment, and automated build verification tests, supporting the agile transition.

What is a Release Management Team?

Release teams manage the coordination and delivery of software releases to the market.

Release Management teams are responsible for managing and coordinating the software release process. They ensure that developed features are integrated, tested, and ready for delivery to the market. Their role may include coordinating release schedules, managing dependencies, handling risks, and ensuring compliance with quality standards. They play a crucial part in the value delivery pipeline’s final stages, helping ensure that releases are executed smoothly and successfully.

The Release Management Team addresses release governance and includes critical stakeholders such as line-of-business owners, product managers, sales and marketing representatives, line managers, IT and deployment resources, QA personnel, and system architects. They meet on a regular cadence to drive the following 5 objectives:

1. Ensure teams understand their mission
2. Confirm comprehension of the solution being built
3. Assess the release’s status
4. Address obstacles to progress
5. Evaluate release schedule adherence and adjust scope if needed

This team provides senior management insight, makes scope, timing, or resource adjustments, and serves as the agile enterprise’s final authority on release governance. This team can also make any scope, timing, or resource adjustments needed to support the release. In this way, the release management team serves as the final authority on all release governance issues and constitutes an integral part of the agile enterprise.

To read more about team empowerment and autonomy, click here.

What is the role of Product Management at the SAFe Program level?

Product Management in SAFe at the Program level is responsible for defining and prioritizing the Program Backlog, and working with customers and stakeholders to understand their needs and translate them into features.

In the Scaled Agile Framework (SAFe), Product Management defines, prioritizes, and refines the Program Backlog, which contains upcoming features to be developed by the Agile Release Train (ART). They work closely with customers and other stakeholders to understand their needs and translate them into value-added features. They collaborate with System Architects to ensure that solution intent is met and participate in PI Planning, Inspect and Adapt (I&A) workshops and routine backlog refinement sessions. They play a key role in aligning teams to the customer’s needs and strategic objectives.

What is the Product Vision in SAFe?

The Product Vision in SAFe is a brief declaration of a product’s future state or goal, providing direction and inspiration to the teams.

The Product Vision acts as a guiding light, providing direction for the Agile teams and helping them understand the purpose of their work. The vision is intended to be aspirational, motivating teams to work towards a common goal. It is usually developed by the Product Manager or Product Owner in collaboration with stakeholders and is used as a tool for decision-making and prioritization throughout the product development process.

In SAFe, the Product Vision addresses the following six questions:

1. What is this program’s strategic intent?
2. What problem will the application, product, or system resolve?
3. What features and benefits will it offer?
4. Who will it cater to?
5. What performance, reliability, etc., will it deliver?
6. What platforms, standards, applications, etc., will it support?

Since the product and software requirements specification documents and the like are unlikely to exist, directly communicating the Vision for the Scaled Agile program must take a different form. Agile teams take a variety of approaches to communicating the Vision. These include the following: 

1. Vision document 
2. Draft press release 
3. Preliminary data sheet 
4. Backlog and Vision briefing

What are SAFe Product Features?

In SAFe, Product Features are serviceable components of value, typically delivered in a single program increment.

Within the Scaled Agile Framework, a Product Feature represents a chunk of business functionality that has a tangible benefit and can be developed and delivered in a single Program Increment (PI). Features provide a language in which all stakeholders can describe and understand system-level behaviors. They are maintained in the Program Backlog and are sized to fit within a PI, making them larger than stories but smaller than epics. The development of these Features is planned and committed by Agile teams during the PI Planning event, and they are integral to defining and delivering value in a SAFe context.

In describing the features of a product or system, we take a more abstract and higher-level view of the system of interest. In so doing, we have the security of returning to a more traditional description of system behavior, the feature. Features can be described as follows:

Features are services provided by the system that fulfill stakeholder needs.

Features live at a level above software requirements and bridge the gap from the problem domain (understanding the needs of the users and stakeholders in the target market) to the solution domain (specific requirements intended to address the user needs)

We also posited in that text that a system of arbitrary complexity could be described with a list of 25 to 50 features (just like a program backlog). This simple rule of thumb allows us to keep our high-level descriptions precisely that—high level—and simplifies our attempts to describe complex systems in a short form while still communicating the full scope and intent of the proposed solution.

And as we just described, features also allow us to organize agile teams in a way that optimizes value delivery.

What is the SAFe Program Backlog?

The SAFe Program Backlog is the prioritized list of features to be implemented by an Agile Release Train.

The Program Backlog in the Scaled Agile Framework (SAFe) is a prioritized collection of upcoming features, each of which can deliver business value. Managed by the Product Management team, it reflects the product’s future direction and serves as the primary input to the Program Increment (PI) Planning process. The items in the backlog are typically ranked based on factors like business value, dependencies, risk, and alignment with strategic themes.

Features are brought to life by stories. During release planning, features are broken down into stories, which the teams utilize to implement the feature’s functionality.

Features are usually expressed as bullet points or, at most, a couple of sentences. For instance, you might describe a few features of an online email service like this:

Enable “Stars” for marking important conversations or messages, acting as a visual reminder to follow up on a message or conversation later. Introduce “Labels” as a “folder-like” metaphor for organizing conversations.

How do you test Features in SAFe?

Features in SAFe are tested through continuous integration, automated testing, and system and solution demonstration sessions.

Testing features within SAFe involves a combination of practices designed to ensure quality and functionality. It begins with continuous integration, where new code is regularly merged and tested. Automated testing at different levels – unit, integration, and system – validates functionality and prevents regression quickly. System and solution demonstration sessions are held at the end of each iteration and Program Increment to review and assess the working features. These practices help ensure that each feature delivers the intended value and meets quality standards.

At the Scaled Agile Program level, whether features also need (or warrant) acceptance tests arises. The answer is typically “yes.” Although story-level testing should ensure that methods and classes are reliable (unit testing) and stories serve their intended purpose (functional testing), a feature may involve multiple teams and numerous stories. Therefore, testing feature functionality is as crucial as testing story implementation.

Moreover, many system-level “what if” considerations (think alternative use-case scenarios) must be tested to guarantee overall system reliability. Some of these can only be tested at the full system level. So indeed, features, like stories, require acceptance tests as well.

In this way, we see that every feature demands one or more acceptance tests, and a feature cannot be considered complete until it passes.

What are SAFe Nonfunctional Requirements?

Nonfunctional Requirements (NFRs) in SAFe are system constraints that define the system’s operational characteristics.

In SAFe, Nonfunctional Requirements represent the “ilities” of the system – like reliability, availability, security, and performance. They define the system’s operational characteristics and constraints, such as response time, capacity, compliance, and scalability. NFRs are crucial for system effectiveness and are considered at all levels of SAFe. System and Solution Architect/Engineering typically define them and are part of the system or program backlog.

Nonfunctional Requirements as Backlog Constraints

From a requirements modeling perspective, we could include the NFRs in the program backlog, but their behavior tends to differ. New features usually enter the backlog, get implemented and tested, and then are removed (though ongoing functional tests ensure the features continue to work well in the future). NFRs restrict new development, reducing the level of design freedom that teams might otherwise possess. Here’s an example:

For partner compatibility, implement SAML-based single sign-on (NFR) for all products in the suite.

In other cases, when new features are implemented, existing NFRs must be reconsidered, and previously sufficient system tests may need expansion. Here’s an example:

The new touch UI (new feature) must still adhere to our accessibility standards (NFR).

Thus, in the requirements model, we represented NFRs as backlog limitations.

We first observe that nonfunctional requirements may constrain some backlog items while others do not. We also notice that some nonfunctional requirements may not apply to any backlog items, meaning they stand alone and pertain to the entire system.

Regardless of how we view them, nonfunctional requirements must be documented and shared with the relevant teams. Some NFRs apply to the whole system, and others are specific to a team’s feature or component domain.

Testing Nonfunctional Requirements

These requirements—usability, reliability, performance, supportability, and so on—are often called a system’s “ilities” or qualities. It should be clear that these requirements also need testing.

Most nonfunctional (0…*) requirements necessitate one or more tests. Instead of labeling these tests as another form of acceptance tests and further overusing that term, we’ve called them system qualities tests. This name implies that these tests must be conducted periodically to verify that the system still exhibits the qualities expressed by the nonfunctional requirements.

What is a Roadmap in SAFe?

A SAFe Roadmap is a visual timeline that illustrates the planned evolution of a solution over time.

In the context of SAFe, a Roadmap is a visual representation that shows a product’s or solution’s strategic direction over a certain timeline. It includes significant milestones, planned features, and key dependencies, and it aligns with the strategic themes and vision of the organization. The Roadmap provides a shared understanding of the product’s trajectory among teams and stakeholders, facilitating alignment and expectation management.

When we discussed the Vision, it was portrayed as independent of time; in other words, it outlines the product or system’s objectives without being tied to specific timelines. This approach is suitable when the goal is to communicate the essence of “what we are about to create.” Overloading the discussion with timelines and the “when” could potentially hinder the conversation about the “what.”

However, we need a perspective incorporating time to establish priorities and plan implementation. This is the purpose of the Roadmap. The Roadmap is neither complex nor mechanically challenging to maintain.

The Roadmap comprises a series of planned release dates, each with a theme and a prioritized set of features. Although it is mechanically simple to represent the Roadmap, determining its content is different.

What is the SAFe Agile Release Train?

The Agile Release Train (ART) is a long-lived team of Agile teams that incrementally delivers value in a value stream.

The ART is a key component of the SAFe framework. It’s essentially a “team of teams”, usually consisting of 50 to 125 people, that delivers value in the form of fully tested, working, system-level software. ARTs are organized around the enterprise’s significant Value Streams

Having discussed the organization of Scaled Agile program teams, the Vision, features, and nonfunctional requirements that define the program’s strategic intent, we can examine how the Vision is implemented over time.

Releases and Potentially Shippable Increments

As previously explained, system functionality development is carried out by multiple teams in a synchronized Agile Release Train (ART), a standard rhythm of timeboxed iterations and milestones that are date- and quality-fixed but scope-variable. The ART generates releases or potentially shippable increments (PSIs) at regular, usually fixed, 60- to 120-day intervals.

The PSI is to the enterprise what iterations are to the team, in other words, the fundamental iterative and incremental cadence and delivery mechanism for the program (an “ubersprint”). For numerous programs, release increments can be deployed to customers at this chosen rhythm; for others, the milestone represents the accomplishment of a valuable and assessable system-level increment. Depending on the business context, these increments can be delivered to the customer.

Release Planning

Release planning is the periodic Scaled Agile program activity that aligns teams to a shared mission. During release planning, teams translate the Vision into the features and stories necessary to achieve the objectives.

However, as we approach release planning, with its costs and overhead, we are reminded of certain Agile Manifesto principles.

• The most efficient form of communication is face-to-face.
• The best requirements, architecture, and designs emerge from self-organizing teams.
• The team regularly reflects on becoming more effective and then tunes and adjusts its behavior accordingly.

These principles and the need to ensure that teams share a common mission prompt enterprises to participate in periodic, face-to-face release planning events. These events gather stakeholders to address the following goals.

• Develop and share a unified Vision.
• Communicate market expectations, features, and relative priorities for the next release.
• Plan and commit to the content of the next release.
• Reallocate resources to match current program priorities.
• Refine the product Roadmap.
• Reflect on and apply lessons learned from previous releases.

The event’s frequency depends on the company’s need for market responsiveness and the iteration and releases cadence it has chosen. In most enterprises, it occurs every 60 to 120 days, with a 90-day cadence being typical.

To read more about Scaled Agile Program Planning Iterations, click here.

Summary

This post introduced new requirements, roles, artifacts, and processes for applying agile development in Scaled Agile programs involving multiple teams. We described how to organize teams to optimize value delivery. We introduced several new requirements artifacts—Vision, features, nonfunctional requirements, and Roadmap—and explained how teams use these artifacts to communicate the larger purpose of the product, system, or application they are developing. We also described how teams combine a series of iterations with building PSIs, or incremental releases, through an Agile Release Train, progressively delivering value to users and customers.

References

• Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional. Amazon
• Scaled Agile Framework (SAFe) – https://www.scaledagileframework.com/
• Larman, C., & Vodde, B. (2008). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley Professional. Amazon
• Kniberg, H., & Skarin, M. (2010). Kanban and Scrum: making the most of both. InfoQ.com. InfoQ
• Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional. Amazon
• Leffingwell, D. (2010). Agile Architecture: Strategies for Scaling Agile Development. IEEE Software, 27(2), 61-67. IEEE Xplore
• Larman, C., & Vodde, B. (2010). Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley Professional. Amazon
• Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing. Amazon
• Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional. Amazon
• Pichler, R. (2010). Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley Professional. Amazon
• Roman, G., & Pichler, R. (2010). The Art of Agile Product Management: A Comprehensive Guide for Agile Product Owners. Wiley. Amazon
• Crispin, L., & Gregory, J. (2015). More Agile Testing: Learning Journeys for the Whole Team. Addison-Wesley Professional. Amazon
•  Leffingwell, D. (2011). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley Professional. Amazon
• Rigby, D. K., Sutherland, J., & Takeuchi, H. (2016). Embracing Agile. Harvard Business Review, 94(5), 40-50. HBR