Kickoff & Budgeting
6 minute read
Devs don’t make mistakes. They just work in hazardous conditions.
Every day the codebase offers each developer a few hundred little traps. Fall in one and you’ll create a bug. We call these traps Hazards.
The amazing thing is that pro devs are so careful they only create 2-3 bugs per day.
Devs avoid 99% of the Hazards!
- What if you could spend an hour once and reduce Hazards per day by 1?
- What if your codebase only presented a developer 1 Hazard per day?
- How does QA change if devs only write 1 bug per quarter?
- How does Tier 2 support change if you only ship 1 bug to production per 18 months?
Safeguarding cycle
How it works
Context
We can’t know all the Hazards in our system.
Why not?
- Bugs are often the result of multiple Hazards.
- Hazards are not all equal. Some appear more often, trick devs more often, or cause bigger bugs.
- We would like to use data to identify & fix the right Hazards first.
- However, analyzing bug data is expensive and we want to start now.
Therefore
We treat new bugs as a data stream and sample it at random.
How?
- We pick, randomly, 1 bug per week to Safeguard.
- Each time we see a Hazard we make it a little better.
- We don’t invest in fixing any Hazard completely.
- We make progress on several Hazards per bug.
- We invest more on fixing Hazards that caused high-impact bugs, less on low-impact ones.
Results
Over time this fixes the Hazards with maximum ROI.
Why?
- Hazards that cause more bugs get fixed more often.
- Hazards that cause bigger bugs get bigger fixes.
- As soon as a Hazard is “fixed enough” to cause fewer bugs, our fixes automatically redirect elsewhere.
Budgeting your safeguarding efforts
Teams usually pick one of these budgeting approaches
Even weekly spend
Safeguard defects until you hit budget cap
How?
Management sets an expected budget range per week and a suggested budget per bug based on severity.
The team Safeguards one random bug then compares their actual spend to the budget range. Repeat until the weekly total hits the minimum weekly spend.
Variable weekly spend
Always fix one thing
How?
Management sets an expected budget per bug based on severity.
The team always Safeguards one bug per week, spending the appropriate budget based on the defect that was randomly chosen.
- Which budget approach do you want to do?
- What are your specific budgets?
| Category | Typical Budget | Your Budget | |
|---|---|---|---|
| Approach | Even | Variable | |
| % of sprint velocity on defect prevention | 15-35% | ||
| Low severity bug | 2 pair-hours | 0.5 pair-days | |
| Medium severity bug | 1 pair-day | 2 pair-days | |
| Critical severity bug | 2 pair-days | 1 pair-week |
Engagement timeline
Preliminaries (1 week)
Preliminary Phase — agree on purpose and budget.
- Kickoff. Announce budget.
- Add one blank story per week to each sprint. Assign them points that total X% of the sprint budget.
- Schedule sessions; start learning by doing.
Change (8 weeks)
Safeguarding comprises 2 modules.
Prevent Problems
Remove the hazards that cause mistakes. Use data to invest incrementally. Ensure each investment reduces cost today. Maximize the value of your investments over time.
Show ROI
Learn how to demonstrate the failures that never happened and show the value of your Safeguards.
We learn each in 3 steps.
Expand
Introduce new behaviors
- Concrete behavior change.
- One change at a time.
- Learn in real world, not lab.
- Proficiency focus: improve behavior consistency and quality.
Master
Make behaviors habitual
- Integrate all new behaviors.
- Apply to novel situations.
- Fluency focus: make behavior automatic and easy.
Leverage
Integrate into everything
- Reduce other processes.
- Reduce defect spend.
- Pay down defect backlog.
In total, this takes 8 weeks.
Change Phase (8 weeks) — make a lasting change
| Week | Activity | Capability |
|---|---|---|
| Week 1 | Expand | 15% Solutions |
| Week 2 | Expand | Plan Safeguards |
| Week 3 | Mastery | Prevent Problems |
| Week 4 | Master & Leverage | Prevent Problems; modify other processes |
| Week 5 | Expand | Show Progress |
| Week 6 | Expand | Show Impact |
| Week 7 | Mastery | Show ROI |
| Week 8 | Master & Leverage | Show ROI; modify other processes |
Follow-on (3 months)
Follow-on Phase (3 months) — measure results and stickiness
- Monthly: measure results.
- Measure against engagement purpose.
- Measure against mastery criteria.
- At 3 months: coach-guided impact assessment.
- Ongoing: modify other practices to take advantage of the new context Safeguarding provides.
Expected results
During the change
| Week | Observable Result |
|---|---|
| Week 1 | Stories are done; nothing else observable |
| Week 2 | Team can show connection from improvements made to the kinds of bugs it will reduce. |
| Week 3 | Safeguarding meeting takes less time. |
| Week 4 | Safeguarding integrates into standup & other processes. Some other processes may shrink or disappear. |
| Week 5 | Stakeholders can observe progress over time. They can ask useful questions during the demo. |
| Week 6 | Stakeholders can start to see business value result from Safeguarding activities. Team is using the wrong metrics, but they are using metrics! Stakeholders can start to steer measurement. |
| Week 7 | Team is incorporating feedback to improve its metrics. |
| Week 8 | Team comes to demo fully prepared to discuss business impact in terms of metrics and answer relevant questions. The metrics are starting to show improved Outcomes since week 1. Demo prep is faster. The team has started altering other processes. |
Following the change
| Desired Result | When to Expect * | Watch For |
|---|---|---|
| Significant Productivity Gain | 1 month | Engineers spend 50% less time doing Tier 2 support or fixing bugs |
| Quality Improvement | 3 months | Call center inbound goes down. Bug backlog starts shrinking rapidly as team starts addressing old bugs. |
| Ready for next initiative | 1-2 months | Team hits Hazards they can’t address incrementally within the usual timebox. |
*Times are measured from end of engagement.
Calendaring
Daily activity schedule for the 8-week change phase
The team will participate in two kinds of activities.
Practice
Do your normal work, but integrate the recipe we are practicing.
This work will be accounted for as regular stories in the sprint. This is not in addition to your job; this is part of your job.
Meeting
Full team gets together and does something.
| Week Number | Mon | Tue | Wed | Thu | Fri |
|---|---|---|---|---|---|
| 1 | Show recipe15% Solutions | Practice recipe15% Solutions | Refine & expand15% Solutions | Practice variations15% Solutions | Share insights15% Solutions |
| 2 | Show recipePlan Safeguards | Practice recipePlan SafeguardsPractice variations15% Solutions | Refine & expandPlan Safeguards | Practice variationsPlan SafeguardsPractice variations15% Solutions | Share insightsPlan Safeguards |
| 3 | ExecutePlan SafeguardsExecute15% Solutions | Execute15% Solutions | Execute15% Solutions | Execute15% Solutions | Execute15% SolutionsGuide masteryPrevent Problems |
| 4 | ExecutePlan SafeguardsExecute15% Solutions | Execute15% Solutions | Execute15% Solutions | Execute15% Solutions | Execute15% SolutionsVerify masteryPrevent Problems |
| 5 | Show recipeShow ProgressPlan Safeguards | Practice recipeShow Progress | Mini-demoShow ProgressRefine & expandShow Progress | Practice variationsShow Progress | DemoShow ProgressShare insightsShow Progress |
| 6 | Show recipeShow ImpactPlan Safeguards | Practice recipeShow Impact | Mini-demoShow ImpactRefine & expandShow Impact | Practice variationsShow Impact | DemoShow ImpactShare insightsShow Impact |
| 7 | Plan Safeguards | DemoSafeguarding ROIGuide masteryPrevent Problems | |||
| 8 | Plan Safeguards | DemoSafeguarding ROIVerify masteryPrevent Problems | |||
| Ongoing | Plan Safeguards | DemoSafeguarding ROI |