Embed Size (px)
Citation preview
How to Improve Agile Team Efficiency
Himanshu Desai (@H_Desai)Principal Consultant, Technical Specialist
1
Page / Copyright ©2015 by Readify Pty Ltd2
Agenda› Measures and Metrics & their suitability› Quality› Velocity› Burndown› Burnup› Business Value Delivered› Cumulative Flow Diagram
› Takeaway
Page / Copyright ©2014 by Readify Pty Ltd3
Bad Metrics› Continental Airlines example› Reducing Fuel Consumption as metrics
› Programming Example› When you reward programmers who write lots of code and fix lots of bugs
Page / Copyright ©2015 by Readify Pty Ltd4
Good metrics› Affirm and reinforce agile principles
› Measure outcome, not output
› Follow trends not numbers
› Belong to a small set of metrics/diagnostics
› "Should provide fuel for meaningful conversations"
› Diagnose & improve the processes that produce business value
› Provide feedback on a frequent and regular basis
› Are easy to collect
/ Copyright ©2015 by Readify Pty Ltd5Page
Quality
Page / Copyright ©2015 by Readify Pty Ltd6
Quality› Code Coverage
› Maintability
› Technical Debt Register
/ Copyright ©2015 by Readify Pty Ltd7Page
Velocity
Page / Copyright ©2014 by Readify Pty Ltd8
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 60
5
10
15
20
25
30
35
Velocity
Sprints
Sto
ry P
oin
ts
Page / Copyright ©2015 by Readify Pty Ltd9
Pop Quiz› Team 1› Velocity : 50 story points
› Team 2› Velocity: 52 story pointsPick
The
winner
Page / Copyright ©2015 by Readify Pty Ltd10
Velocity› It is not a goal
› Rate at which team can produce working software› Factors› Toolset› Team composition
Page / Copyright ©2014 by Readify Pty Ltd11
Goodhart's law
“When a measure becomes a target, it ceases to be a good measure.”
Page / Copyright ©2015 by Readify Pty Ltd12
Velocity – Myths› Higher velocity is always a good thing
› Not true because….› Tech debt is bad› Pushing too hard on new product value and velocity tends to increase
tech debt
› Key Point : Measure and limit tech debt accumulation
/ Copyright ©2015 by Readify Pty Ltd14Page
Burndown
Page / Copyright ©2015 by Readify Pty Ltd15
Burndown› Rate at which features are completed
› Completed at sprint and release level
› Point in time measurement of amount of work left to be done
Page / Copyright ©2014 by Readify Pty Ltd16
1/5/2015 1/6/2015 1/7/2015 1/8/2015 1/9/2015 1/10/2015 1/11/2015 1/12/2015 1/13/2015 1/14/20150
20
40
60
80
100
120
140
160
180
200
Burndown
Actual Remaining Ideal
tIME
Poin
ts/H
ou
rs
Page / Copyright ©2014 by Readify Pty Ltd17
1/5/2015 1/6/2015 1/7/2015 1/8/2015 1/9/2015 1/10/2015 1/11/2015 1/12/2015 1/13/2015 1/14/20150
20
40
60
80
100
120
140
160
180
200
Burndown
Actual Remaining Ideal
tIME
Poin
ts/H
ou
rs
Page / Copyright ©2014 by Readify Pty Ltd18
1/5/2015 1/6/2015 1/7/2015 1/8/2015 1/9/2015 1/10/2015 1/11/2015 1/12/2015 1/13/2015 1/14/20150
20
40
60
80
100
120
140
160
180
200
Burndown
Actual Remaining Ideal
tIME
Poin
ts/H
ou
rs
/ Copyright ©2015 by Readify Pty Ltd19Page
Burnup
Page / Copyright ©2015 by Readify Pty Ltd20
Burnup› Same as burn-down but...
› Instead of tracking how much work is left to be done, we track how much work is completed so the curve goes up, not down
› Provides the visibility of scope changes.
Page / Copyright ©2014 by Readify Pty Ltd21
1/5/
2015
1/6/
2015
1/7/
2015
1/8/
2015
1/9/
2015
1/10
/201
5
1/11
/201
5
1/12
/201
5
1/13
/201
5
1/14
/201
5
1/15
/201
5
1/16
/201
5
1/17
/201
5
1/18
/201
5
1/19
/201
5
1/20
/201
5
1/21
/201
5
1/22
/201
5
1/23
/201
5
1/24
/201
5
1/25
/201
5
1/26
/201
5
1/27
/201
5
1/28
/201
5
1/29
/201
5
0
5
10
15
20
25
Burnup
Actual Scope
Time
Sto
ry P
oin
ts
1/5/
2015
1/6/
2015
1/7/
2015
1/8/
2015
1/9/
2015
1/10
/201
5
1/11
/201
5
1/12
/201
5
1/13
/201
5
1/14
/201
5
1/15
/201
5
1/16
/201
5
1/17
/201
5
1/18
/201
5
1/19
/201
5
1/20
/201
5
1/21
/201
5
1/22
/201
5
1/23
/201
5
1/24
/201
5
1/25
/201
5
1/26
/201
5
1/27
/201
5
1/28
/201
5
1/29
/201
5
0
5
10
15
20
25
30
Burnup
Actual Scope
Time
Sto
ry P
oin
ts
Page / Copyright ©2015 by Readify Pty Ltd23
Important points› Effectively sized and testable stories.
› Allow finishing work to end quickly
› Focus on few stories at a time, rather than work on too much at once
Page / Copyright ©2015 by Readify Pty Ltd24
How to achieve this?› Get the product owner to provide INVEST stories.› Provide more visibility to WHERE work is before its DONE
› Manage the work in progress to drive focus
/ Copyright ©2015 by Readify Pty Ltd25Page
Business Value Delivered
Page / Copyright ©2014 by Readify Pty Ltd26
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 50
20
40
60
80
100
120
140
160
180
200
Cumulative Business Value Delivered
Page / Copyright ©2015 by Readify Pty Ltd27
Business Value Delivered› Assign business value to features.
› Best to assign at the epic level or group of user stories.
/ Copyright ©2015 by Readify Pty Ltd28Page
Cumulative Flow Diagram
Page / Copyright ©2015 by Readify Pty Ltd29
Cumulative Flow Diagram› The idea is to visualize where the features/stories are in the workflow across time.
› Helps you to visualize work status in more depth
› Manage the work in progress to drive focus
Page / Copyright ©2014 by Readify Pty Ltd31
1 2 3 4 5 6 7 8 9 100
2
4
6
8
10
12
14
16
18
20
Cumulative Flow Diagram
8. Done 7. Await Merge 6. Await Acc. 5. Testing4. Code Review 3. Design Review 2. In Progress 1. To Do
Time (Weeks)
Sto
ries C
om
ple
te
WIP
Page / Copyright ©2015 by Readify Pty Ltd32
Take away › What you don’t measure, you can not improve
› Use of burnup in conjunction with burndown.
› Spread the work evenly to reduce risk of leftovers.
› Velocity is not a goal
› Use CFD to identify bottleneck and take corrective action
Page / Copyright ©2015 by Readify Pty Ltd33
Take away (Continued)
› Track Business Value Delivered. All features should be quantified with business value. Aim for smaller feature
› Defects per sprint gives you an idea of how well the sprint is going
› Don’t ignore developer satisfaction
› Pay up technical debt
› Manage code coverage
Page / Copyright ©2014 by Readify Pty Ltd34
/ Copyright ©2014 by Readify Pty Ltd35Page
Make it all visible
