SAFe SASM

Release Train Engineer

Behaviour driven development

Non funtional requirements define system attributes such as security, reliability, performance, maintainability, scalability, and usability

Program Increment

Product Owner

Product Manager

alignment, built-in quality, transparency, and program execution

Agile development, Lean product development, systems thinking, and DevOps

Flow, Architecture and Design Quality, Code Quality, System Quality and Release Quality

#1 – Take an economic view
#2 – Apply systems thinking
#3 – Assume variability; preserve options
#4 – Build incrementally with fast, integrated learning cycles
#5 – Base milestones on objective evaluation of working systems
#6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths
#7 – Apply cadence, synchronize with cross-domain planning
#8 – Unlock the intrinsic motivation of knowledge workers
#9 – Decentralize decision-making
#10 – Organize around value

A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).

Features are defined using a Features and Benefits (FAB) Matrix:

– A short phrase giving a name and context Benefit hypothesis

– The proposed measurable benefit to the end-user or business

A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.

Minimum Marketable Feature

Weighted Shortest Job First

The Solution Train is the organizational construct used to build large and complex Solutions that require the coordination of multiple Agile Release Trains (ARTs), as well as the contributions of Suppliers. It aligns ARTs with a shared business and technology mission using the solution Vision, Backlog, and Roadmap, and an aligned Program Increment (PI).

Solution Train Engineer (STE) is the servant leader of the train. Their oversight allows the train to run smoothly by identifying and resolving bottlenecks across the entire solution. The STE facilitates the large solution-level events and monitors the solution Kanban and solution health via its Metrics. They also work with Release Train Engineers (RTEs) to coordinate delivery.

Solution Management represents the customer’s overall needs across ARTs, as well as communicating the portfolio’s Strategic Themes. They collaborate with Product Management of each ART to define capabilities and split them into features. Solution Management, the primary content authority for the solution backlog, also contributes to the economic framework that governs the ARTs and Agile teams

Solution Architect/Engineering collaboratively defines the technology and architecture that connects the solution across the ARTs. It works with the ART’s System Architect/Engineering team to help guide their portion of the solution’s design.

Customers are the ultimate buyers of the solution and are involved at every level of SAFe. They’re part of the value stream and are inseparable from the development process. Customers work closely with Solution and Product Management and other key stakeholders to shape the solution intent, the vision, and the economic framework in which development occurs

System Teams is often formed for the Solution Train to address the integration issues across the ARTs

Shared Services are specialists—data security, information architects, and database administrators (DBAs), for example—that are necessary for the success of a solution but may not be dedicated to a specific train

Model-Based Systems Engineering (MBSE) – Describes how emergent requirements and design can be developed, documented, and maintained in more flexible and accessible models

Set-Based Design (SBD) – Describes practices that support the preservation of options and the move from variable to fixed requirements over time, while deferring decisions to the last responsible moment

- Solution Train sync
- Architect sync
- Solution Demo
- Prepare for PI Planning
- Inspect & Adapt
- Pre-PI Planning
- Post-PI Planning

- Scrum of Scrum
- PO Synmc 
- Systems Demo
- Prepare for PI Planning
- Inspect & Adapt
- PI Planning

- ART Sync
- Daily Stand-up
- Iteration Review
- Backlog refinement
- Iteration Retro
- Iteration Planning
- PI Planning

Inspect & Adapt Event

The I&A event consists of three parts:

1. PI System Demo
2. Quantitative and qualitative measurement
3. Retrospective and problem-solving workshop

Participants in the I&A should be, wherever possible, all the people involved in building the solution. These include for an ART:

• The Agile teams Release Train Engineer (RTE)
• System and Solution Architect/Engineering
• Product Management, Business Owners, and others on the train

Additionally, Solution Train stakeholders may attend this event.

The System Team is a specialized Agile Team that assists in building and supporting the Agile development environment, typically including development and maintenance of the toolchain that supports the Continuous Delivery Pipeline.  The System Team may also support the integration of assets from Agile teams, perform end-to-end Solution testing where necessary, and assists with deployment and Release on Demand.

In SAFe, Agile teams are cross-functional groups of 5-11 individuals who define, build, test, and deliver an increment of value in a short time box.

Continuous Learning Culture

Systems thinking takes a holistic approach to solution development, incorporating all aspects of a system and its environment into the design, development, deployment, and maintenance of the system itself.

Experience, expertise, execution, exploration

Sequential phase-gated (waterfall) development process. These phase-gate milestones are not arbitrary. They follow a seemingly logical and sequential process

Communities of Practice (CoPs) are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain.

Domain – An area of shared interest 
Practice – A shared body of knowledge, experiences, and techniques 
Community – A self-selected group of individuals who care enough about the topic to participate in regular interactions

For addressing systemic problems, a structured, root-cause problem-solving workshop is held by the ART. Root cause analysis provides a set of problem-solving tools used to identify the actual causes of a problem, rather than just addressing the symptoms. The session is typically facilitated by the RTE, in a timebox of two hours or less.

Synchronization allows multiple solution perspectives to be understood, resolved, and integrated at the same time.

Decentralizing decision-making reduces delays, improves product development flow and throughput, and facilitates faster feedback and more innovative solutions. Higher levels of empowerment are an additional, tangible benefit.

• Workflow steps
• Business rule variations
• Major effort Simple/complex
• Variations in data Data entry methods
• Deferred system qualities
• Operations (ex., Create, Read, Update, Delete [CRUD])
• Use-case scenarios
• Break-out spike

Release on Demand is the process that deploys new functionality into production and releases it immediately or incrementally to customers based on demand. Release on Demand is the final aspect in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment, and Release on Demand