System and Solution Architect/Engineering:

  • Defines a shared architecture and vision for the solution under development
  • Determine system, subsystem, interfaces, validate technology assumptions and evaluate alternatives, working closely with agile release train and solution train
  • Takes systems view on solution development
  • Participate in planning, definition, and high-level design of the solution and explore solution alternatives
  • Actively participate in the Continuous Exploration process as part of the Continuous Delivery Pipeline, especially with enabler Epics Define subsystems and their interfaces, allocate responsibilities to subsystems, understand solution deployment, and communicate requirements for interactions with solution context
  • Work with customers, stakeholders, and suppliers to establish high-level Solution Intent, and the solution intent information models and documentation requirements
  • Establish critical NFRs at the solution level, participate in the definition of others
  • Operate within the Economic Framework to validate the economic impact of design decisions
  • Work with portfolio stakeholders, notably the Enterprise Architect, to develop, analyze, split, and realize the implementation of enabler epics
  • Participate in Program Increment (PI) Planning and Pre- and Post-PI Planning, System and Solution Demos, and Inspect and Adapt events
  • Define, explore, and support the implementation of ART and Solution Train Enablers to evolve solution intent, working directly with Agile teams to implement them
  • Plan and develop the Architectural Runway in support of new business Features and Capabilities
  • Work with Product and Solution Management to determine capacity allocation for enablement work
  • Support technology/engineering aspects of Program and Solution Kanbans
  • Provide oversight and foster Built-In Quality

Product and Solution Management:

  • Understand customer needs and validate solutions
  • Understand and support portfolio work
  • Develop and communicate the program vision and roadmap
  • Manage and prioritize the flow of work
  • Participate in PI planning
  • Define releases and program increments
  • Work with System Architect/Engineering to understand Enabler work
  • Participate in demos and Inspect and Adapt (I&A)
  • Build an effective Product Management/Product Owner team

Economic Framework:

The primary purpose of the economic framework is to support effective, fast decision-making within the bounds of the larger economic picture. In turn, that requires three things:

  • An understanding of the rules for decision-making
  • The current local context
  • Relevant decision-making authority

Solution Intent:

It is the repository for storing, managing and communicating the knowledge of current and intended solution behavior. It includes both fixed and variable specifications and designs. Solution intent is a critical knowledge repository to store, manage, and communicate ‘what is being built’ and ‘how it will be built.’ It serves many purposes:

  • Provides a single source of truth regarding the intended and actual behavior of the solution
  • Records and communicates requirements, design, and system architecture decisions
  • Facilitates further exploration and analysis activities
  • Aligns the Customer, Dev Team, and Suppliers to a common mission and purpose
  • Supports Compliance and contractual obligations

Compliance:

Compliance refers to a strategy and a set of activities and artifacts that allow teams to apply Lean-Agile development methods to build systems that have the highest possible quality, while simultaneously assuring they meet any regulatory, industry, or other relevant standards.

Most high-assurance systems require V&V to ensure that:

  • The system works as designed (verification)
  • It meets the needs of the user (validation)

Model Based Systems Engineering:

Model-Based Systems Engineering (MBSE) is the practice of developing a set of related system models that help define, design, and document a system under development. These models provide an efficient way to explore, update, and communicate system aspects to stakeholders, while significantly reducing or eliminating dependence on traditional documents.

Set Based Design:

Set-Based Design (SBD) is a practice that keeps requirements and design options flexible for as long as possible during the development process. Instead of choosing a single point solution upfront, SBD identifies and simultaneously explores multiple options, eliminating poorer choices over time. It enhances flexibility in the design process by committing to technical solutions only after validating assumptions, which produces better economic results.

Economic Trade-Offs in Set-Based Design Different design options have different economic implications. So understanding SBD requires knowledge of the macroeconomic goals and benefits of the system. One way to look at this is to place the alternatives on a spectrum, where a certain weight can be associated with each option. Some of the significant economic indicators may include:

  • Cost of development
  • Cost of manufacturing
  • Performance and reliability
  • Cost of support
  • Development time
  • Technical risks

Program and Solution Kanban:

The Program and Solution Kanban systems are a method to visualize and manage the flow of Features and Capabilities from ideation to analysis, implementation, and release through the Continuous Delivery Pipeline.

Program and Solution Backlogs

The Program Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the enabler features necessary to build the Architectural Runway.

The Solution Backlog is the holding area for upcoming Capabilities and enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.

Product Management has responsibility for the Program Backlog, while Solution Management is responsible for the Solution Backlog.

Backlog refinement typically includes:

  • Reviewing and updating backlog item definition and developing acceptance criteria and benefit hypothesis
  • Working with the teams to establish technical feasibility and scope estimates
  • Analyzing ways to split backlog items into smaller chunks of incremental value
  • Identifying the enablers required to support new features and capabilities, and establishing their capacity allocation

Little’s Law illustrates that the average wait time for an item in a queue is equal to the average length of the queue divided by the average processing rate for an item in a queue. The longer the queue, the higher the wait time, and the higher the variability.

Solution Train:

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)

Operates on following set of principles:

  • Fixed cadence
  • A new solution increment every PI
  • Solution
  • Compliance
  • Suppliers
  • PI Timebox
  • Uses an economic framework
  • ARTs power the solution train
  • Inspect and Adapt
  • Develop on cadence. Release on Demand.
  • The solution Kanban and Backlog

Pre- and Post-PI Planning

Pre- and post-PI planning events allow Agile Release Trains and Suppliers in large Value Streams to build a unified plan for the next PI. The pre- and post-PI planning events serve as a wrapper for the PI planning at the Program Level, where the actual detailed planning takes place and is incorporated into the Innovation and Planning (IP) Iteration calendar.

The pre-PI planning event is used to coordinate input objectives, Milestones, and business and solution context for the ART PI planning sessions.

The post-PI planning event is used to integrate the results of ART planning into the Vision and Roadmap for the value stream. At the end of the post-PI planning event, there should be an agreement on a set of solution PI Objectives to be implemented by the end of the PI and demoed at the next Solution Demo. As with PI planning, the pre- and post-PI planning events deliver several business benefits:

  • Provide open and productive communication through face-to-face alignment
  • Synchronize ARTs with Solution Train vision via the ART and solution PI objectives
  • Identify dependencies and foster cross-ART coordination
  • Provide the opportunity for just the right amount of solution-level architecture and user experience guidance (see the article, Lean UX)
  • Match solution demand to ART capacities

Inputs to pre- and post-PI planning include the solution roadmap, vision, Solution Intent, and the top Capabilities from the Solution Backlog.

Attendees include:

  • Solution stakeholders, including Solution Train Engineer (STE), Solution Management, Solution Architect/Engineering, solution System Team, and Release Management
  • Representatives from all the ARTs and suppliers, usually Release Train Engineers (RTEs), Product Management, System Architect/Engineering, Customers, and other primary stakeholders

Outputs include three primary artifacts:

  • A set of aggregated specific, measurable, achievable, realistic, time-bound (SMART) PI objectives for the solution
  • A solution planning board, which highlights the capabilities, anticipated delivery dates, and any other relevant milestones for the solution
  • A confidence vote (commitment) to the solution PI objectives

This cadence based planning process guides delivery through the inevitable technical obstacles and twists and turns of the business and technology environment.

Coordinating Solution Train and ART Planning Events in the IP Iteration

Solution Demo

The Solution Demo is where the results of development efforts from the Solution Train are integrated, evaluated, and made visible to Customers and other stakeholders.

The solution demo is where the results of the combined development efforts of multiple Agile Release Trains (ARTs)—along with the contributions from Suppliers and other solution participants—are shown to customers and other stakeholders. This demo is a critical time for the Solution Train, an opportunity for objective evaluation and feedback. It’s also a moment to celebrate the accomplishments of the last PI.

Each solution demo represents a significant learning point in the history of the solution, converting some product development uncertainty to knowledge. Results of this demo determine the future course of action for the investment in the portfolio.

A typical event agenda includes the following activities:

  • Briefly, review the Solution Train PI Objectives for the PI (10 minutes)
  • Demo each PI objective and capability in an end-to-end use case (30 – 60 minutes total)
  • Identify business value completed for each PI objective
  • Open forum for questions and comments
  • Wrap up by summarizing progress, feedback, and action items

Customer:

Engaging customers in the development process depends on the type of solution and the customer’s impact. For example:

  • An internal customer requesting their IT department build an application for them
  • An external customer who’s the buyer of a custom-built offering (e.g. a government purchasing a defense system) or is part of a larger class of buyers (e.g. an independent software vendor that sells a suite of products).

Solution Context

Identifies critical aspects of the operational environment for the solution. It provides an essential understanding of requirements, usage, installation, operation, and support of the solution itself. Solution context heavily influences opportunities and constraints for releasing on demand.

The solution context is often driven by factors outside the control of the organization that develops the solution. The level of coupling between the solution and its context generally represents an architectural and business challenge, that of finding the right balance between flexibility and tightly coupled interaction with the environment—interactions that often cross internal, Supplier, and Customer organizational boundaries.

Solution

Each Value Stream produces one or more Solutions, which are products, services, or systems delivered to the Customer, whether internal or external to the Enterprise.

Reference: https://www.scaledagileframework.com/