improving your agile process
DESCRIPTION
Slides from my lightning talk at DevDays DC on how to improve your agile process by gathering small amounts of data and using it to make decisions.TRANSCRIPT
Improving your Agile Process
First...who are we?
We reduce home energy use
We reduce home energy useby showing people how much they use
We reduce home energy useby showing people how much they useand then they actually use less!
Agile means:
Agile means:short iterations
Agile means:short iterations
a metric sh*t-ton of practices chosen from a salad bar
TDD, Pair Programming, Scrum, Kanban Cards, BDD, Continuous Integration, MDD,
Sprints, Stand-ups, Continuous Deployment, The Planning Game, User
Stories, Planning Poker, Sustainable Pace, Collective Code Ownership...
Adopting agile?
Adopting agile?Which practices?
Already agile-ish?
Already agile-ish?Which practices will help us and
why?
Pick what feels good?
Pick what feels good? Study your process and target
problem areas.
Scientific Method!
1. Gather Data 2. Form Hypothesis 3. Perform Experiment 4. Analyze Results
1. Gather Data
Quantify:good things (to increase)
Quantify:good things (to increase)bad things (to decrease)
The Big Bad: Bugs
The Big Bad: Bugs(you are using a bug tracker, right?)
“We wrote less bugs than the previous iteration. We
rule!” (Right?)
V2.2 V2.3
# of Bugs 25 23
V2.2 V2.3
# of Bugs 25 23
Team Size 8 5
Flu took out half the team!
Wait...What?
Raw measurements must be put in context
What is the “size” of an iteration?
LOC?
LOC?Doesn’t fit with agile
Hard to measure
Hours/Days?
Hours/Days?Fixed iterations
Hard to measure
We use “Story Points”
We use “Story Points”1, 2, 4, 8 per user story
“Story Points” could be anything that:
“Story Points” could be anything that:
changes w/ amount of work
“Story Points” could be anything that:
changes w/ amount of workdetermined consistently
“Story Points” could be anything that:
changes w/ amount of workdetermined consistently
easy to capture
Bugs ÷ Size ==Defect Density
V2.2 V2.3
Bugs 25 23
Story Points 14 10
Density 1.79 2.3
Simple
SimplePaints Broad Strokes:
Increase == Bad
SimplePaints Broad Strokes:
Increase == BadAlmost enough to draw
conclusions
With a small amount of additional meta-data...
With a small amount of additional meta-data...
...you can gain incredible insights
•Severity•Priority•Where Introduced: ‣bad requirements
‣bad programming
‣configuration/deployment
1.0
1.3
1.6
1.9
2.2
V2.3 V2.4 V2.5
Defect Density: unclear requirementsDefect Density: Programming Errors
1.000
1.375
1.750
2.125
2.500
V2.3 V2.4 V2.5
Defect Density - all types
1.000
1.375
1.750
2.125
2.500
V2.3 V2.4 V2.5
Defect Density - all typesDefect Density - Blockers
2. Form Hypothesis
Metrics give us insightto focus on problem areas
Form a hypothesis about problem areas and potential
solutions
Agile practices are a goldmine
Agile practices are a goldmine...if used sensibly in the context
of your process
Example:“Increasing test coverage will
reduce our defect density”
Example:“Pair Programming will reduce
‘bad programmer’ bugs”
Example:“BDD will help clarify
requirements so we implement the right thing”
3. Perform Experiment
On the next iteration, test your hypothesis
Start slowly;implement one change, chosen
for maximum impact
4. Analyze Results
The next iteration’s metrics should prove/disprove your
hypothesis
Repeat until profit!
This improvement method isn’t perfect
This improvement method isn’t perfect
but it’s a GREAT start
How has this helped OPOWER?
Iteration 1Half of the user stories not
being tracked :(
Iteration 2Parts of the team using different
scale for story points :(
Iteration 3Data looked good, baseline
established.
Iteration 4Lots of deploy/config errorsOther numbers same/better
Iteration 5Automated deployment »
deploy errors down.But: Defect Density was up
Iteration 6Lowered velocity
Set up test coverage tracking(final results not in yet!)
Scientific Method
MeasureHypothesizeExperiment
Analyze