SAFe 4.5 Advanced Scrum Master Study Notes *mvsafe's* SAFe Advanced Scrum Master 4.5 (ASM) PRACTICE EXAM questions and answers - ✔https://quizlet.com/356419609/safe-4-advanced-scrum-master-45-practiceteam-70-passing-flash-cards/ *umarani's* leading safe 4.0 exam questions and answers NOTE: It is the same questions as 'mvsafe' SAFe ASM 4.5 - ✔http://umarani.com/howpass-leading-safe-40-exam SAFe Questions and Answers - ✔https://quizlet.com/177551883/safe-questions-flashcards/ *barnyardman's* SAFe 4 study notes - ✔https://quizlet.com/201371450/safe-4-flashcards/ *Role: Scrum Master* -https://www.scaledagileframework.com/scrum-master/ -- Relate note-* Agile team * Kanban * Agile Release Train (ART) * Lean-Agile Leader * Lean-Agile Mindset * SAFe Core Values * SAFe Principles * Built-In Quality * Iteration Goals * Program Increment (PI) Objectives * Iteration Planning * Iteration Review * Iteration Retrospective * Iteration * Program Increment * System Team * User Experience * Shared Services * PI Planning * System Demos * Inspect and Adapt * Features and Capabilities * Enterprise - ✔* Scrum Masters are servant leaders and coaches for an Agile Team. * An effective Scrum Master is a team-based servant leader who:
- Exhibits Lean-Agile leadership - Supports the team rules - Facilitates the team's progress toward team goals - Leads team efforts in relentless improvement - Facilitates meetings - Supports the Product Owner - Eliminates impediments - Promotes SAFe quality practices - Builds a high-performing team - Protects and communicates - Responsibilities on the train - Coordinates with other teams - Facilitates preparation and readiness for ART events - Supports estimating -*The Scrum Master role* is a unique Agile team member who spends much of her time helping other team members communicate, coordinate, and cooperate; generally, this person assists the team in meeting their delivery goals. *The Scrum Master is a servant leader* who enables teams to self-organize, selfmanage, and deliver via effective Lean-Agile practices. The Scrum Master supports and enforces the Scrum process and other rules that the team has agreed. The Scrum Master also helps the team coordinate with other teams on the Agile Release Train (ART) and communicates status to management as needed. Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise *1.1: Characteristics of an effective Agile Team* - ✔* Able to reliably deliver * Its members are not afraid to challenge each other's ideas for the ultimate win * Makes process visible to themselves and to their stakeholders * Collaborates to achieve Iteration goals and PI Objectives * Produces consistent, high-quality increments of value * Sustains a predictable pace of development * Able to pivot when necessary Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise *1.2: Modern enterprises introduce a bigger challenge* - ✔The team in the Enterprise is affected by other teams, stakeholders, and processes that fall outside of their control Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise *1.3: Teams must improve relentlessly* - ✔Apart from the impediments to developing and delivering value, Agile Teams in the Enterprise may encounter significant roadblocks to growth Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise - Know the purpose and basic constructs of SAFe *1.4: The Scaled Agile Framework (SAFe)* - ✔* Synchronizes alignment, collaboration, and delivery for large numbers of team
* Core Values 1. Built-In Quality 2. Program execution 3. Alignment 4. Transparency Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise - Know the purpose and basic constructs of SAFe *1.5: Essential SAFe* - ✔Essential SAFe provides the basis for success Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise - Know the purpose and basic constructs of SAFe *1.6: Nothing beats an Agile Team* - ✔* Empowered, self-organizing, self-managing, cross-functional team * Delivers valuable, tested, working system every two weeks * Uses a team framework which combines the best of Scrum project management, XPinspired technical practices, and Kanban for flow Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise - Know the purpose and basic constructs of SAFe *1.7: Except a team of Agile Teams* - ✔* Self-organizing, self-managing , team of Agile Teams * Delivers working, tested full-system increments every two weeks * Operates with Vision, architecture, and UX guidance * Common iteration lengths and estimating * Face-to-face planning for collaboration, alignment, and adaptation Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise - Know the purpose and basic constructs of SAFe *1.8: Portfolio SAFe* - ✔Portfolio SAFe aligns strategy and execution Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise - Know the purpose and basic constructs of SAFe *1.9: Large Solution SAFe* - ✔Large Solution SAFe coordinates ARTs with a Solution Train Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise - Know the purpose and basic constructs of SAFe *1.10: Full SAFe* - ✔Some enterprises require Full SAFe Lesson 1: Exploring the Scrum Master Role in the SAFe Enterprise - *Establish Scrum Master connections in the Framework* - ✔Using the Big Picture, draw connections from the Scrum Master to other Framework elements, based on: - Communication - Collaboration
- Problem-solving - Inputs/outputs - Other ideas you have Lesson 2 - Apply SAFe Principles: A Scrum Master Perspective *2.0: SAfe Lean-Agile Principles* - ✔SAFe Lean-Agile Principles 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 Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: *#1 Take an economic view* - Base decisions on economics - ✔Many decisions at the Team Level impact development economics * Validate key decisions based on how they impact the five variables * Team makes thousands of decisions during the PI * Effective team process leverages more economically-feasible ways of product development * Take an economic view does not always require knowing 'dollarized value' but is rather a general thinking tool -- Cycle time vs. product cost - Cycle time vs. value - Cycle time vs development expense -Product cost vs. development expense Product cost vs. Value Product cost vs. Cycle time -Development expense vs. Value Development expense vs Cycle time Development expense vs. Product Cost -Risk Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #1 Take an economic view *1.1 Base decisions on economics - Consider examples* - ✔Following are examples of indicators that may have surprisingly high economic impact in the long run * Cost of late defect fixing * Cost of branching with late merge
* Cost of delayed performance testing * Cost of large batch of cross-team dependencies * Economic value of test automation * Economic value of "Enablers" such as research spikes, refactors, etc. -NOTE: Cost of fixing a defect grows nearly exponentially over time Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: *#2 Apply system thinking* - ✔* Complex systems development requires disciplines, systematic systems thinking * Optimizing a component does not optimize the system * The value of a system passes through its interconnections * A system can evolve no faster than its slowest integration point * Understand and optimize the full Value Stream Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #2 Apply system thinking *2.1 Take a system view on value delivery* - ✔All we are doing is looking at the timeline, from when the customer gives us a order to when we collect the cash. Anad we are reducing the timeline by reducing the non-value added wastes - Taiichi Ohno -Understand the full Value Stream: * Most inefficiencies and impediments in your process will surface themselves as delays in value delivery * Consider all steps as part of the Value Stream, including definition, analysis, validation, deployment, and release * Customers and suppliers are part of your Value Stream * Establish a culture of relentless improvement of the full Value Stream -Request->Approve->Technical assessment->Code & Test->Verify->Deploy Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #2 Apply system thinking *2.2 What are cycle times?* - ✔* Time to finish a task * Time to finish a story * Time to deploy to production -Reduce 'cycle time' Make decisions that result in a *reduction of cycle times* (total time to complete something and get value from it) Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #2 Apply system thinking *2.3 Reduce cycle times / improve flow!* - ✔A tale of two stories -Story A: Time to complete: 3 iterations (Code, Test, Fix, Test, Done-Done) (3 days) Story B: Time to complete: 5 days (Code, Test, Fix, Test, Done-Done) -Result: Cycle Time savings = 25 days
Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #2 Apply system thinking *2.4 Move from bottleneck to bottleneck* - ✔I say an hour lost at a bottleneck is an hour out of the entire system. I say an hour saved at a non-bottleneck is worthless. Bottlenecks govern both throughput and inventory - Eliyahu M. Goldratt, The Goal -* The Scrum Master is an Eanbler who helps the team identify and remove bottlenecks. * Every system has only one or two bottlenecks that significantly constrain performance. * Once you have identified an removed the current bottleneck, there will be another one, but the system is already operating at higher level of performances! Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: *#3 Assume variability; preserve options* - Development occurs in an uncertain world ✔Aggressively evaluate alternatives. Converge specifications and solution sets - Allen Ward. -* You cannot possibly know everything at the start * Requirements and designs must be flexible to build an optimum solution * Iterative and incremental development aims at reducing uncertainty over time Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #3 Assume variability; preserve options *3.1 Common problem of many organizations* - ✔When Agile practices are adopted on top of a traditional, phase-gate mindset, teams end up with a typical problem: * They follow an iterative and incremental development model while committing to a specific Solution option early in the process * As a result, the power of Agile is significantly underused and reduced to applying only minor adjustments -- Too many constraints up front Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #3 Assume variability; preserve options *3.2 Different thought process is needed* - ✔'Just-in-Time' elaboration of requirements and design - Not everything should be defined at once - Better requirements and implementation options will merge over the course of Iterations - Up-front thinking is not enough; 'learning by doing' must extend the paradigm -'Set-based design' - If you can't be right early on, preserve multiple options until you have more certainty - Narrow them down over the course of the learning points and Iterations Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: *#4 Build incrementally with fast, integrated learning cycles*
*4.1 Apply fast learning cycles* *PDCA* * Plan * Do * Check * Adjust - ✔Fast feedback accelerates knowledge. * Improves learning efficiency by decreasing the time between action and effect * Reduces the cost of risk-taking by truncating unsuccessful paths quickly * Facilitated by small batch sizes * Requires increased investment in development environment -The shorter the cycles, the faster the learning Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #4 Build incrementally with fast, integrated learning cycles *4.2 Integration points control product development* - ✔Product development is the process of converting uncertainty to knowledge - Dantar P. Oosterwal -* Integration points accelerate learning * Development can proceed no faster than the slowest learning loop * Improvement comes through synchronization of design loops and faster learning cycles Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #4 Master Perspective: Build incrementally with fast, integrated learning cycles *4.3 Integration points reduce risk* - ✔See diagram https://www.scaledagileframework.com/build-incrementally-with-fast-integrated-learningcycles/ Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: * #5 Base milestones on an objective evaluation of working systems* *5.1: The problem of phase gate milestones* - ✔Phase gates fix requirements and designs too early, making adjustments costly and late as new facts emerge. - Tracking progress via traditional milestones delays critical learning points until it's too late Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #5 Base milestones on an objective evaluation of working systems *5.2: Apply objective milestones* - ✔Program Increment (PI) Demos are orchestrated to deliver objective progress, product, and process metrics -* Progress -> Objectives * PRoduct -> Performance, Customer feedback * PRocess -> Improvement stories -PI Demos (Objectives, Performance, Customer feedback, I&A)
Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #5 Base milestones on an objective evaluation of working systems *5.3: Iterate to the optimum solution* - ✔Objective Milestones facilitate learning and allow for continuous, cost-effective adjustments towards an optimum solution. Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: * #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths* *6.1: How can we reduce cycle times?* - ✔* Reduce size of work * Reduce bottlenecks * Reduce waiting * Increase swarming * Improve quality Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.1: Reduce WIP* - ✔Reduce Work-In-Progress Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.2: WIP and Flow* - ✔When there's too much WIP, there's no visibility into the bottlenecks and the system is usually highly inefficient. -At the surface, however, it all looks smooth and promising Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.3: Too much WIP slows down the enterprise* - ✔WIP levels of the team and the program are connected. Understanding the connection creates improvement opportunities Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.4: Visualize and limit WIP* - ✔One team's Big Visible Information Radiator (BVIR) - How is this team doing? - How do you know that? --- WIP Board --Not started | Development | Test | Accepted Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.5: The importance of small batches* - ✔Small batches go through the system faster, with lower variability. * Large batch sizes increase variability * High utilization increases variability
* Severe project slippage is the most likely result * Most important batch is the transport (handoff) batch * Proximity (co-location) enables small batch size * Good infrastructure enables small batches -Book to read - Implementing Lean Software Development by Mary Poppendieck - Principles of Product Development Flow by Don Reinertsen Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.6: Finding optimum batch size* - ✔Optimum batch size is an example of a U-curve optimization. * Total costs are the sum of holding costs and transaction costs * Higher transaction costs shift optimum batch size higher * Higher holding costs shift batch size lower Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.7: Reducing optimum batch size* - ✔Reducing transaction costs reduces total costs and shifts optimum batch size lower. * Reducing batch size: - Increases predictability - Reduces rework - Lowers cost * Batch size reduction probably saves twice what you think -Book to read - Principles of Product Development Flow by Don Reinertsen Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.8: Manage queue lengths* - ✔Log queues: All bad * Log queues created - longer cycle times - increased risk - more variability - lower quality - less motivation Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths *6.9: Reduce queue lengths* - ✔Formula: Average wait time = average queue length / average processing rate -* Understand Little's Law
* Faster processing time decreases wait * Control wait times by controlling queue lengths -Example: Given average process speed of 10 Features per quarter and a committed set of 30 Features, a new Feature will experience approximate wait time of 3Q. -30 items / 10 items per Q = 3Q Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: *#7 Apply cadence, synchronize with cross-domain planning* *7.1: Cadence and synchronization* - ✔Cadence * Transforms unpredictable events into predictable events * Makes waiting times predictable - If you can't predict delivery, existing programs become Feature magnets * Facilitates planning; provides more efficient use of resources * Delivering on cadence requires scope or capacity margin -Synchronization * Synchronization causes multiple events to happen at the same time * Sync events facilitate cross-functional tradeoffs of people and scope * Periodic resynchronization limits variance to a single time interval * Regular integration provides high fidelity tests and objective assessment * To work effectively, design cycles must be synchronized -Book to read - The lean machine by Dantar Ootserwall - Principles of Product Development Flow by Don Reinertsen Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #7 Apply cadence, synchronize with cross-domain planning *7.2: Control variability with planning cadence* - ✔Cadence-based planning limits variability to a single interval -Asynchronous planning - Emergency replanning, Max deviation 3X over time -Cadence-based planning - Max deviation over time Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #7 Apply cadence, synchronize with cross-domain planning *7.3: Synchronize with cross-domain planning* - ✔"Future product development tasks can't be pre-determined. Distribute planning and control to those who can understand and react to the end results" - Michael Kennedy, Product Development for the Lean Enterprise -* All stakeholders face-to-face, (but typically multiple locations)
* Management sets the mission, with minimum possible constraints * Requirements and design happen * Important stakeholder decisions are accelerated Teams created - and take responsibility - for plans Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: #8 * #8 Unlock the intrinsic motivation of knowledge workers* *8.1: Drive - The puzzling puzzles of Harry Harlow* - ✔The 1949 experiment * Eight rhesus monkeys for a two-week experiment on motivation and learning * Puzzles were placed in the cages -Results * Unprompted, the monkeys solved the puzzles on their own * An interesting and not understood phenomenon * As a motivator, raisins were added as rewards * Result: the monkeys made more errors and solved the problems less frequently -Quote "It appears that the performance of the task provides its own intrinsic reward... this drive... may be as basic as the others" by The Surprising Truth About What Motivates US, Daniel H. Pink Lesson 2 - Apply SAFe Principles: Scrum Master Perspective: *#9 Decentralize decision-making* *9.1: Decentralize decision-making* - ✔Quote "Any inefficiency of decentralization costs less than the value of faster response time" Principles of Product Development Flow by Don Reinertsen -* Decentralize all others: - Frequent decisions - Time-critical decisions - Decision that require local information * Define the economic logic behind a decision' empower individuals and teams to actually make them Lession 3 - Exploring Agile and Scrum Anti-Patterns - *Explore anti-patterns associated with the Product Owner role* *3.1 Recognizing anti-patterns* - ✔As an Agile coach, the Scrum Master must learn to recognize anti-patterns in the process. * Anti-patterns can be structural or behavioral - Structural example: Team has more than one Product Owner - Behavioral example: Partially completed stories are being carried over from Iteration to Iteration -* Anti-patterns can be internal or external - Internal example: Developers don't work collaboratively on stories - External example: Lack of coordination with other teams leads to excessive WIP
Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Explore anti-patterns associated with the Product Owner role* *3.2: Many anti-patterns can be traced to the PO role* - ✔Underperforming in the Product Owner role can lead to dysfunction on the team. * Key responsibilities of the Product Owner: - Facilitate Team Backlog refinement - Prepare for and participate in Iteration Planning - Elaborate stories and Enablers ' just-in-time' - Address team questions; b the 'voice of the customer' - Accept stories - Participate in the Iteration Review and retrospective - Coordinate with other Product Owners to manage dependecies Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Learn how Stories and tasks may lead to anti-patterns* *3.3: Big stories are a frequent source of anti-patterns* - ✔A team that can't iterate isn't able to inspect and adapt. - Big stories do not support team iteration - Smaller stories allow for faster, more reliable implementation - Splitting bigger stories into smaller ones is an essential skill Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Learn how Stories and tasks may lead to anti-patterns* *3.4: Ways to split a story* - ✔* By business rule variations * By use case scenario * Simple / complex -www.scaledagileframework.com/story Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Learn how Stories and tasks may lead to anti-patterns* *3.5: Split by business rule variations* - ✔Business rule variations often provide a straightforward splitting scheme. -Example: - As a shopper, I want extra benefits based on how much I buy... -- Splitting story by bronze level, silver level, or gold level Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Learn how Stories and tasks may lead to anti-patterns* *3.6: Split by use case scenarios* - ✔If use cases are used to represent complex interaction, the Story can be split via the individual scenarios. -Example - As a user, I want to enroll in the energy savings program through a retail distributor...
-- Use case/ Story 1: (Happy path) Notify utility that consumer has equipment -- Use case/ Story 2: Utility provisions equipment and data notifies consumer -- Use case/ Story 3: (Alternate scenario) Handle data validation errors Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Learn how Stories and tasks may lead to anti-patterns* *3.7: Split by simple/complex - ✔Simplify! What's the simplest version that can possibly work? -Example - As a user, I basically want a fixed price, but I also want to be notified of critical peak pricing events... -- Splitting -- ...respond to the time and the duration of the critical peak pricing event -- ... respond to emergency events Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* *3.8: Product Owner (PO), backlog, planning, and commitment anti-patterns ✔*Product Owner (PO) and backlog (Anti-Patterns)* * Product Owner and team reach Iteration Planning without preparation * There is more than one Product Owner (PO) per team * Product Owner (PO) is not sufficiently involved during Iteration execution -*Planning (Anti-Patterns)* * Planning is based on tasks, not on User Stories and acceptance criteria! -*Commitment (Anti-Patterns)* * Team does not commit to clear Iteration goals Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* *3.9: Execution, demos, and retrospectives anti-patterns* - ✔*Execution (Anti-Patterns)* * Developers don't work collaboratively on User Stories * Waterfalling Iterations - Team integrates and tests Stories only at Iteration end * 'Done isn't done'; debt is carried forward Iteration to Iteration -*Demos (Anti-Patterns)* * Team delays demos or extends Iteration * Story reported but not demonstrated (non-UI Stories, spikes, refactors, etc.) -*Retrospectives (Anti-Patterns)* * 'Idea fest' instead of focus on near-term, incremental improvements Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment*
*3.10: Reading suggestion* - ✔*"Seven Sins of Scrum and other Agile Anti-patterns"* www.infoq.com/news/2016/03/agileindia-7sins-scrum Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* "Seven Sins of Scrum and other Agile Anti-patterns" * 3.11: S1: Processes & Tools Over Individuals & Interactions* https://www.infoq.com/news/2016/03/agileindia-7sins-scrum - ✔a. Agile is the tool Over Tools to support agility b. Agile is a process Over Agility is a mindset c. Best practices Over Principles & values d. One size fits all Over Context e. Collaboration Over Shared ownership Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* "Seven Sins of Scrum and other Agile Anti-patterns" * 3.11: S2: Status Over Flow of Value* https://www.infoq.com/news/2016/03/agileindia-7sins-scrum - ✔a. Showing progress Over Delivering value b. Checking boxes Over Learning & adapting c. "My part is done" Over "Team is done" d. Starting Over Finishing e. Individual utilization Over Team throughput f. Specialization Over Generalization Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* "Seven Sins of Scrum and other Agile Anti-patterns" * 3.11: S3: Stories Over Strategy* https://www.infoq.com/news/2016/03/agileindia-7sins-scrum - ✔a. Buckets (chunks of work) Over Filters (flow of value) b. "I want it all" Gluttony Over Minimum viable product c. Listening to customers Over Learning what they really need d. "I know what they need" Over Validating hypothesis e. Tasks Over Stories f. Following orders Over Understanding why Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* "Seven Sins of Scrum and other Agile Anti-patterns" * 3.11: S4: Crap Over Craftsmanship* https://www.infoq.com/news/2016/03/agileindia-7sins-scrum - ✔a. Almost done Over Really done Velocity Over Quality b. Testing quality in Over Building quality in
c. Technical debt is evil Over Technical debt is debt d. Cost of crap Over Cost of delay Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* "Seven Sins of Scrum and other Agile Anti-patterns" * 3.11: S5: Iterations Over Releases* https://www.infoq.com/news/2016/03/agileindia-7sins-scrum - ✔a. Potentially shippable increments Over Releases b. Commitment Over Focus on value c. Capacity planning Over Velocity planning Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* "Seven Sins of Scrum and other Agile Anti-patterns" * 3.11: S6: Illusion Over Reality* https://www.infoq.com/news/2016/03/agileindia-7sins-scrum - ✔a. Gross velocity Over Net velocity b. Unpointed stories Over Best estimate c. Velocity Over Quality d. Estimation Over Forecasting e. Microestimation Over Macroestimation f. Vanity metrics Over Decision metrics Lesson 3 - Exploring Agile and Scrum Anti-Patterns - *Identify context-specific antipatterns in your environment* "Seven Sins of Scrum and other Agile Anti-patterns" * 3.11: S7: Organizational Hacks Over Leadership* https://www.infoq.com/news/2016/03/agileindia-7sins-scrum - ✔a. Controlling inputs Over Controlling outputs/outcomes b. Micromanagement Over Macromanagement d. Taking sides Over Serving the whole team e. Meetings Over Actions & resolutions f. Certification Over Qualification Lesson 4 - Facilitating program execution *4.1 Synchronize development with the Agile Release Train* *4.1.1: Agile Release Trains (ART) deliver Solutions* - ✔A long-lived, self-organizing team of Agile Teams -*Agile Release Trains (ART) deliver Solutions* Define new functionality->Implement->Acceptance test->Deploy->Repeat until further noticed. Project chartering not required. Lesson 4 - Facilitating program execution - 4.1 Synchronize development with the Agile Release Train
*4.1.1: The Agile Release Train* - ✔* A virtual organization of 5 - 12 teams (50 - 125+ individuals) that plans, commits, and executes together * Program Increment (PI) is a fixed timebox; default is 10 weeks * Synchronized Iterations and PIs * Aligned to a common mission via a single Program Backlog * Operates under architectural and UX guidance * Frequently produces valuable and evaluable system-level Solution -Lesson 4 - Facilitating program execution - 4.1 Synchronize development with the Agile Release Train *4.1.2: Cadence without synchronization is not enough* - ✔* Time spent thinking you are on track... When you discover you are not ... Integrate and slip! * The slowest component drags the train, still late discovery! Lesson 4 - Facilitating program execution - 4.1 Synchronize development with the Agile Release Train *4.1.3: Synchronize to assure delivery* - ✔* This system IS sprinting * Probably need help from a System Team *Program Increment - System demos (S1 through S4) - Continuous integration (PI to PI) Lesson 4 - Facilitating program execution *4.2 Organize teams on the train* *4.2.1: Build cross-functional Agile Release Trains* - ✔* Agile Release Train * Teams - Business - Product Management - Architect/System Engineering - Program - Hardware -Software - Testing - Deployment Lesson 4 - Facilitating program execution - 4.2 Organize teams on the train *4.2.2: Organizing teams around value* - ✔* Organize for the larger purpose - Maximize velocity by minimizing dependencies and handoffs, while sustaining architectural robustness and system qualities * A team can organized around - Features - Components * Far less desirable - Architectural layer -> Platform, middleware, UI, DB, business logic, etc. - Other -> Programming language, spoken language, technology, location
Lesson 4 - Facilitating program execution - 4.2 Organize teams on the train *4.2.3: Finding the right trade-off* - ✔Most large programs have a mix. * Lean toward *Feature teams* - Fastest velocity - Minimize dependencies - Develop T-shaped skills -* Use *Component teams* when: - High reuse, high technical specialization, critical NFRs - Create each component as a 'potentially-replaceable part of the system, with welldefined interfaces' -Generally avoid organizing around architectural layers, as they create team coupling and don't provide a technical separation of concerns. Lesson 4 - Facilitating program execution - 4.2 Organize teams on the train *4.2.4: Other ART Roles* - ✔* Release Train Engineer acts as the *Chief Scrum Master* for the train. * Product Management owns, defines, and prioritizes the Program Backlog. * System Architect/Engineering provides architectural guidance and technical enablement to the teams on the train. * The *System Team* provides processes and tools to integrate and evaluate assets early and often. **Business Owners* are the key stakeholders on the Agile Release Train (ATR). Lesson 4 - Facilitating program execution - 4.2 Organize teams on the train *4.2.5: Release Train Engineer (RTE) acts as the "Chief Scrum Master" for the Agile Release Train (ART)* - ✔Responsibilities of the RTE include: * Manage and optimize flow of value through the program * Facilitate PI Planning readiness and the event itself * Aggregate and communicate PI Objectives * Assist with execution and Features completion tracking * Assist with economic decision-making through Feature estimation and roll-up to Value Stream and portfolio * Escalate and track impediments * Foster collaboration between teams and system-level stakeholders' manage risks and dependencies * Drive relentless improvement via Inspect and Adapt Lesson 4 - Facilitating program execution - 4.2 Organize teams on the train *4.2.6: Release Train Engineer (RTE) and Scrum Master - RTE-SM community supports Agile Release Train (ART) execution* - ✔* Release Train Engineer (RTE) is often best fit to assist Scrum Masters in removing systemic impediments * RTE and SMs see problems with the train/team structure firsthand
* Together RTE and Scrum Masters are able to take a systems view of the Agile Release Train * Operating as a community is important: - Regularly meet to discuss problems - Exchange experiences Lesson 4 - Facilitating program execution - 4.2 Organize teams on the train *4.2.7: The Product Manager owns the Program Backlog* - ✔* Assumptions about requirements need to be validated. Teams must quickly feed emerging knowledge back into the Solution. * *Primary responsibilities of Product Managers*: - Understand customer needs; validate Solutions - Work with System Architect/Engineering to understand the value of Enablers - Develop and communicate Vision and Roadmap - Manage and prioritize the flow of work to the program - Prepare for and participate in PI Planning - Define releases and program increments - Participate in demos and Inspect and Adapt - Build and effective Product Manager/Product Owner team Lesson 4 - Facilitating program execution - 4.2 Organize teams on the train *4.2.8: The Product Owner (PO) / Product Manager (PM) team steers the train* - ✔At scale, a single person cannot handle product and market strategy while also being dedicated to an Agile Team. - Product Manager owns *Program backlog* - Product Owner owns *Team backlog* - Team implements *value* Lesson 4 - Facilitating program execution - *4.3 Plan the Program Increment* *4.3.1: PI PLanning* - ✔Cadence-based PI PLanning meetings are the pacemaker of the Agile Enterprise. * Two days every 8 - 12 weeks (10 weeks is typical) * Everyone attends in person if at all possible * Product Management owns Feature priorities * Development teams own Story planning and high-level estimates * Architect/Engineering and UX work as intermediaries for governance, interfaces, and dependencies Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.2: The PI Planning process* - ✔* Input: Vision and top 10 Features * Output: Team and Program PI Objectives and Program Board Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.3: Day 1 agenda* - ✔* 8 am - State of the business and upcoming objectives * 9 am - Vision and prioritized Features * 10:30 am
- Architecture, common framework, etc. - Agile tooling, engineering practices, etc. * 11:30 am - Facilitator explains planning process * 1:00 pm - Teams develop draft plans and identify risks and impediments - Architects and PRoduct Managers circulate * 4:00 pm - Teams present draft plans, risks, and impediments * 5:00 pm - Adjustments made based on challenges, risks, and impediments Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.4: Business context* - ✔* To kick off PI Planning, executive leadership shares the state of the business and upcoming objectives. * There is no prescribed format, but some options include: - The key portfolio priorities are communicated - The organization's strengths, weaknesses, opportunities, and threats (SWOT) are analyzed Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.5: Product / Solution Vision* - ✔Product Management presents the Vision and the high-priority Features Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.6: Architecture, User Experience (UX), and development practices* - ✔Architecture, UX, and development practices are first-class citizens in PI Planning, not afterthoughts! * A system architect presents the Vision for architecture, new architecture EPics, and common frameworks * Development management may provide updates on Agile tooling and improvements in engineering practices * UX professional provide guidance around usability issues Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.7: Team breakout #1* - ✔*In breakouts, each team breaks down their Features into user Stories that are estimated and placed into Iterations. * Ther is a lot of back and forth between the teams, mostly about understanding and minimizing dependencies. Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.8: Team Plan* - ✔* Iteration 1.1, 1.2, 1.3, 1.4, 1.5 * Iteration includes Velocity and Load - For velocity, use historic information or 8 x (number of developers + testers) - Be sure to adjust for holidays and vacation time -* PI Objectives, Stretch objectives * Risk * Color coding gives visibility into investments - Green = User Stories
- Orange = Infrastructure/Enablers - Yellow = Exploration Enablers - Purple = Maintenance - Red/Pink without checked= Risks and dependencies - Red/Pink with checked= Addressed risks and dependencies -Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.9: Program Board* - ✔*Program board - feature delivery, dependencies, and milestones* Example of program board activities: - A program Milestone or event is happening in Iteration 1.3 (e.g., a trade show, market release, etc.) - This Feature cannot be delivered until multiple teams complete their dependencies. - A feature placed in a team's swim lane with no strings means that it can be completed independently of other teams -Program board color codes: - Blue = Features - Red/Pink = Significant Dependency - Orange = Milestone/Event - Red String = A dependency requiring Story or other dependencies to be completed before the Feature can be completed Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.10: Align to a mission with PI Objectives* - ✔* Objectives are business summaries of what each team intends to deliver in the upcoming PI. * They often map directly to the Features in the backlog, but not always. For Example: - Aggregation of a set of Features, stated in more concise terms - A milestone, such as a trade show - An Enabler Feature needed to support the implementation - A major refactoring Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.11: Stretch objectives* - ✔* Stretch objectives provide a reliability guard band. * Stretch objectives do count in velocity/capacity: - They are planned; they aren't extra things for teams to do ' just in case you have time' - But they are not included in the commitment, thereby making the commitment more reliable - If a team has low confidence in meeting a PI Objective, encourage them to move it to stretch - If an item has many unknowns, consider moving it to stretch, and put in early spikes Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.12: Scrum of Scrums* - ✔* The hourly Scrum of Scrums checkpoint helps keep teams on track and supports early identification of risk.
* Hourly Scrum of Scrum planning checkpoint: - Keep teams on track with hourly planning Milestones - Help drive out risks, impediments, and dependencies -Example: Scrum Master Check-In Planning Radiator (Day 1, Check-in 1) - Do you understand the planning requirement? - Do you know who your team is for the whole Iteration? - Is your working space setup? - Do you have a Scrum Master & PO? - Do you have access to the team members and stakeholders you need? - Do you understand (and can fine) the Vision that drives your Iteration backlog? - Have you identified your 4+1 velocities? Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.13: Draft plan review* - ✔*Plans are peer reviewed by all teams. Example: Draft plan review agenda: 1. Velocity (capacity) and load 2. Draft PI Objectives 3. Program risks and impediments 4. Q&A Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.14: Management review and problem-solving* - ✔* At Day end, management meets to make adjustments to scope and objectives based on the day's planning. * Common questions during the managers' review: - What did we just learn? - Where do we need to adjust Vision? Scope? Resources? - Where are the bottlenecks? - What Features must be de-scoped? - What decisions must we make between now and tomorrow to address these issues? Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.15: Day 2* - ✔* 8 am - *Planning adjustments* - Planning adjustments made based on previous day's management meeting * 9 am - *Team breakouts* - Teams develop final plans and refine risks and impediments - Business owners circulate and assign business value to team objectives * 11 am - *Final plan review & lunch* - Teams present final plans, risks, and impediments * 1 pm - *Program risks* - Remaining program-level risks are discussed and ROAMed * 2 pm - *PI confidence vote* - Team and program confidence vote * 2:15 pm - *Plan rework if necessary* - If necessary, planning continues until commitment is achieved * After commitment - *Planning retrospective & moving forward* - Retrospective - Moving forward
- Final Instructions Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.16: Make planning adjustments* - ✔Based on the previous day's management review and problem-solving meeting, adjustments are discussed. * Possible changes: - Business priorities - Adjustment to plan - Changes to scope - Movement of resources Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.17: Team breakout #2* - ✔Based on new knowledge (and a good night's sleep), teams work to create their final plans. - In the second team breakout, Business Owners circulate and assign business value to PI Objectives from low (1) to high (10) - Teams finalize the Program Increment plan - Teams also consolidate program risks, impediments, and dependencies - Stretch objectives provide the capacity and guard band needed to increase cadencebased delivery reliability Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.18: Final plan review* - ✔Teams and Business Owners peer-review all final plans. Example of Final plan review agenda: 1. Changes to velocity (capacity) and load 2. Final PI Objectives with business value 3. Program risks and impediments 4. Q&A Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.19: Building the final plan* - ✔* Final plans are collected at the front of the room * Final plans are reviewed by all teams * Business Owners are asked whether they accept the plan * If so, the team's plan and program risk sheet are brought to the front of the room * If not, the plans stay in place and the team continues planning after the review Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.20: Addressing program risks* - ✔* After all plans have been presented, remaining program risks and impediments are discussed and categorized. * ROAMing risks: - *R*esolved - Has been addressed; no longer a concern - *O*wned - Someone has taken responsibility - *A*ccepted - Nothing more can be done. If risk occurs, release may be compromised - *M*itigated - Team has plan to adjust a necessary Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment
*4.3.21: Confidence vote: Team and Program Levels* - ✔* After dependencies are resolved and risks are addressed, a confidence vote is taken at the Team and Program levels. - 'Fist of five' confidence vote -- Range of 1-5 -- 1 = No confidence -- 5 = Very high confidence - A commitment with two parts: 1. Teams agree to do everything in their power to meet the agreed-to objectives 2. In the event that fact patterns dictate that it is simply not achievable, teams agree to escalate immediately so that corrective action can be taken Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.22: Plan rework if necessary* - ✔What happens if there is low confidence? Rework! The program timebox: * Just as the Iteration Planning Meeting is timeboxed, so is the PI Planning Meeting. * Leaving the two-day planning meeting without a committed plan is not an option. Team stay to rework their plans and 'ROAM' their risks and impediments. Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.23: Run a Planning Meeting retrospective* - ✔* The PI Planning Meeting will evolve over time. Ending with a retrospective will help it continuously improve. - The planning Meeting retrospective 1. What went well 2. What didn't 3. What we can do better next time * Add the action items to your Program Backlog and take action! Lesson 4 - Facilitating program execution - 4.3 Plan the Program Increment *4.3.24: Moving forward* - ✔* The moving-forward portion describes what happens after PIPlanning ends. - Capturing objectives and Stories in Agile project management tooling - Aggregating Team PI Objectives to Program PI Objectives - Setting Scrum of Scrum cadence, Release Management Team cadence, System Demo cadence, etc. - Program Backlog refinement and next PI Planning preparation events - Summarizing changes to engineering practices - Cleaning up the room Lesson 4 - Facilitating program execution - *4.4 Execute the Program Increment* *4.4.1: Program events drive the train* - ✔* Program events create a closed-loop system to keep the train on the tracks. - ART Sync - Program events, Team events - Prepare for PI Planning - PI Planning
- Scrum of Scrum - PO Sync - System Demo - Inspect & Adapt Lesson 4 - Facilitating program execution - 4.4 Execute the Program Increment *4.4.2: ART Sync is used to coordinate progress* - ✔*Programs coordinate dependencies through sync meetings >> Scrum of Scrums ->ART Sync<- PO Sync << -Scrum of Scrums - Visibility into progress and impediments - Facilitated by RTE - Participants: Scrum Masters, other select team members, SMEs if necessary - Weekly or more frequently, 30-60 minutes - Timeboxed, and followed by a "meet after" -PO Sync - Visibility into progress, scope, and priority adjustments - Facilitated by RTE or PM - Participants: PMs, POs, other stakeholders, and SMEs as necessary - Weekly or more frequently, 30-60 minutes - Timeboxed, and followed by a 'meet after' Lesson 4 - Facilitating program execution - 4.4 Execute the Program Increment *4.4.3: Demo the full system increment every two weeks* - ✔* Features are functionally complete or 'toggled' so as not to disrupt demonstrable functionality * New Features work together, and with existing functionality * Happens after the teams' demo (may lag by as much as one Iteration, maximum) * Demo from a staging environment, resemble production as much as possible Lesson 4 - Facilitating program execution - 4.4 Execute the Program Increment *4.4.4: Innovation and Planning Iteration* - ✔Facilitate reliability, Program Increment readiness, planning, and innovation * Innovation: Opportunity for innovation spikes, hackathons, and infrastructure improvements * Planning: Provides for cadence-based planning * Estimating guard band for cadence-based delivery -"Provide sufficient capacity margin to enable cadence." by Don Reinertsen, Principles of Product Development Flow Lesson 4 - Facilitating program execution - 4.4 Execute the Program Increment *4.4.5: IP Iteration calendar* - ✔* Validation (if shipping) * Innovation / hackathon / spikes for next PI * PI Planning readiness
*PI Planning * Continuing Education * Inspect and Adapt workshop Lesson 4 - Facilitating program execution - *4.5 Participate in Inspect and Adapt* *4.5.1: Inspect and Adapt* - ✔* Three parts: 1. The PI System Demo 2. Quantitative measurement 3. The Problem-Solving Workshop * Attendees: Teams and stakeholders * Timebox: 3-4 hours per PI Lesson 4 - Facilitating program execution - 4.5 Participate in Inspect and Adapt *4.5.2: PI System Demo* - ✔At the end of the PI, teams demonstrate the current state of the Solution to the appropriate stakeholders. * Often led by Product management, POs, and the System Team * Attended by Business Owners, program stakeholders, Product management, RET, Scrum Masters, and teams Lesson 4 - Facilitating program execution - 4.5 Participate in Inspect and Adapt *4.5.3: Program Performance Reporting* - ✔As part of the Solution Demo, teams compare planned vs. actual PI Objectives. * Teams meet with their Business Owners to self-assess the business value they achieved for each objective * Each team's planned vs. actual business value is then rolled up to the Program Level in the Program Predictability Measure Lesson 4 - Facilitating program execution - 4.5 Participate in Inspect and Adapt *4.5.4: PI Predictability Measure* - ✔The PI Predictability Measure shows whether achievements fall into an acceptable process control band * Target: effective process control range * Predictability sufficient to run the business * Handles common variations * Special causes may still cause excess variation Lesson 4 - Facilitating program execution - 4.5 Participate in Inspect and Adapt *4.5.5: The Problem-Solving Workshop* - ✔Teams conduct a short retrospective, then systematically address the larger impediments that are limiting velocity. * Agree on the problem to solve (Insufficiently reliable release commitments?) * Apply root cause analysis (+ five whys) * Identify the biggest root cause using Pareto Analysis * Restate the new problem for the biggest root cause (Insufficient Architectural Runway) * Brainstorm solutions * Identify improvement backlog items (NFRs) Lesson 4 - Facilitating program execution - *4.6 Release value on demand*
*4.6.1: ART continuously deliver value* - ✔Continuous Delivery Pipeline * Agile Release Train - Continuous Exploration - Continuous Integration - Continuous Deployment - Release on Demand Lesson 4 - Facilitating program execution - 4.6 Release value on demand *4.6.2: Six Recommended Practices for Continuous Deployment (CD) - ✔CD is an important practice for every team member, the team, and the ART. 1. Maintain development and test environments to better match production 2. Maintain a staging environment that emulates production 3. Deploy to staging every Iteration 4. Automate testing of Features and Nonfunctional requirement 5. Automate deployment 6. Decouple deployment from release Lesson 4 - Facilitating program execution - 4.6 Release value on demand *4.6.3: What is DevOps?* - ✔An Agile approach to bridge the gap between development and operations to deliver value faster and more reliably. -Development * Create change * Add or modify features Operations: *Create stability * Create or enhance services -DevOps is a capability of every Agile Release Train Lesson 4 - Facilitating program execution - 4.6 Release value on demand *4.6.4: A CALMR approach to DevOps* - ✔SAFe DevOps --------------*C*ulture - Establish a culture of shared responsibility for development, deployment, and operations *A*utomation - Automate the Continuous Delivery Pipeline *L*ean flow - Keep batch sizes small, limit WIP, and provide extreme visibility *M*easurement - Measure the flow through the pipeline. Implement application telemetry *R*ecovery - Architect and enable low-risk releases. Establish fast recovery, fast reversion, and fast fix-forward Lesson 4 - Facilitating program execution - 4.6 Release value on demand *4.6.5: Decouple deployment from release* - ✔Develop on Cadence and Release on Demand PI One
- Customer preview - *Major release* -PI Two - Subsystem release - *Major release* -PI Three - New Feature Lesson 4 - Facilitating program execution - 4.6 Release value on demand *4.6.6: Decouple release elements from the total solution* - ✔Solution - Streamlet 1 - End-user functionality (released every 2 weeks) - Streamlet 2 - Security updates (released on demand) - Streamlet 3 - Back-office functionality (released every month) - Streamlet 4 - Entire solution (major release every quarter) Lesson 4 - Facilitating program execution - 4.6 Release value on demand *4.6.7: DevOps enables Continuous Delivery* - ✔Agile Release Train PI One * SAFe DevOps ->CALMR PI Two - Release on Demand * Continuous Exploration * Continuous Integration * Continuous deployment Lesson 4 - Facilitating program execution - 4.7 Prepare for the next PI Planning Session* *4.7.1: Key stakeholders prepare briefings* - ✔In preparation for PI Planning, leadership creates a series of briefings to set context. *