Improving your Agile Process

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

dave@opower.com

http://www.opower.com

@davetron5000