1. Dual Operating System
1.1. Value Stream Networking
1.1.1. Customer Centricity
1.1.2. Speed of Innovation
1.2. Functional Hierarchy
1.2.1. Effeciency and Stability
2. Configurations
2.1. Full
2.2. Large Solution
2.3. Portfolio
2.4. Essential
3. 7 Core Competencies
3.1. 1. Team & Technical Agility
3.1.1. the critical skills and Lean-Agile principles and practices that highperforming Agile Teams and teams of Agile Teams use to create high-quality solutions for their customers
3.1.1.1. Solution Meet Customer Needs
3.1.1.2. Solution Deliver Value to Customer
3.1.2. Dimensions
3.1.2.1. Form cross-functional Agile Teams
3.1.2.1.1. Cross-functional, selforganizing entities
3.1.2.1.2. Teams execute Iterations with Scrum and Kanban
3.1.2.1.3. Agile business teams foster true Business Agility
3.1.2.1.4. Roles and responsibilities on the Agile Team
3.1.2.2. Build quality in
3.1.2.2.1. You can’t scale crappy code (or hardware, or anything else).
3.1.2.2.2. Ensures that every increment of the Solution reflects quality standards
3.1.2.2.3. Is required for high, sustainable development velocity
3.1.2.2.4. Many practices apply to every team, business or technology
3.1.2.2.5. Built-in Quality practices for technology-focused teams
3.1.2.3. Organize Agile Release Trains (ARTs) around the flow of value
3.1.2.3.1. long-lived Team-of-Agile-Teams
3.1.2.3.2. (ARTs) continuously deliver value
3.1.2.3.3. Create cross-functional Agile Release Trains
3.1.2.3.4. Roles on the Agile Release Train
3.1.2.3.5. (ARTs) continuously deliver value
3.2. 2. Agile Product Delivery
3.2.1. A customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users
3.2.1.1. Creating the Right Solution for the Right Customer AT the Right Time
3.2.1.2. Balance between Execution Focus and Customer Focus
3.2.2. Dimensions
3.2.2.1. Customer Centricity & Design Thinking
3.2.2.2. Develop on Cadence, Release on Demande
3.2.2.2.1. Development Centric
3.2.2.2.2. Customer Centric
3.2.2.3. DevOps and the Continuous Delivry Pipeline
3.2.2.3.1. Continuous Exploration
3.2.2.3.2. Continuous Integration
3.2.2.3.3. Continiuous Deployment
3.3. 3. Entreprise Solution Delivry
3.3.1. Applying Lean-Agile principles and practices to the specification, development, deployment, operation, and evolution of the world’s largest and most sophisticated systems
3.3.2. Dimensions
3.3.2.1. Lean System and Solution Engineering
3.3.2.1.1. LEAN QMS
3.3.2.2. Coordinating Trains and Suppliers
3.3.2.3. Continually Evolve Live Systems
3.3.2.3.1. Continuous Delivery Pipeline
3.3.2.3.2. Evolve Deployed Systems
3.4. 4. Lean Portfolio Managment
3.4.1. Applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance
3.4.2. Dimesions
3.4.2.1. Strategy and Investment Funding
3.4.2.2. Agile Portfolio Operations
3.4.2.3. Lean Governance
3.5. 5. Organizational Agility
3.5.1. How Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities
3.5.2. Dimensions
3.5.2.1. Lean-Thinking People and Agile Teams
3.5.2.2. Lean Business Operations
3.5.2.3. Strategy Agility
3.6. 6. Continuous Learning Culture
3.6.1. A set of values and practices that encourage individuals—and the enterprise as a whole—to continually increase knowledge, competence, performance, and innovation
3.6.2. Dimensions
3.6.2.1. Learning Organization
3.6.2.2. Innovation Culture
3.6.2.3. Relentless Improvement
3.7. 7. Lean-Agile Leadership
3.7.1. how Lean-Agile Leaders drive and sustain organizational change and operational excellence by empowering individuals and teams to reach their highest potential
3.7.2. Dimensions
3.7.2.1. Mindset & Principles
3.7.2.1.1. Core Values
3.7.2.1.2. House of Lean
3.7.2.1.3. The Agile Manifesto
3.7.2.1.4. SAFe Lean-Agile Principles
3.7.2.2. Leading by Exemple
3.7.2.3. Leading Change
4. Knowledge base
4.1. Of proven integrated principles, practices, and competencies
4.2. For achieving Business Agility
4.2.1. Business Agility
4.2.1.1. Requires Everyone Use Lean & Agile Practices
4.2.1.1.1. Technical Agility
4.2.1.1.2. Value Stream Thinking
4.2.1.2. Continualy and proactively delivring innovative business solutions faster than the competition
4.3. By implementing Lean, Agile, and DevOps at scale
5. Core Values
5.1. 1. Alignment
5.1.1. Communicate the mission by establishing and expressing the portfolio strategy and solution vision
5.1.1.1. Informed Inputs
5.1.1.1.1. Continuous Exploration with Customer Centrecity & Design Thinking
5.1.1.2. Transparent & Prioritized Outputs
5.1.1.2.1. Strategic Themes
5.1.1.2.2. Portfolio Vision
5.1.1.2.3. Portfolio Backlog
5.1.2. Help organize the value stream and coordinate dependencies
5.1.3. Provide relevant briefings and participate in Program Increment (PI) Planning
5.1.4. Help with backlog visibility, review, and preparation; regularly check for understanding
5.2. 2. Built-in Quality
5.2.1. By refusing to accept or ship low-quality work
5.2.2. Support investments in capacity planning for maintenance and to reduce technical debt
5.2.3. Ensure Design thinking, UX, architecture, operations, security, and compliance, are part of the regular flow of work
5.3. 3. Transparency
5.3.1. Visualize all relevant work
5.3.2. Take ownership and responsability for errors ans mistakes
5.3.3. Admit your own mistakes
5.3.4. Support others whp acknowledge and learn from their mistakes and never punish the messenger
5.4. 4. Program Execution
5.4.1. Participate as an active business owner in PI execution
5.4.2. Celebrate high quality and predictably delivred Program Increments
5.4.3. Aggressively remove impediments and demotivators
6. House of Lean
6.1. The Goal - Value
6.1.1. Achieve the shortest sustainable lead time
6.1.2. The best quality and value to people and society
6.1.3. High morale, safety, and Customer delight
6.2. Pillar 1 - Respect for people and culture
6.2.1. Generative culture
6.2.2. People do all the work
6.2.3. Your Customer is whoever consumes your work
6.2.4. M§
6.2.5. Build long-term partnerships based on trust
6.2.6. To change the culture, you have to change the organization
6.3. Pillar 2 - Flow
6.3.1. Optimize sustainable value delivery
6.3.2. Build-in quality
6.3.3. Understand, exploit, and manage variability
6.3.4. Move from projects to products
6.4. Pillar 3 - Innovation
6.4.1. Innovative people
6.4.2. Provide time and space for innovation
6.4.3. Go see
6.4.4. Experimentation and feedback
6.4.5. Innovation riptides
6.4.6. Pivot without mercy or guilt
6.5. Pillar 4 - Relentless Improvement
6.5.1. A constant sense of danger
6.5.2. Optimize the whole
6.5.3. Problem-solving culture
6.5.4. Base improvements on facts
6.5.5. Reflect at key Milestones
6.6. Foundation - Leadership
6.6.1. Lead by example
6.6.2. Adopt a growth mindset
6.6.3. Exemplify the values and principles of Lean-Agile and SAFe
6.6.4. Develop people
6.6.5. Lead the change
6.6.6. Foster psychological safety
7. The Agile Manifesto
7.1. Values
7.1.1. Individuals and interactions over processes and tools
7.1.2. Working software over comprehensive documentation
7.1.3. Customer collaboration over contract negotiation
7.1.4. Responding to change over following a plan
7.2. Principles
7.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
7.2.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
7.2.3. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
7.2.4. 4. Business people and developers must work together daily throughout the project.
7.2.5. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
7.2.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7.2.7. 7. Working software is the primary measure of progress.
7.2.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
7.2.9. 9. Continuous attention to technical excellence and good design enhances agility.
7.2.10. 10. Simplicity—the art of maximizing the amount of work not done—is essential.
7.2.11. 11. The best architectures, requirements, and designs emerge from selforganizing teams.
7.2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
8. SAFe Lean-Agile Principles
8.1. Why ?
8.1.1. ► A Lean-Agile transformation will deliver substantial benefits
8.1.2. ► However, it is a significant change, and every implementation is different
8.1.3. ► Leaders should understand why the practices work; it’s part of 'knowing what it is they must do’
8.1.4. ► If a practice needs to change, understanding the principles will assure the change moves the Enterprise in the right direction
8.2. Principles
8.2.1. #1 Agile economics
8.2.1.1. Deliver early and often
8.2.1.1.1. Deliver value incrementally
8.2.1.1.2. Early delivery has higher value
8.2.1.1.3. Cumulative gross margins are higher
8.2.1.2. Apply an economic framework
8.2.1.2.1. Understanding solution economic trade-offs
8.2.1.2.2. Operating within lean budgets and guardrails
8.2.1.2.3. Leveraging suppliers
8.2.1.2.4. Sequencing jobs for the maximum benefit
8.2.2. #2 Apply systems thinking
8.2.2.1. Attributes of systems thinking
8.2.2.1.1. Optimizing a component does not optimize the system
8.2.2.1.2. For the system to behave well as a system, a higher-level understanding of behavior and architecture is required
8.2.2.1.3. The value of a system passes through its interconnections
8.2.2.1.4. A system can evolve no faster than its slowest integration point
8.2.2.2. Optimize the full Value Stream
8.2.2.2.1. Most problems with your process will surface as delays
8.2.2.2.2. Most of the time spent getting to market is a result of these delays
8.2.2.2.3. Reducing delays is the fastest way to reduce time-to-market
8.2.3. #3 Assume variability; preserve options
8.2.3.1. Development occurs in an uncertain world
8.2.3.1.1. You cannot possibly know everything at the start
8.2.3.1.2. Requirements must be flexible to make economic design choices
8.2.3.1.3. Designs must be flexible to support changing requirements
8.2.3.1.4. Preservation of options improves economic results
8.2.3.2. Preserve options with set-based approach
8.2.3.2.1. Set-Based Design (SBD)
8.2.3.2.2. Set-Based Concurrent Engineering (SBCE)
8.2.4. #4 Build incrementally with fast, ntegrated learning cycles
8.2.4.1. Apply fast learning cycles
8.2.4.1.1. Improves learning efficiency by decreasing the time between action and effect
8.2.4.1.2. Reduces the cost of risk-taking by truncating unsuccessful paths quickly
8.2.4.1.3. Is facilitated by small batch sizes
8.2.4.1.4. Requires increased investment in development environment
8.2.4.2. Integration points control product development
8.2.4.2.1. Integration points accelerate learning
8.2.4.2.2. Development can proceed no faster than the slowest learning loop
8.2.4.2.3. Improvement comes through synchronization of design loops and faster learning cycles
8.2.5. #5 Base milestones on objective valuation of working systems
8.2.5.1. The problem of phase-gate milestones
8.2.5.1.1. They force design decisions too early; this encourages false-positive feasibility.
8.2.5.1.2. They assume a ‘point’ Solution exists and can be built correctly the first time.
8.2.5.1.3. They create huge batches and long queues, and they centralize requirements and design in program management.
8.2.5.2. Apply objective Milestones
8.2.5.2.1. Program Increment (PI) System Demos are orchestrated to deliver objective progress, product, and process Metrics.
8.2.5.3. Iterate to the optimum solution
8.2.5.3.1. Objective Milestones facilitate learning and allow for continuous, cost-effective adjustments towards an optimum Solution.
8.2.6. #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths
8.2.6.1. Visualize to increase understanding
8.2.6.1.1. Use a Kanban Board to make the current WIP visible for all stakeholders
8.2.6.1.2. Start balancing the amount of WIP against the available development capacity
8.2.6.2. Reduce batch size for higher predictability
8.2.6.2.1. Large batch sizes increase variability
8.2.6.2.2. Small batches go through the system faster with lower variability
8.2.6.2.3. The most important batch is the handoff batch
8.2.6.3. Finding optimal batch size
8.2.6.3.1. The economically optimal batch size depends on both the holding cost (the cost for delayed feedback, inventory decay, and delayed value delivery) and the transaction cost (the cost of preparing and implementing the batch)
8.2.6.3.2. Total costs are the sum of holding costs and transaction costs
8.2.6.3.3. Higher transaction costs make optimal batch size bigger
8.2.6.3.4. Higher holding costs make batch size smaller
8.2.6.4. Reducing optimal batch size
8.2.6.4.1. Reducing transaction costs reduces total costs and lowers optimum batch size
8.2.6.4.2. Batch size reduction probably saves twice what you think
8.2.6.5. Manage queue lengths
8.2.6.5.1. Reduce queue lengths
8.2.6.5.2. Faster processing time decrease wait
8.2.6.5.3. Shorter queue lengths decrease wait
8.2.7. #7 Apply cadence, synchronize with cross-domain planning
8.2.7.1. Cadence without synchronization is not enough
8.2.7.2. Synchronize to assure delivery
8.2.7.3. Control variability with planning cadence
8.2.7.3.1. Cadence-based planning limits variability to a single interval
8.2.7.4. Synchronize with cross-domain planning
8.2.7.4.1. All stakeholders meet face-to-face (but typically in multiple locations)
8.2.7.4.2. Managment sets the mission with minimum possible constraints
8.2.7.4.3. Requirements and design happen
8.2.7.4.4. Important stakeholder decisions are accelerated
8.2.7.4.5. Teams create and take responsability for plans
8.2.8. #8 Unlock the intrinsic motivation of knowledge workers
8.2.8.1. On managing knowledge workers
8.2.8.1.1. Workers themselves are most qualified to make decisions about how to perform their work
8.2.8.1.2. Workers must be heard and respected for management to lead effectively
8.2.8.1.3. Knowledge workers have to manage themselves: they need autonomy
8.2.8.1.4. Continuing innovation has to be part of the work and the responsibility of knowledge workers
8.2.8.2. Unlocking intrinsic motivation with autonomy, mastery, and purpose
8.2.8.2.1. ► Autonomy is the desire to be self-directing and have control over what we work on, how we do our work, and who we work with
8.2.8.2.2. ► Mastery is the urge to get better at what we do and improve our personal and team skills
8.2.8.2.3. ► Purpose is the desire to do something that matters and has meaning
8.2.9. #9 Decentralize decision-making
8.2.9.1. Define the economic logic behind a decision; empower others to make the changes
8.2.9.2. Centralize Strategic Decisions
8.2.9.2.1. Infrequent
8.2.9.2.2. Long-lasting
8.2.9.2.3. Provide significant economies of scale
8.2.9.3. Decentralize Everything Else
8.2.9.3.1. Frequent
8.2.9.3.2. Time-critical
8.2.9.3.3. Require local information
8.2.10. #10 Organize around value
8.2.10.1. Value doesn’t follow silos
8.2.10.2. Instead, organize around the flow of value
8.2.10.2.1. Realizing Value Streams with Agile Teams and Trains
8.2.10.3. Value at scale is distributed
9. Building Solutions with Agile Product Delivery
9.1. 1. Apply Customer Centricity with Design Thinking
9.1.1. Why Customer Centricity?
9.1.1.1. Customer-centric Enterprises deliver whole-product Solutions that are designed with a deep understanding of Customer needs
9.1.1.1.1. Customer-centric Gouvernments and nonprofits create : the resiliency, sustainability, and alignment needed to fulfill their mission
9.1.1.1.2. Customer-centric Businesses generate :
9.1.1.2. Customer Centricity is a mindset
9.1.1.2.1. EVERYTHING is about the customer
9.1.2. What is Design Thinking?
9.1.2.1. Design Thinking is an iterative Solution development process that promotes a holistic approach to delighting stakeholders
9.1.2.1.1. Understand the problem
9.1.2.1.2. Design the solution
9.1.2.1.3. Solution Desirable, Feasible, Viable, and Sustainable
9.1.2.2. Use personas to understand Customers
9.1.2.2.1. ► Convey the problems they’re facing in context (i.e., their work environment) and key triggers for using the product
9.1.2.2.2. ► Capture rich, concise information (photographs, family stories, jobs, etc.) that inspire great products without unnecessary details
9.1.2.3. Use empathy maps to identify with Customers
9.1.2.3.1. ► The empathy map is a tool that helps teams develop deep, shared understanding and empathy for the Customer
9.1.2.3.2. ► Use it to design better user experiences and Value Streams
9.1.2.4. Use journey maps to design the end-to-end Customer experience
9.1.2.5. Use story maps to capture workflows
9.1.2.5.1. Capture the activities or tasks the user must perform to accomplish their goal
9.1.2.5.2. Stories within an activity are typecally prioritized from
9.2. 2. Prioritize the Program Backlog
9.2.1. Features are managed through the Program Backlog
9.2.2. Vision aligns everyone on the product’s direction
9.2.2.1. ► How will our product solve our customer's problems?
9.2.2.2. ► What Features does it have?
9.2.2.3. ► How will it differentiate us?
9.2.2.4. ► What Nonfunctional Requirements does it deliver?
9.2.3. Features represent the work for the Agile Release Train
9.2.3.1. ► Feature is an industry-standard term familiar to marketing and Product Management
9.2.3.2. ► A benefit hypothesis justifies Feature implementation cost and provides business perspective when making scope decisions
9.2.3.3. ► Acceptance criteria are typically defined during Program Backlog refinement
9.2.3.4. ► Reflect functional and nonfunctional requirements
9.2.3.5. ► Fits in one PI
9.2.4. Features are implemented by Stories
9.2.4.1. Srories are small increments of value that can be developed in days and are relatively easy to estimate
9.2.4.2. Story user-voice from captures role, activity, and goal
9.2.4.2.1. User Story
9.2.4.2.2. Enabler Story
9.2.4.3. Features fit in one PI for ART; Stories fit in one Iteration for One Team
9.2.5. Estimate Stories with relative Story points
9.2.5.1. A Story point is a singular number that represents:
9.2.5.1.1. – Volume: How much is there?
9.2.5.1.2. – Complexity: How hard is it?
9.2.5.1.3. – Knowledge: What do we know?
9.2.5.1.4. – Uncertainty: What’s not known?
9.2.5.2. Story points are relative. They are not connected to any specific unit of measure.
9.2.5.3. Apply estimating poker for fast, relative estimating
9.2.5.3.1. Estimating Pocker combines expert opinion, analogy, and disaggregation for quick but reliable estimates
9.2.5.3.2. All team members participate
9.2.5.3.3. Steps
9.2.5.4. Estimation is a whole-team exercise
9.2.5.4.1. Increases accuracy by includung all perspectives
9.2.5.4.2. Builds understanding
9.2.5.4.3. Creates shared commitment
9.2.6. Prioritize Features for optimal ROI
9.2.6.1. To prioritize based on Lean economics, we need to know two things:
9.2.6.1.1. The cost of delay (CoD) of delivering value
9.2.6.1.2. The duration to implement the value
9.2.6.1.3. In the general case, give preference to jobs with shorter duration and higher CoD
9.3. 3. Participate in PI Planning
9.3.1. Program Increment Planning
9.3.1.1. ► Two days every 8 – 12 weeks (10 weeks is typical)
9.3.1.2. ► Everyone attends, in person if at all possible
9.3.1.3. ► Product Management owns Feature priorities
9.3.1.4. ► Agile Teams own Story planning and high-level estimates
9.3.1.5. ► Architect/Engineering and UX work as intermediaries for governance, interfaces, and dependencies
9.3.2. The benefits of PI Planning
9.3.2.1. ► Establishing face-to-face communication across all team members and stakeholders
9.3.2.2. ► Aligning development to business goals with the business context, Vision, and Team/Program PI Objectives
9.3.2.3. ► Identifying dependencies and fostering cross-team and cross-ART collaboration
9.3.2.4. ► Providing the opportunity for ‘just the right amount’ of architecture and Lean User Experience (UX) guidance
9.3.2.5. ► Matching demand to capacity, eliminating excess work in process (WIP)
9.3.2.6. ► Fast decision making
9.3.3. The PI Planning process
9.3.3.1. Inputs
9.3.3.1.1. Vision
9.3.3.1.2. TOp 10 Features of the Program Backlog
9.3.3.2. Output
9.3.3.2.1. Team's PI Objectives
9.3.3.2.2. Program PI Objectives
9.3.3.2.3. Program Board
9.3.3.3. Process
9.3.3.3.1. Day 1
9.3.3.3.2. Day 2
9.4. 4. Develop on Cadence; Release on Demand
9.4.1. Manage the flow of work with the Program Kanban
9.4.2. Program events drive the train
9.4.2.1. Team events
9.4.2.1.1. Iteration Planning
9.4.2.2. Program events
9.4.2.2.1. PI Planning
9.4.3. ART sync is used to coordinate progress
9.4.3.1. Scrum of Scrums
9.4.3.1.1. Visibility into progress and impediments
9.4.3.1.2. Facilitated by RTE
9.4.3.1.3. Participants : Scrum Masters, other selct team members, SEMs if necessary
9.4.3.1.4. Weekly or more frequently, 30-60 minutes
9.4.3.1.5. Timeboxed and followed by a 'Meet After'
9.4.3.2. PO Sync
9.4.3.2.1. Visibilty in progress, scope, and priority adjustments
9.4.3.2.2. Facilitated by RTE or PM
9.4.3.2.3. Participants: PMs, POs, other stakeholders, and SMEs as necessary
9.4.3.2.4. Weekly or more frequently, 30-60 minutes
9.4.3.2.5. Timeboxed and followed by a 'Meet After'
9.4.4. Demo the full system increment every two weeks
9.4.4.1. ► Features are functionally complete or ‘toggled’ so as not to disrupt demonstrable functionality
9.4.4.2. ► New Features work together and with existing functionality
9.4.4.3. ► Happens after the Iteration review (may lag by as much as one Iteration, maximum)
9.4.4.4. ► Demo from a staging environment which resembles production as much as possible
9.4.5. Innovation and Planning (IP) Iteration
9.4.5.1. ► Innovation: Opportunity for innovation, hackathons, and infrastructure improvements
9.4.5.2. ► Planning: Provides for cadence-based planning
9.4.5.3. ► Estimating guard band for cadence-based delivery
9.4.6. Improving results with the Inspect and Adapt event
9.4.6.1. 3 parts
9.4.6.1.1. The PI System Demo
9.4.6.1.2. Quantitavie and Qualitative Measurement
9.4.6.1.3. Problem-Solving Workshop
9.4.6.2. Timebox : 3 - 4 hr per PI
9.4.6.3. For Teams and stakeholders
9.5. 5. Build a Continuous Delivery Pipeline with DevOps
9.5.1. Achieve higher performance with DevOps
9.5.2. A CALMR approach to DevOps
9.5.2.1. ► Culture
9.5.2.1.1. Establish a culture of shared responsibility for development, deployment, and operations.
9.5.2.2. ► Automation
9.5.2.2.1. Automate the Continuous Delivery Pipeline.
9.5.2.3. ► Lean flow
9.5.2.3.1. Keep batch sizes small, limit WIP, and provide extreme visibility.
9.5.2.4. ► Measurement
9.5.2.4.1. Measure the flow through the pipeline. Implement full-stack telemetry.
9.5.2.5. ► Recovery
9.5.2.5.1. Architect and enable low-risk releases. Establish fast recovery, fast reversion, and fast fix-forward.
9.5.3. DevOps is in the Value Stream
9.5.3.1. Value occurs only when the end users are operating the Solution
9.5.3.2. DevOps isn’t optional. The only question is how efficient it is.
9.5.4. The Continuous Delivery Pipeline enables the flow of value
9.5.4.1. CE+CI+CD+RoD
9.5.4.2. Continuous Exploration – Understand Customer needs
9.5.4.3. Continuous Integration – A critical technical practice of the ART
9.5.4.4. Continuous Deployment – Getting to production early
9.5.4.5. Separate deploy from release
9.5.4.5.1. ► Hide all new functionality under feature toggles
9.5.4.5.2. ► Enables testing background and foreground processes in the actual production environment before exposing new functionality to users
9.5.4.6. Release on Demand – Making value available when it’s needed
9.5.4.7. Architect for releasability
9.5.4.7.1. ► Enablers build up the runway
9.5.4.7.2. ► Features consume it
9.5.4.7.3. ► Architectural Runway must be continuously maintained
9.5.4.7.4. ► Use capacity allocation (a percentage of train’s overall capacity in a PI) for Enablers that extend the runway
10. Exploring Lean Portfolio Management
10.1. Define a SAFe portfolio
10.1.1. Lean Portfolio Management empowers the portfolio
10.1.1.1. ► Strategy and investment funding
10.1.1.2. ► Agile portfolio operations
10.1.1.3. ► Lean governance
10.1.2. Strategy and investment funding is a collaboration
10.1.2.1. Enterprise Ewecutives + Enterprise Architect + Business Owners
10.1.2.2. ► Key stakeholders collaborate to develop and communicate the portfolio strategy
10.1.2.3. ► They provide Lean Budgeting and funding to the Value Streams that develop and maintain the portfolio products and services
10.1.2.4. ► They build a Portfolio Kanban system to establish flow
10.1.3. Large Enterprises will have multiple portfolios
10.1.3.1. In larger Enterprises, there can be multiple SAFe portfolios, typically one for each line of business, business unit, or division
10.1.4. Define the portfolio with the Portfolio Canvas
10.1.4.1. The Portfolio Canvas is a template for identifying a specific SAFe portfolio
10.1.4.2. It defines the domain of the portfolio and other key elements
10.1.5. Categorize investments by horizon (maturity stage)
10.1.5.1. Map Solutions by horizon
10.2. Connect the portfolio to Enterprise strategy
10.2.1. A model for Enterprise strategy formulation
10.2.2. Establish Strategic Themes
10.2.2.1. ► Differentiation from the current state to the desired future state
10.2.2.2. ► A collaboration between LPM and the larger Enterprise
10.2.2.3. ► Enterprise business drivers drive Strategic Themes
10.2.2.4. ► Portfolio context influences Strategic Themes
10.2.3. Strategic Themes influence what gets built
10.2.3.1. ► Strategic Themes are differentiating, specific, and itemized business objectives that connect a portfolio to the strategy of the Enterprise.
10.2.3.1.1. — Provide context for decision-making, inputs to the Vision, budget, and backlogs
10.2.3.1.2. — Adjust ART and Value Stream funding to track changing strategic priorities
10.2.3.1.3. — Assist with Epic evaluation and decision-making
10.2.3.1.4. — Influence each Program Vision and Roadmap
10.3. Maintain the Portfolio Vision
10.3.1. Identify opportunities for the portfolio’s future state with SWOT
10.3.1.1. ► Establishes an understanding of your organization’s strengths and weaknesses
10.3.1.2. ► Identifies the most significant opportunities and potential threats
10.3.1.3. Matrix
10.3.1.3.1. Internal
10.3.1.3.2. External
10.3.2. TOWS strategic options matrix
10.3.2.1. ► TOWS is used primarily for identifying strategic options to create a better future state
10.3.2.2. Matrix
10.3.2.2.1. Internal strengths vs External opportunities
10.3.2.2.2. Internal strengths vs External Threats
10.3.2.2.3. Internal Weaknesses vs External opportunities
10.3.2.2.4. Internal Weaknesses vs External Threats
10.3.3. Envision the future state
10.3.3.1. ► The portfolio canvas captured current state
10.3.3.2. ► Use SWOT and TOWS to brainstorm potential future states
10.3.3.3. ► Evaluate your options, and pick a future state
10.3.3.4. ► Identify the Epics that will get you there
10.3.4. Express the future state as a Vision
10.3.4.1. Use : A postcard from the future tool
10.3.4.2. Aspirational, yet realistic and achievable
10.3.4.2.1. It must be compelling and somewhat futuristic, yet practical enough to be feasible over some meaningful timeframe
10.3.4.3. Motivational to engage others on the journey
10.3.4.3.1. The vision must align with the Strategic Themes, as well as to the individual team’s purpose
10.4. Establish portfolio flow
10.4.1. Govern Epic flow with the Portfolio Kanban
10.4.1.1. ► Makes largest business initiatives visible
10.4.1.2. ► Brings structure to analysis and decision-making
10.4.1.3. ► Provides WIP limits to ensure the teams analyze responsibly
10.4.1.4. ► Helps prevent unrealistic expectations
10.4.1.5. ► Helps drive collaboration amongst the key stakeholders
10.4.1.6. ► Provides a transparent and quantitative basis for economic decision-making
10.4.2. MVPs foster innovation and control scope
10.4.3. Epic hypothesis statement template
10.5. Fund Value Streams
10.5.1. Problem: Cost-center budgeting
10.5.1.1. Traditional project-based, cost-center budgeting creates overhead and friction, lowers velocity
10.5.2. Problem: Projects increase cost of delay
10.5.2.1. When overruns happen, project accounting and re-budgeting increases cost of delay and impacts culture.
10.5.3. Solution: Fund Value Streams not projects
10.5.3.1. Funding Value Streams provides for full control of spend, with:
10.5.3.1.1. ► No costly and delay-inducing project cost variance analyses
10.5.3.1.2. ► No resource reassignments
10.5.3.1.3. ► No blame game for project overruns
10.5.4. Control costs with increased flexibility
10.5.4.1. ART budgets and resources are unaffected by Feature cost overruns or changing priorities
10.5.5. Maintain the Guardrails
10.5.5.1. ► Apply investment horizons
10.5.5.2. ► Continuous Business Owner engagement
10.5.5.3. ► Approve Epic initiatives
10.5.5.4. ► Utilize capacity allocation
11. Leading the Change
11.1. Lead by example
11.1.1. ► Authenticity
11.1.1.1. requires leaders to model desired professional and ethical behaviors.
11.1.2. ► Emotional
11.1.2.1. intelligence describes how leaders identify and manage their emotions and those of others through selfawareness, self-regulation, motivation, empathy, and social skills
11.1.3. ► Lifelong learning
11.1.3.1. depicts how leaders engage in ongoing, voluntary, and self-motivated pursuit of knowledge and growth, and they encourage and support the same in others
11.1.4. ► Growing others
11.1.4.1. encourages leaders to provide the personal, professional, and technical guidance and resources each employee needs to assume increasing levels of responsibility
11.1.5. ► Decentralized decision-making
11.1.5.1. moves the authority for decisions to where the information is
11.2. Lead the change
11.2.1. Keys to leading successful change
11.2.1.1. 1. ► Establish a sense of urgency
11.2.1.2. 2. ► Create a powerful guiding coalition
11.2.1.3. 3. ► Develop the vision and strategy
11.2.1.4. 4. ► Communicate the vision
11.2.1.5. 5. ► Empower employees for broad-based action
11.2.1.6. 6. ► Generate short-term wins
11.2.1.7. 7. ► Consolidate gains and produce more wins
11.2.1.8. 8. ► Anchor new approaches in the culture
11.2.2. SAFe® Implementation Roadmap
12. Team Backlog
12.1. Containes
12.1.1. User Stories
12.1.2. Enabler Srories
12.1.2.1. Created by Enterprise Architects supporting the portfolio backlog, or Solution and System Architects/Engineering
12.1.3. Improvement Stories
12.1.4. NFRs
12.1.4.1. Define system attributes such as security, reliability, performance, maintainability, scalability, and usability
12.1.4.2. Serve as constraints or restrictions on the design of the system across the different backlogs
12.1.4.3. Are typically revisited as part of the Definition of Done (DoD)
12.1.4.4. Are often defined in the acceptance criteria for multiple backlog items
12.1.4.5. System and Solution Architect and Engineering are often responsible for defining and refining these NFRs
12.2. Inputs
12.2.1. Program Backlog
12.2.2. Lacal context stories
12.2.2.1. Refector
12.2.2.2. Maintenance
12.2.2.3. Technical Debt
12.2.3. From Iteration Retrospective
12.2.4. Other Stakeholders
12.2.4.1. Other team's dependancies
12.2.4.2. Spikes / researches
12.2.4.2.1. exploration Enabler Story
12.2.4.3. Other commitments
12.3. PO is responsible for it
12.3.1. anyone can write stories
12.3.2. approving them into the team backlog and accepting them into the system baseline are the responsibility of the PO
12.4. PO is responsible for
13. Program Backlog
13.1. Contains
13.1.1. Business Features
13.1.1.1. For PM + PO
13.1.2. Enabler Features
13.1.2.1. For System Archi/Eng
13.2. Inputs
13.2.1. From Continuous Exploration
13.2.1.1. items in these backlogs result from research activities and active collaboration with various stakeholders
13.2.1.1.1. Customers, Business Owners, Product Management, Product Owners, System and Solution Architects/Engineering, and more