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