<!-- .slide: id="title-slide" --> # Scrum @ Scale --- <!-- .slide: id="credits" --> ## Scrum @ Scale Scrum@Scale is a protected Brand. These slides / presentations are neither endorsed by nor affiliated.. This is not official training or materials. ##### Visit: [Scrum@Scale](https://www.scrumatscale.com/) ------ ## Purpose Here **This is simply my way of learning.** The purpose of these presentations are to help me apply these concepts and practices, and help teach/coach others. --- <!-- .slide: id="success-rating" --> ## Scaling Map * Rows are scaling components * Including 4x mega-issues * Including 12x nodes of S@S framework * Columns are collection of individual assessments ------ ## Rating Your Current Outcomes Rate your current projects and/or product delivery. | | Person A | Person B | Person C | | ---------- | ---------- | --------- |---------- | | Successful | 20% | 30% | 50% | | Challenged | 50% | 40% | 30% | | Failed | 30% | 30% | 20% | ------ ## Rating the Mega-Issues Rate the 4x mega-issues. | Mega-Issues | Person A | Person B | Person C | | ---------- | ---------- | --------- |---------- | | Prioritization | ⬆️ 4️⃣ | ⏸ 3️⃣ | 🟧 3️⃣ | | Working Product | 🟩 2️⃣ | 🟧 3️⃣ | 🟩 1️⃣ | | Org. Refactoring | 🟥 2️⃣ | 🟥 5️⃣ | ⬇️ 2️⃣ | | Org. Culture | ⬆️ 3️⃣ | ⬆️ 5️⃣ | ⏸ 5️⃣ | ------ ## Rating the S@S Nodes Rate the 12x nodes of the S@S framework. | S@S Nodes | Person A | Person B | Person C | | ---------- | ---------- | --------- |---------- | | Team Process | ⬆️ 4️⃣ | ⏸ 3️⃣ | 🟧 3️⃣ | | Exec. Agile Team | 🟩 2️⃣ | 🟧 3️⃣ | 🟩 1️⃣ | | Cont. Improvement | 🟥 2️⃣ | 🟥 5️⃣ | ⬇️ 2️⃣ | | Cross-Team Collab. | ⬆️ 3️⃣ | ⬆️ 5️⃣ | ⏸ 5️⃣ | ------ ## Rating Scale Current node strength * 🟩 = Great. No impediments. * 🟧 = Some impediments (SI). Team not impacted. * ⬆️ = SI. Team progress impacted. Situation improving. * ⏸ = SI. Team progress impacted. Situation stagnant. * ⬇️ = SI. Team progress impacted. Situation deteriorating. * 🟥 = Major impediments. Team totally blocked. ------ ## Rating Scale Strategic importance * 1️⃣ = Least important * 2️⃣ * 3️⃣ * 4️⃣ * 5️⃣ = Most important ------ ## Plot Ratings * Strategic importance on X axis * Current node strength on Y axis * Top-right section are the priorities --- <!-- .slide: id="agile-architecture" --> ## Agile Architecture ------ Underlying structure is a set of largely independent business components with pre-defined interfaces (inputs / outputs). ------ Stable interfaces allow for the components to be modified without disrupting the entire system. ------ This enables organizational design to "emerge" rapidly in response to inspect and adapt cycles. --- <!-- .slide: id="mega-issues" data-background-color="var(--r-background-alt-color)" --> ## Mega Issues Why are organizations struggling to be Agile? --- ## 1. Prioritization > If you can't prioritize, cool agile tools will only make you feel better as you fail **The #1 Challenge** ------ Every team should have a clear, ordered backlog every sprint so they know exactly what they need to do and in what order. No teams are raided for people to start new projects. Backlog flows to stable teams. ------ > "We have multiple conflicting priorities" > "Our teams are constantly disrupted by changes for new projects" > "Everything is number one priority" ------ ## Great Every team has a clear, ordered backlog every sprint so they know exactly what they need to do and in what order. ------ ## Good No teams are raided for people to start new projects. Backlog flows to stable teams. ------ ## Bad Symptoms > “We have multiple conflicting priorities.” > “Our teams are constantly disrupted by changes for new projects.” > “Everything is the number one priority.” ------ ## Blocked Even in well run agile organizations, our assessments show that only 70% of the people are working on backlog relevant to the business. --- ## 2. Working Product > If you can deliver, cool technical tools will just keep you busy as you fail. ------ How often are you releasing value to customers? --- ## 3. Organization Refactoring > If you can't regularly refactor the organization to focus on priorities, no scaling framework will prevent you from failing. ------ ## Great Teams are easily refactored to optimize production. ------ ## Good Our reliance on Subject Matter Experts limits our ability to refactor. ------ ## Bad Symptoms > “These people report to me.” >“I can change their priorities.” > “I’m bonused to build my empire.” ------ Our HR policies and territorial behavior make it almost impossible to move people around. --- ## 4. Company Culture > If you can't change your company culture being at odds with agility, your implementation will limp along. ------ > "Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes." ##### Josh Seddon ------ Structure ⬇️ System ⬇️ Culture ------ ## Great This is a place where everyone can speak their mind without fear of repercussion or ridicule. ------ ## Good We are supposed to have a culture of learning; it just seems people keep forgetting that. ------ ## Bad Symptoms > "Any new idea has to go through a long chain of commands." > "Other business units are always stealing our budget." > "You can't appear to fail here; your career would be at risk." ------ ## Blocked There's so much hierarchy and so many behind-the-scenes deals, its a wonder we get anything done at all. --- <!-- .slide: id="transformation" --> ## Transformation Path ------ 1. Create a shared understanding of success 1. Choose your start point (who, what, where) 1. Establish the **Executive Action Team** 1. Open the **MetaScrum** 1. Initiate cultural changes 1. Form teams around a **Product Backlog** 1. Launch a reference model 1. Deliver value every sprint 1. **Inspect and adapt** - Product/Process/Org. 1. Rinse and repeat until whole org. is Scrum --- <!-- .slide: id="scrum-master-cycle" --> ## The Scrum Master Cycle As a Practitioner, I need to understand how the SM Cycle works, so that I can help my organization eliminate impediments. --- <!-- .slide: id="team-process" data-background-color="var(--r-background-alt-color)"--> ## Team Process As a Practioner, I need to understand that *if you can't **Scrum** you can't **Scale***. ------ ### Scaling a broken system doesn't work Before you scale a Scrum implementation, teams must be operating consistently with the Scrum Guide or any **deficiencies will be magnified**. ------ Initially, identify a set of dependent teams and create a supportive structure. This set of teams will discover what organizational issues block agility and create opportunities to solve them. ------ It is useful to identify organizational impediments and strive to eliminate them as quickly as possible. ------ When they reach a maturation point where they Scrum well (= delivering value every Sprint & handling impediments in a timely manner), they have become a **Reference Model** for the organization ------ ## Goals * Maximize the flow of completed and quality tested work * Strive to increase velocity a little each sprint * Operate in a way that is sustainable and enriching ------ ## Inputs * Additional context clarifying org. vision and goals * Ordered product backlog of items to work on * Feedback on Product Increment ------ ## Outputs * Completed product increment end of each sprint * Identified impediments the team needs to remove * Process coordination with related teams * Velocity data to forecase delivery * Other team metrics to support transparency ------ ## Great Every team has a PO & SM with a clear, ordered backlog. They do all Scrum events and deploy on their own. ------ ## Good Some fo the accountabilities, events, artifacts are missing. But they still produce working product every sprint. ------ ## Bad Symptoms > "We have no dedicated PO or SM roles" > "Our teams do some events, no one goes to backlog refinement." > "There is no tranparency of our work." ------ ## Blocked > "Aren't daily Scrum meetings all tehre is to Scrum?" --- <!-- .slide: id="scrum-framework" --> ## The Scrum Framework As a member of a Scrum Team, I need to understand the Scrum framework, in order to help my team implement it properly. ------ ## 3x Accountabilities 1. Product Owners 1. Scrum Masters 1. Engineers ------ ### 1. Product Owner * Voice of the Customer * Sets Vision and Product Goal * Sets Priority ------ ### 2. Scrum Master * Leader who Serves * Continuous Improvement ------ ### 3. Engineer * Knowledge * Capability * Quality * Self-managing ------ ## 6x Events 1. Sprint 1. Backlog Refinement 1. Sprint Planning 1. Sprint Review 1. Daily Scrum 1. Retrospective ------ ### 1. Sprint * Fixed duration * Common cadence * Container for events ------ ### 2. Backlog Refinement * Definition of Ready * Ordered in value / priority * Kept "healthy" ------ ### 3. Sprint Planning * Sprint backlog ------ ### 4. Sprint Review * Deliver product increment * Velocity * Feedback ------ ### 5. Daily Scrum * Re-plan and adjust * Unblock "blockers" ASAP ------ ### 6. Retrospective * Kaizen ------ ## 3x Artifacts 1. Product Backlog 1. Sprint Backlog 1. Product Increment ------ ### 1. Product Backlog * Product Goal * Vision * Properties ------ ### 2. Sprint Backlog * Sprint Goal * Known work * Capacity ------ ### 3. Product Increment * Definition of Done * Sum of completed work * Value --- ## Hyper-Productive ## Team Patterns ------ ### Backlog Refinement > Breaking things down into manageable-szied READY pieces helps to avoid failure. ------ ### Small Teams > Adding more people to a team makes it slower. ------ ### Stable Teams > Any change in team members causes delays. ------ ### Organizational Sprint Pulse > At scale, a synchronized cadence helps reduce system stress and inconsistency. ------ ### Yesterday's Weeather > Taking just enough into a Sprint improves team performance Over-utilization slows things down ------ ### Swarming > Reducing context switching moves things along faster. ------ ### Interrupt Buffer > Use a buffer to reserve capacity for emergencies. ------ ### Good Housekeeping > Defect free product eliminates work. ------ ### Scrumming the Scrum > Add one process improvement to the Sprint Backlog every sprint. ------ ### Happiness Metric > Unhappy people become actively disengaged. --- ## Scrum of Scrums As a member of "teams of teams" (SoS), I want to understand how scaling works so we can deliver an integrated product increment together. ------ Scrum-of-Scrum helps where a team **do not** have an independent path to production. Ideally, teams would have an independent path to production (i.e. loosely coupled architecture). But there are often dependencies that need to align. **Scrum-of-Scrum helps** ------ **The Scrum-of-Scrum (SoS) is:** * **Not** an event (more a group working to align) * A set of teams that need to deliver together * Is a Team-of-Teams * Responsible for an increment of product at end of sprint * Must deliver the Chief Product Owner's sprint goal ------ > What do we need to do to help them coordinate **HOW** they are going to drive things to **DONE** as a group? ------ ## Scaled Daily Scrum (SDS) * Event facilitated by a Scrum-of-Scrums Master (**SoSM**) * Enables cross-team coordination * Adjust as a group in order to achieve SoS Sprint Goals * Surface and remove impediments if possible * Share learnings for continuous improvement ------ ## What is discuss at the SDS? What impediments does my team have that will prevent them from accomplishing their sprint goal (or impact the upcoming delivery)? ------ ## What is discuss at the SDS? Is my team doing anything that will prevent **another team** from accomplishing likewise. ------ ## What is discuss at the SDS? Have we discovered any new dependencies or a way to mitigate them? ------ ## Scrum-of-Scrum Master (SoSM) Scaling the accountabilities of the Scrum Master. Must ensure that impediments are shared and removed, knowledge is spread and standardized, and dependencies are discussed and resolved. ------ ## Scrum-of-Scrum Master (SoSM) It should be someone who has enough power to remove impediments and understands the policies and politics of getting things **done** and **released**. ------ ## Scrum-of-Scrum Master (SoSM) Could be one of the team's Scrum Masters or someone dedicated to the role. ------ ## Scrum-of-Scrum Master (SoSM) SoSM's strive to improve thoughtput & quality while lowering costs. --- ## Bereaucracy & Hierarchy A Scaling challenge * Heavy bureaucratic processes delays decision making * "Everything we do requires sign-offs, nothing gets done" ------ ## Minimum Viable Bureaucracy **Executive Action Team** Senior team in charge of agile ways of working. **Executive MetaScrum** Alignment meeting led by a Chief Product Owner (CPO) with management and stakeholders. **Organise teams into a SoS** ...around a value stream funcitioning as a release team ------ ## Executive Action Team Perspective * **EAT** - Eats impediments * Removing those the teams/SoS cannot * EAT Daily Scrum is an org-wide SDS * Allows for cross-value stream coordination * Measures and improves the quality of Scrum * Owns organisation transformation strategy --- <!-- .slide: id="executive" data-background-color="var(--r-background-alt-color)" --> ## Executive Action Team As an Agile Leader, I need to implement an Executive Action Team, so that my organization can scale sustainably. ------ **This is the starting point** Find the people with the direct authority. ------ Align the organization along a shared and transparent **transformation strategy** and ensure that a prioritized transformation backlog exists to execute that vision. ------ **Continuously observe metrics** tracking product delivery thoughput while removing the inhibiting impediments. ------ Enable execuation of the high-level transformation processes with a primary **focus on removing waste**. ------ Support the **PO and SM cycles** of the Scrum@Scale framework though mentoring, coaching, and challenging the organization to iteratively evolve. ------ ## EAT Accountabilities **Removes impediments** which cannot be handled by the Teams due to scope, budget, or corporate political power Accountable for the **quality of Scrum** in the organization ------ ## EAT Accountabilities Measures and improves the **quality of Scrum** in the organization to build capability for business agility. Owns the **Organizational Transformation Strategy** ------ ## EAT Accountabilities Owns the **Transformation Backlog** and “eats impediments” which block it Executes the **Transformation Strategy** or delegates it to an empowered body ------ ## EAT Accountabilities Often called the Agile Practice or Agile CO ------ ## Inputs * Business strategy & market trends * Transformation status & process information * Other organizational development initiatives * Organizational metrics to provide transparency * Identified impediments * Feedback on interventions ------ ## Outputs * Organizational transformation strategy * Up-to-date EAT backlog * Status of organizational development * Vision & goals re: org. culutre, structure, values, etc ------ ## Great We have dedicated Executives transforming the organization and eliminated impediments each Sprint. ------ ## Good We have a dedicated team for getting rid of impediments, but no backlog to change the organization. ------ ## Bad Symptons > "No one prioritizes impediments" > "There is no buy-in from Executives to make this company agile" > There is no overall strategy for us to become agile" ------ ## Blocked We do not have any empowered groups dedicated to getting rid of impediments. --- <!-- .slide: id="continuous-improvement" data-background-color="var(--r-background-alt-color)" --> ## Continuous Improvement ## & Impediment Removal ------ Identify **impediments** that slow teams down and reframe them as **opportunities** to get faster. ------ Maintain an open and structured environment for prioritizing and removing impediments, and then verifying the resulting improvement. ------ Ensure visibility to the right people in the organization to effect change. ------ ## Kaizen Katalog - Entry Template * Why try this? (Problem it solves) * Procedure for implementation * Duration of experiment * We hope to observe? * We will watch out for? * Metrics it affects? * Results ------ ## Inputs * Updates on impediments removal * Velocity data for all teams * Team happiness data * Impediments raised by individual Scrum teams ------ ## Outputs * Impediment status made visible * Visible results of process experiments and learnings ------ ## Great Our teams utilize the Daily Scrum to surface impediments and Retrospectives to improve & velocity is increasing. ------ ## Good Our teams have Daily Scrums and Retrospectives, but little increase in velocity has been observed. ------ ## Bad Symptpoms > “Our teams inconsistently look for improvement.” > “Impediments linger for months.” > “Retrospectives rarely yield ideas that improve how much work gets done.” ------ ## Blocked Our teams have almost no ability to get rid of impediments and Retrospectives are unproductive --- <!-- .slide: id="experiments" --> ## Experiments Incremental transformation towards Scrum@Scale ------ ## Pick High Value Node Based on the ratings across the Scrum@Scale node. | Impact | Importance | | ------ | ------------ | | 🟥 | 5️⃣ | | ⬇️ | 4️⃣ | ------ ## Pick a Node Input Which input do you feel (hunch) is a root cause? Addressing this input could make the most difference. ------ ## Form a Hypothesis Articulate your hunch as a hypothesis. * If we try **X** * Then **Y** will result ------ ## Run the Experiment Put these identified experiments into your backlog. Pull in an experiment into a sprint. ------ ## Aha's Capture any **Aha's** that come from them (key learnings). --- <!-- .slide: id="cross-team" data-background-color="var(--r-background-alt-color)" --> ## Cross Team Coordination As an enterprise, we need just enough cross-team coordination, so that teams consistently deploy working products. ------ Coordinate similar processes across multiple related teams. ------ Identify cross-team dependencies and make them visible to the PO loop to ensure they don't become impediments. ------ Maintain alignment of team norms and guidelines for consistent output. ------ ## Scaled Coordination * **Sprinting together** from the enterprise perspective * Maintaining a common **Definition of Done** * Regular **Scaled Daily Scrum** * Resolve emergent dependencies and issues * Common team Scrum events at Scale * Example: Increment planning, retros * **Communities of Practice** & formal Quality Circles ------ ## Inputs * Align Scrum and non-Agile teams * Team level norms and practices * Results of process experiments * Requests for change to norms / standards * Identify cross-team dependencies ------ ## Outputs * Visible team norms and guidelines * Synced backlogs with dependencies * Enabling specifications for common dev ------ ## Great All of out teams that need to coordinate have cooperative PO's adn SM's adn events for handling dependencies. ------ ## Good Our teams coordinate for the most part, but some issues remain to be handled by the executives. ------ ## Bad Symptoms > "Our teams have tons of dependencies." > "Some teams are overloaded while others seem to have spare capacity." > "People are constantly reinventing the wheel here." ------ ## Blocked Our teams have constant down-time due to dependencies and no formal way to mitigate them. --- <!-- .slide: id="delivery" data-background-color="var(--r-background-alt-color)" --> ## Delivery As an organization, we need to scale our deployment system, so that our product delivery meets our customer's needs. ------ Deliver a consistent flow valuable finished producct to customers. ------ Integrate the work of different teams into one seamless product. ------ Ensure high quality of the customer experience. ------ Capture and communicate feedback on product, process, and schedule. ------ ## Inputs * Steady flow of potentially shippable increments * Feedback from customers and users of the product * Adoption metrics ------ ## Outputs * Working product in hands of customers * Updated release plan based on actual delivery * Product feedback in context * Updating product backlog as per feedback * Process feedback on integration or quality issues ------ ## Great We have a great system of getting our product to our customers. ------ ## Good Out products get out, but there are errors in what we deliver that never seem to get fixed. ------ ## Bad Symptoms > "We have a totally manual process for distribution of product." > "Getting our products out takes a long time." > "We have no idea if people like how they get our products." ------ ## Blocked Our customer base has a difficult time getting our products into their hands. --- <!-- .slide: id="feedback" data-background-color="var(--r-background-alt-color)" --> ## Product Release & Feedback As an enterprise, we need to harness feedback, so that we can effectively improve our products and processes. ------ Understand how customers actually use and interact with the product. ------ Define improvements to existing functionality. ------ Distill actionable changes in direction from noise of all responses. ------ Update progress towards product or project completion to refine release planning and stakeholder alignment. ------ ## Lean Startup * Minimum Viable Product * The Pivot ------ ## Iterative Risk Management * Product Risk - Are we solving a substantial problem? * Product Risk - What are our technical challenges? * Customer Risk - Who are our ideal customers? * Customer Risk - Do we understand their needs? * Market Risk - Do we have a viable market niche? * Market Risk - Are we better than the competition? ------ ## Inputs * Customer and stakeholder reactions from sprint review * Identified integration and product release issues * Observation or direct feedback from actual product users ------ ## Outputs * Updates to release plan and stakeholder visibility * Results of market and customer experiments * Identified bugs / experience issues to be corrected * Additional desired functionality with value estimates ------ ## Great We regularly monitor data on both our product and delivery system and adjust constantly to market demands. ------ ## Good We have a lot of good data being captured, but we have a hard time distinguishing noise from what's important. ------ ## Bad Symptoms > "We have inconsistant streams of data coming in." > "The data we get is not used for generating backlog items." > "we have no idea why it doesn't sell." ------ ## Blocked Other than sales, we don't have a good grasp on how competitive our products are or how to improve them. --- <!-- .slide: id="product-owner-cycle" --> ## The Product Owner Cycle As an Executive, I need to understand how the PO Cycle works, so that I can help my organisation prioritize the right work. ------ ## Scaling the Product Owner As an Agile Leader, I need to understand how the PO role scales, so that I can grasp how to satisfy the business’ needs at scale. ------ ## Product Owner Team Coordinating "what" to deliver ------ The PO often has more to do than a single person can handle well. Therefore create **Product Owner Team** * Led by **Chief Product Owner** * Who **together** do product ownership * Realizes the **Product Vision** * Ordering the **Product Backlog** items * Through a **single** Product Backlog ------ ## Decision Latency The time to make a decision. Decision latency is directly related to Process Efficiency. ------ Slowness in making decisions is the primary driver of project failure and budget overrun. ------ Scrum pushes decisions out to the teams; empowered cross-functional teams have a greater ability to make decisions faster. ------ An empowered, decisive, available Product Owner is critical to reduce decision latency. ------ How do we decide what makes it into the Shared Backlog? ------ Create a **Meta-Scrum** as a forum where the entire enterprise can align behind the Product Owners’ backlogs at every level of Scrum in the organization. --- <!-- .slide: id="metascrum" data-background-color="var(--r-background-alt-color)" --> ## Executive Meta-Scrum As an Agile Leader, I need to open an Executive MetaScrum, so that my organisationcan align more easily. ------ Create an **overarching vision** for products & make it visible to the organization. ------ Generate a single **prioritized backlog of products**. ------ Create a uniform **Definition of Done** that applies to all products. ------ Consider **dependencies** from a backlog perspective raised by the SoS to prevent team impediments. ------ Decide upon and monitor **metrics** that give **insights** into the products. ------ ## Inputs * Stakeholder and team input * Product feedback, customer satisfaction * Market and marketing trends * Current enterprise backlog * Velocity data for all teams * Current cross-team dependencies * Current resource conflicts ------ ## Outputs * Strategic vision * Business strategy * Up-to-date enterprise backlog * Clear goals * Principles for prioritization * Principles for trade-off decisions ------ ## Great We have executives who are dedicated to creating a company vision and a backlog of products to achieve it. ------ ## Good There is a strategic vision, but we are not sure how our products make that vision a reality. ------ ## Bad Symptoms > “Our teams have their own vision but it doesn’t align with the organization.” > “Some teams work towards achieving our company’s mission, some do busy work.” > “People have competing visions.” ------ ## Blocked There is no central guiding vision, and we don’t see how our products as a whole support this organization. --- <!-- .slide: id="strategic-vision" data-background-color="var(--r-background-alt-color)" --> ## Strategic Vision As an organization, we need a strategic vision, so that our teams can work together towards a common goal. ------ Clearly align the entire organization along a shared path forward. ------ Compellingly articulate why the organization exists. ------ Describe what the organization will do to leverage key assets in support of its mission. ------ Update continuously based on feedback to outmaneuver the competition. ------ Strategic Vision & Goals ⬇️ Product Vision & Goals ⬇️ Sprint Goals ------ Value (Impact) ⬆️ Released Product (Outcome) ⬆️ Working Product (Output) ------ ## Inputs * Consumer, market, competitive insights * Feedback on released product * Feedback on released progress * Other team metrics to support transparency ------ ## Outputs * Clarified context * Of org. culture, vision, goals, norms * Clear goals & principles for ordering backlogs * Hypothesis on market needs / growth engine ------ ## Great We have a high-level vision set for the company and each team has a vision that is traceable back to it. ------ ## Good We have good product visions, but no real cohesive portfolio vision that ties them all together. ------ ## Bad Symptoms > “We’re focused on tangible sales, not vision statements.” > “I don’t understand how our company’s vision translates into our products.” > “Our team’s have no unifying vision.” ------ ## Blocked We do not have anyone setting a vision for the company, or one that is disconnected from our products. --- <!-- .slide: id="prioritization" data-background-color="var(--r-background-alt-color)" --> ## Backlog Prioritization As an organization, we need to scale our priorities across an enterprise backlog, so that our teams are aligned on what is important. ------ Identify a clear ordering for products, features, and services to be delivered ------ Reflect value creation, risk mitigation and internal dependencies in ordering of the backlog ------ ## Sources of Business Value * Market Value * Risk Reduction * Capability Building ------ ## Methods for Determining Value In order of fastest to more detailed 1. MoSCoW 1. Planning Poker 1. Kano Analysis 1. Impact + WSJF 1. Cost of Delay 1. ROI 1. Break-even Analysis 1. Net Present Value ------ ## Inputs * Clear goals and principles for prioritization * Guidance on how manage trade-off decisions * Current product backlog * Feedback on released product * Team and stakeholder input on dependencies * Agreed preferred flow (incl. dependencies) ------ ## Outputs * Guidelines for managing technical debt * Guidelines for reducing risks * Architectural guidelines and standards * Products, features, enablers prioritized in backlog ------ ## Great We meet regularly to go over our backlog at a high level and reprioritize as the marketplace demands. ------ ## Good We meet quarterly to discuss prioritization but have trouble changing direction even if we need to. ------ ## Bad Symptoms > “We have multiple groups with competing priorities.” > “Everything is a number one priority.” > “We have no way of measuring if prioritization helps us.” ------ ## Blocked We do not have anyone setting the overall priorities for the company nor a consistent metric by which to do so. --- <!-- .slide: id="refinement" data-background-color="var(--r-background-alt-color)" --> ## Backlog Refinement As an organization, we must decompose and refine the backlog, so that many teams can work together. ------ Break complex products into manageable independent functional elements. ------ Capture and distill emerging requirements and customer feedback. ------ Ensure all backlog items are truly “Ready” when they reach sprint backlog. ------ Supply backlog all the way to individual team product owners. ------ ## Inputs * Guidelines for managing technical debt * Guidelines for reducing risks * Architectural guidelines and standards * Products, features, enablers prioritized in backlog * Input on required level of enabling specification * Emerging requirements, insights, feedback ------ ## Outputs * Consolidated individual team level backlogs ------ ## Great We meet regularly to map out and refine the backlog into pieces of customer-visible value. ------ ## Good We meet to refine the backlog but have difficulty writing effective backlog items. ------ ## Bad Symptoms > “We meet on an ad-hoc basis for refinement without goals.” > “Our backlog items don’t have well-defined acceptance criteria.” > “We have a hard time refining items.” ------ ## Blocked Our entire backlog is a bunch of tasks. --- <!-- .slide: id="release-planning" data-background-color="var(--r-background-alt-color)" --> ## Release Planning As an organization, we need an effective method of release planning, so that our customers can anticipate delivery. ------ Forecast delivery of key features and capabilities. ------ Communicate snapshot of delivery expectations to stakeholders. ------ Inform updated prioritization, as needed, based on stakeholder feedback and needs. ------ | Conceptual View | Product View | | ------------------ | ------------------ | | Vision / Roadmap | Product Release | | ⬇️ | ⬇️ | | Sprint Goals | Shippable Increment | | ⬇️ | ⬇️ | | Feature Availability | User Story (Backlog) | ------ ## Agile Release Plan **Clear Vision & Product Goals** Tied to concrete business value Aligns stakeholders ------ ## Agile Release Plan **Vision Decomposed Into Features / Capabilities** Prioritized and estimated ROI and customer need driven ------ ## Agile Release Plan **Burndown chart of progress on prioritized backlog items** Measured in Points! ------ ## Agile Release Plan **Feature availability timeline** Best guess – subject to change ------ ## Availability Timelines Help Stakeholders Know when to Expect New Features ------ * Facilitates conversations on priority * Aligns stakeholders and heads off distractions * Timeline is only a forecast, and subject to change ------ ## Inputs * Prioritized product backlog * Team velocity for all teams * Data on emerging requirements * Plus defect rates and other activities * Input on implications of current delivery trajectory ------ ## Outputs * Requests to re-prioritize backlog items * Roadmap of upcoming functionality * Burndown chart(s) of progress towards release ------ ## Great We have a clearly defined release plan around delivering value that our customers want at a pace we can keep. ------ ## Good We have a plan to deliver products, but our releases sometimes don’t include top priority value items. ------ ## Bad Symptoms > “We miss our release dates constantly.” > “Our customers complain about not getting what they want when promised.” > “We have a hard time cutting scope in order to hit our release dates.” ------ ## Blocked We almost never deliver on time and require multiple fixes for anything we do get to market. --- <!-- .slide: id="metrics" data-background-color="var(--r-background-alt-color)" --> ## Metrics & Transparency As an organization, we need transparency of the work and to track the proper metrics, so that I can assess the effectiveness of our work. ------ Provide all decision makers, including team members, with appropriate context to make good decisions. ------ Shorten feedback cycles as much as possible to avoid overcorrection. ------ Accomplish all of this with minimal additional effort by teams, stakeholders or leadership. ------ ## Lens: Value Are we prioritizing the right features to deliver first? * Business value points * Outcomes achieved * Revenue impact ------ ## Lens: Productivity Are we improving our ability to deliver product over time? * PBI cycle time * Delivery lead time * Customer lead time ------ ## Lens: Sustainability Are we working in a way we can continue for the long run? * Kaizen stories * Kaizen initiatives * Customer insights ------ ## Lens: Satisfaction Are we paying attention to our impact on people? * Colleague happiness * Process effectiveness * Customer satisfaction ------ ## Inputs * Customer satisfaction and product quality data * Internal quality or reliability data * Current release plan info for all initiatives * Financial data for all initiatives * Velocity data for all teams ------ ## Outputs * Insights for updating strategic vision * Context for making front-line decisions * Insights on systemic impediment root causes * Data supporting priority for changes ------ ## Great All of our teams have transparent backlogs and we have agreed upon metrics that every team tracks. ------ ## Good We have adequate transparency, and every team captures metrics, but not always the same ones. ------ ## Bad Symptoms > “I don’t know what the teams are working on or why they collect specific metrics.” > “I don’t know how to find the team backlogs or where their metrics are published.” > “We can’t agree on what to measure.” ------ ## Blocked We have no idea what is in the teams’ backlogs and no standard way of measuring their progress. --- (Insert finishing image)