Agile

DBT Team - Agile Fractal

1. A cross-functional, self-organizing team that can Define, Build, and Test 2. Optimized for communication 3. Teams can be based on: - Features - Products - Components - Subsystems - Interfaces

Developer/Tester (Role)

1. Creates and refines user stories and acceptance criteria 2. Define/Build/Test/Deliver stories 3. Develops Prgm Increment (PI) Objectives & Sprint Plans 4. Commits to Sprint Goals and PI Objectives 5. Other specialty roles

Product Owner

1. Defines and accepts stories 2. Assures team is pursuing a common vision 3. Drives business value with a backlog and priorities 4. Acts as the customer for developer questions 5. Works with product management to plan releases 6. Owns Team backlog(s) 7. Defines sprints and stories 8. Accepts sprint increments 9. Re-factors, redesigns, refines backlog

Release Planning - Team Breakout #1

1. Each team breaks down their features into user stories which are estimated and placed into Sprints 2. There is a lot of back and forth between the teams - mostly understanding and minimizing dependencies

Sample Agenda for Day 2 of Release Planning

1. Planning Adjustments: adjustments based on prior day's management meeting 2. Team Breakouts: - Teams develop final plans & refine risks & impediments - Business Owners circulate & assign business value to team objectives 3. Final Plan Review: Teams present final plans, risks, and Impediments 4. Program Risks: Remaining program-level risks are discussed and ROAMed 5. PI Confidence Vote: Team and program confidence vote 6. Plan Re-work if Necessary: If necessary, planning continues until commitment is achieved 7. Planning Retrospective & Moving Forward: - Retrospective - Moving Forward - Final Instructions

Rules of the Release Train

1. Program Increment (PI) dates are fixed 2. Estimating, planning, and asset integration coordinated with 2 week sprints, aligned cadence, and normalized estimating 3. Every 2 weeks - system integration and system demo milestones are enforced 4. All cargo (code, docs, etc) goes on the train. 5. The system always runs

Program Level Calendar includes:

1. Release Planning Meetings 2. PI Demos 3. Inspect and adapt Workshops

Common Vision Statement Formats

1. Rolling Wave Briefings 2. Vision Document 3. Preliminary Data Sheet 4. Draft Press Release

Scrum Master (Role)

1. Runs team meetings, enforces agile behavior 2. Removes impediments 3. Protects the team from outside influence 4. Attends integration (scrum of scrum) meetings

Sprint Team Level Calendar includes:

1. Sprint Planning Meetings 2. Sprint Demos 3. Sprint Retrospectives

Release Planning - Example of Acceptance Criteria

1. Sprints are Planned: (typically 4 are planned) - Velocity established - All stories estimated, no story bigger than 8 story points - Sprints loaded; load less-than or equal-to velocity 2. PI Objectives sheet: - Legible, concise, and understandable - Business value assigned by Business Owners 3. Program Risks Identified

During Release Planning Kickoff, Architecture, UX, and Development share information about:

1. System Architect presents the vision for architecture, new Architecture Epics, and common frameworks 2. Development may provide updates on Agile tooling and improvements in engineering practices 3. UX professionals provide user experience guidance

To prioritize based on lean economics, we need to know two things:

1. What is the Cost of Delay (CoD) in delivering value 2. What is the cost to implement the valuable thing

Agile Release Train

A long-lived, self-organizing team-of-agile-teams that delivers solutions 1. A virtual organization of 5-12 teams (50-125 individuals) that plans, commits, and executes together 2. Common cadence and normalized estimating 3. Aligned to a common mission via a single program backlog 4. Operates under architectural and UX guidance 5. Frequently produces valuable and evaluate-able system-level solutions

Spike

A story or task aimed at answering a question or gathering information, rather than at producing product. Sometimes a user story is generated that cannot be estimated until the development team does some actual work to resolve a technical or functional question or a design problem. The solution is to create a "spike," which is a User Story whose purpose is to provide the answer or solution. Like any other story or task, the spike is then given an estimate and included in the sprint backlog. Spikes are demonstrable. The results of the spike are used to define multiple smaller User Stories.

Acceptance Test

Acceptance tests are documented, persistent tests that repeatedly assure the system always works as intended 1. Specific, unambiguous 2. Can be automated or manual (but need automation) 3. Can be written in a programming language (PERL, Groovy, Java) or in natural language (using RobotFramework or Cucumber) or in table format (FIT)

Addressing Program Risks

After all plans had been presented, remaining program risks and impediments are discussed and categorized using ROAM.

Confidence Votes: Team and Program

After dependencies are resolved and risks are addressed, a confidence vote is taken at the team and program levels using the "Fist of Five" approach. A teams Commitment has Two Parts 1. Teams agree to do everything in their power to meet the agreed-to objectives 2. In the event that it becomes apparent that their objectives may not be achievable, teams agree to escalate immediately so that corrective action can be taken

Inspect & Adapt occurs

At the end of each Program Increment (PI)

Demo occurs

At the end of every Sprint

System Demo

At the end of every sprint, the System Team/Product Management demonstrates the solution increment to the stakeholders 1. A demonstration of the integrated software assets to business owners and other program stakeholders 2. Happens after the team sprint demos (may lag by as much as one sprint, maximum!)

Release Planning occurs

At the start of the next Program Increment (PI)

Release Planning - Team Breakout #2

Based on new knowledge (and a good night's sleep), teams work to create their final plans. 1. In the second team breakout, business owners circulate and assign business value to release objectives (1-10) 2. Teams finalize the Program Increment plan 3. Consolidate risks, impediments, and dependencies 4. Stretch objectives provide the capacity and guard band needed to increase cadence-based delivery reliability

Sample Agenda for Day 1 of Release Planning

Business Context: State of the business and objectives Product/Solution Vision: Vision and prioritized features Architecture Vision & Development Practices: - Architecture, common frameworks, etc. - Agile tooling, engineering practices, etc. Planning Process: Facilitator explains planning process Team Breakouts: - develop draft plans and identify risks & impediments - Architects and Product Managers circulate Draft Plan Review: Teams present draft plans, risks, & impediments Management Review and Problem Solving: Adjustments are made based on challenges, risks, and impediments

Release Planning

Cadence-based PI/Release Planning meetings are the pacemaker of the agile enterprise 1. Two days every 8-12 weeks 2. Everyone attends in person if possible 3. Product Mgt owns feature priorities 4. Dev team owns story-planning & high-level estimates 5. Architects and UX folks work as intermediaries for governance, interfaces, and dependencies Result: program objectives for the next PI

SWOT

Chart listing: Strengths, Weaknesses, Opportunities and Threats

Formula for CoD

CoD=(UserBusinessValue + TimeCriticality + RR-OE)

Planning Requirements - Example

Color coding gives visibility into investments

Estimating Poker

Combines expert opinion, analogy, and dis-aggregation for quick but reliable estimates 1. Participants include all team members 2. The product owner participates, but does not estimate 3. Each estimator gets a deck of cards 4. Product owner reads a story 5. Estimators privately select cards 6. Cards are turned over 7. Discuss differences 8. Re-estimate

Management Review & Problem Solving

Common Questions: 1. What did we just learn? 2. Where do we need to adjust Vision? Scope? Resources? 3. Where are the bottlenecks? 4. What sacred features must be sacrificed? 5. What decisions must we make between now and tomorrow to address these issues? Based on the previous day's Management Review and Problem Solving meeting, adjustments are discussed. Possible Changes: 1. Business priorities 2. Adjustment to plan 3. Changes to scope 4. Movement of resources

Continuous System Integration

Continuously integrate assets across Sprint Teams into the codebase, leaving as little as possible to the System Team 1. Integrate every DBT-cycle (vertical slices) of a user story 2. Avoid physical branching - Hide functionality by using branching by abstraction and feature toggles - No assumption-driven development 3. Use development by intention in case of inter-team dependencies - Define interfaces and integrate first; then add functionality

Acceptance Criteria

Defines how the team will know that the intent of a story has been achieved 1. Cover relevant aspects, including: - System behavior - Non-functional requirements 2. Mainly defined at Sprint planning, but are also defined during Backlog Refinement or the Define-Build-Test cycle 3. Serve as a starting point for story acceptance tests

DBT-Cycle

Design-Build-Test Cycle

Test First: Automate Now!

Else, velocity is bottlenecked, quality is speculative, scaling is impossible 1. Automated tests are implemented in the same iteration as the code 2. The team that codes also automates the tests 3. Create an isolated automated test environment 4. Actively maintain test data under version control 5. Passing vs. not-yet-passing and broken automated tests are the real iteration progress indicator

Release Planning Facilitator

Ensures the team has a shared understanding of the planning process and deliverables for the planning process Walkthrough of: 1. Team planning process 2. Planning acceptance criteria 3. Program Board Each team has the same deliverables: 1. An objectives sheet 2. One sheet per sprint for stories 3. One risk sheet for risks and impediments

Features, Benefits and Acceptance Criteria

Features deliver business benefits. Feature acceptance criteria proves that the value is there.

Release Planning - Building the Final Plan

Final plans are collected at the front of the room 1. Final plans are reviewed by all teams 2. Business Owners are asked whether they accept the plan 3. If so, the team's plan and program risk sheet is brought to the front of the room 4. If not, the plans stay in place and the team continues planning after the review

The program planning calendar can be set

For a year in advance

Prioritizing Features for Optimal ROI

In a flow system, job sequencing is the key to economic outcomes

Innovation & Planning Sprints (Spikes)

Innovation and Planning sprints facilitate reliability, Program Increment readiness, planning, and innovation 1. Innovation: Opportunity for innovation spikes, hackathons, and infrastructure improvements 2. Planning: Provides cadence based planning resource flexibility for cadence 3. An estimating guard band for cadence-based delivery

The Release Planning Process

Input: Vision and Top Ten features Output: PI Objectives and Program Board

Inspect and Adapt

Inspect and Adapt is a routine event which consists of the program demo and retro I&A has 3 parts: 1. Part 1. The PI demo of the solution's current state to program stakeholders 2. Part 2. Quantitative measurement 3. Part 3. The problem solving workshop Attendees: Teams and stakeholders Timebox: 3-4 hours per PI

Formula for Duration?

Job size is a quick proxy for duration 1. We know how to estimate effort (job size) for our Features and Epics, either relatively or in story points 2. In systems that are running at capacity, bigger jobs take longer to do 3. We can use use job size as a proxy for duration

Release Planning Kickoff Meeting starts with

Management shares the state of the business and upcoming objectives. There is no prescribed format, but some options include reviewing: 1. The key portfolio priorities 2. The organization's strengths, weaknesses, opportunities, and threats (SWOT)

Release Planning - Program Plan

Maps the features (User Stories) to be developed to Scrum Teams, Sprints and PI (Program Increment). It also highlights feature Dependencies and Milestones.

Starting Fast with Normalized Estimation

Normalized story point estimating provides the economic basis for estimating work within and across programs 1. For each FTE (developer and tester), assign 8 points (adjust for part timers) 2. Subtract 1 point for each vacation and holiday 3. Find a story that takes 1/2 day to code & 1/2 day to test and validate. Assign 1 story point 4. Estimate other stories relative to this story 5. Never look back (don't re-calibrate)

Release Management meetings occur

Once a week

Release Planning - Draft Plan Review

Plans are peer-reviewed by all teams Draft Plan Review Agenda: 1. Velocity (Capacity) and Load 2. Summary of Sprints (Plan Flow) 3. Draft PI Objectives 4. Program risks, impediments, and Program Board dependencies

Program Epics

Program Epics carry larger initiatives into the Program Backlog 1. Arise from splitting Portfolio Epics for implementation 2. Or, arise locally, but are sufficiently substantial in scope as to require budgetary approval and a lightweight business case 3. Split into features in the program backlog

Scrum of Scrums (SoS)

Programs coordinate dependencies via scrum of scrums 1. Scrum Masters and Release Train Engineer (RTE) gain visibility into progress and impediments 2. Typically twice per week 3. Time boxed, ---but followed by a problem-solving Meet After 4. Often a similar meeting for Product Owners

ROAMing Risks:

ROAM abbreviation for categorizations of risk: 1. Resolved - addressed and no longer a concern 2. Owned - someone has taken responsibility 3. Accepted - no way to mitigate. Could impact release 4. Mitigated - team has plan to adjust as necessary

RR-OE

Risk Reduction - Opportunity Enablement A relative valuation assigned to help calculate CoD See WSJF Prioritization Matrix

Release Planning - Planning Scrum of Scrums (SoS)

See Pic

Features

Services that fulfill user needs. 1. Feature is an industry-standard term 2. Expressed as a phrase. Value is in terms of benefits 3. Identified, prioritized, estimated, & maintained in the Program Backlog

To assure on time delivery across Scrum Teams

Synchronize Iteration Schedules

Fist Of Five confidence vote for hitting objectives

Team members indicate their level of confidence in meeting objectives by raising hands with 1, 2, 3, 4 or 5 fingers raised. 1 = No confidence; will not happen 2 = Little confidence; probably will not happen 3 = Good confidence; that team will meet objectives 4 = High confidence; should happen 5 = Very high confidence; will happen

PI (Program Increment) Objectives

Team's PI Objectives often map directly to the features in the backlog, but sometimes may they may not. For example: ‣ aggregation of a set of features stated in concise terms ‣ a milestone like trade show demo ‣ an architectural feature? ‣ a major refactoring

Release Planning - Final Plan Review

Teams and Business Owners peer-review all final plans. Example Final Plan Review Agenda: 1. Changes to velocity and load 2. Final PI objectives with business value 3. Program risks, impediments, and Program Feature Board dependencies 4. Q&A

Roadmap

The Roadmap guides the delivery of Features over time. 1. Series of prioritized Features & planned release dates 2. Commitment is made only to the next release 3. Subsequent releases are best estimates

SAFe ScrumXP Team

The ScrumXP Team is the foundation of agile development 1. 7+/- 2 Members, collocated 2. Self-managing: No managers 3. Scrum Master: (Player-Coach) 4. Full-time role preferred - May be shared across 2-3 teams 6. Product Owner: 1 product owner per team - may be dedicated to 1 or 2 teams

Unit of functionality in XP

The User Story is the unit of functionality in XP. We demonstrate progress by delivering tested, integrated code that implements stories small enough that the programmers can build half a dozen in an iteration.

Vision

The Vision communicates strategic intent. 1. Where are we headed with this solution 2. Problems that it solves 3. Features and benefits provided 4. Who it benefits 5. The performance improvements it delivers

Scrum of Scrums

The hourly scrum of scrums checkpoint helps keep teams on track and facilitates early identification of risks: 1. Keeps teams on track with hourly planning milestones 2. Helps drive out risks, impediments & dependencies

Scrum of Scrums meetings occur

Twice a week

Story Points

Used for estimating Backlog items 1. A Story Point is a number that represents: • Volume - how much is there? • Complexity - how hard is it? • Knowledge - what do we know? • Uncertainty - what's not known? 2. Story points are relative; they are not connected to any specific unit of measure 3. Compare with other stories, an 8-point story should take 4 times longer than a 2-point story

User Stories

User Stories replace traditional requirements, and describe intended system behavior 1. Small increments of value can be developed in days 2. Relatively easy to estimate, effort can be rapidly determined 3. No large, unwieldy documents 4. Not detailed at project outset, but elaborated on a just-in-time basis 5. Need little or no maintenance; can be safely discarded after implementation 6. Foundation for ATDD (Acceptance Test Driven Development)

Components of Cost of Delay (CoD)

User-Business Value: Relative value to customer or bus. 1. They prefer this over that 2. Revenue impact? 3. Potential penalty or other negative impact? Time Criticality: How User Value decays over time 1. Is there a fixed deadline? 2. Will they wait for us or move to another solution? 3. What is current effect on customer satisfaction? Risk Reduction-Opportunity Enablement (RR-OE): What else does this do for our business? 1. Reduce the risk of this or future delivery? 2. Is there value in the information we will receive? 3. Enable new business opportunities?

Formula for WSJF

WSJF = COD/Job Size (aka: duration)

WSJF Prioritization Matrix

Weighted Shortest Job First (WSJF) provides the greatest economic benefit

CoD Economics: Weighted Shortest Job First

When nothing is equal, do the Weighted Shortest Job First (WSJF)! WSJF = Cost of Delay / Duration

CoD Economics: Shortest Job First

When the cost of delay is equal, do the shortest job first

CoD Economics: High Delay Cost First

When the time is equal, do the high CoD job first

Team Backlog

Work a team needs to accomplish to advance a solution. 1. It is truly ALL things. If a thing is in there, it might get done. If it isn't there, there is no chance that it will be done. 2. It represents opportunities, not commitments— a list of what we want to do 3. Items may be estimated (preferable), but estimates do not imply committed delivery 4. It has a single owner: the team's Product Owner, who is also part of a larger Product Owner/Product Manager team. 5. It is largely driven by Program Priorities

Team-Based Estimation

▸ Increases accuracy by including all perspectives ▸ Builds understanding ▸ Creates shared commitment