How many times have you been asked to deliver on metrics that did not make sense, that were counterproductive to the team’s effectiveness, or that were seemingly impossible to collect? Often times, the metrics being collected are the ones that are easy, but not necessarily the ones that matter. When it comes to software delivery, lean and agile practices and methodologies have clearly taken the lead. In the spirit of Kaizen, this session will take a look at the measures we can and should collect from agile teams, why these metrics are relevant and interesting, and how we can use them to help our teams continuously improve.
%in tembisa+277-882-255-28 abortion pills for sale in tembisa
Chicago Coders Conference 2017 - Metrics that matter
1. Measuring the right things for the right reasons!
Angela Dugan
Principal Consultant, Agile Coach
Polaris Solutions
2. Principal Consultant (SALTY!)
Been doing software since 1999 (OLD!)
Lots of certs (BORING!)
Loves board games and running
Possibly unhealthy love of Halloween?
@OakParkGirl
Angela@Polarissolutions.com
5. Lines of Code
# Bugs Found# Bugs Fixed Velocity
Utilization
Lead Time
Bug Reactivations
Cyclomatic Complexity
# Features Delivered
WIP
Planned vs. Actual Budget Overrun
Sprint Burndown
Actuals vs Estimate
Build Quality
Code Coverage
23. Anything started and not DONE
Lower WIP = Lower Lead Times
Lower Lead Times = Faster Delivery
Faster Delivery = Faster Feedback
Faster Feedback = Less Waste
@OakParkGirl
Angela@Polarissolutions.com
25. Is affected by time poorly spent
Is affected by dependency on other teams
Is effected by team’s skill/confidence at estimating
Is affected by too much WIP
Is affected by unexpected outages and unplanned work
@OakParkGirl
Angela@Polarissolutions.com
26. Velocity is a LAGGING indicator
Velocity is not necessarily a good predictor for future performance
Asking for higher velocity may come at a cost!
Velocity trends are what is valuable AIM FOR PREDICTABILITY
OVER “PRODUCTIVITY”
@OakParkGirl
Angela@Polarissolutions.com
28. Can encourage people to “sandbag” if too heavily focused on
“perfect burndown”
Don’t panic or over-react to small jumps or flat spots, instead ask
questions
Watch for smells in process that protect the burndown like
delaying bug-fixing or shrinking test cycles
@OakParkGirl
Angela@Polarissolutions.com
34. The features they are committing to deliver
The code they are committing
Their build/release process
The new features they are about to deliver to a customer
@OakParkGirl
Angela@Polarissolutions.com
41. Start measuring cause and effect of change instead of just cold,
hard metrics!
How is team WIP affecting velocity?
How is velocity affecting quality?
How is code churn affecting maintainability?
How is velocity affecting team morale?
How is team morale affecting quality?
@OakParkGirl
Angela@Polarissolutions.com
42. If you’re not monitoring
positive/negative impacts of
things you are doing, what
are you REALLY trying to
achieve?
@OakParkGirl
Angela@Polarissolutions.com
43. If you’re not monitoring
positive/negative impacts of things
you are doing, what are you REALLY
trying to achieve?
#FixedItForYou
@OakParkGirl
Angela@Polarissolutions.com
46. “Velocity is not the goal” [Video] by Doc Norton
Lean Change Management [Book] by Jason Little
The Principles of Product Development Flow [Book] by Donald G.
Reinertsen
Drive: The Suprising Truth About What Motivates Us [Book] by
Daniel Pink
@OakParkGirl
Angela@Polarissolutions.com