How (fr)agile we are

3,020 views
2,839 views

Published on

my presentation about Agile metrics at Better Software 2011

Published in: Technology, Business

How (fr)agile we are

  1. 1. how (fr)agilewe aremetrics in an Agile world<br />Gaetano Mazzanti<br />Gama-Tech<br />
  2. 2. metrics<br />goals & proxies<br />!<br />
  3. 3. makemoney<br />survive<br />goal #1<br />
  4. 4. delivervaluetostakeholders<br />makethemsuccessful/happy<br />
  5. 5. successmeans<br />differentthings<br />todifferent people<br />
  6. 6. proxyvariables<br />indirectmeasures<br />
  7. 7. typicalproxyvariables<br />efficiency<br />schedulevariance<br />budget<br /># ofdefects<br />
  8. 8. measurement<br />alters<br />behavior<br />
  9. 9. which metrics?<br />agile<br />metrics for a linear, deterministic world<br />traditional<br />no metrics<br />code & fix<br />rigidprocess<br />top-down<br />no processchaos<br />ordered<br />chaotic<br />complex<br />
  10. 10. product development is complex<br />“self-organizing, non-linear,<br />feedback systems are<br />inherently unpredictable<br />they are not controllable“<br />D.Meadows<br />
  11. 11. however, we can<br />watch, learn and work<br />with the system<br />
  12. 12. metrics<br />learn & change<br />
  13. 13. single loop learning<br />results<br />actions<br />lead to<br />how<br />which shape future<br />efficiency<br />doing things right <br />incremental change<br />
  14. 14. double loop learning<br />results<br />actions<br />values, assumptions<br />Chris Argyris<br />guide<br />how<br />why<br />lead to new/improved <br />effectiveness<br />doing the right things<br />efficiency<br />doing things right <br />question assumptions<br />radical change<br />incremental change<br />
  15. 15. learn, change,move on<br />results<br />actions<br />values, assumptions<br />definemetric*<br />setexpirationdate<br />resultok orexpiration<br />date passed?<br />metric<br />*shared, simple, controllable, transparent, time-bound<br />
  16. 16. question assumptions<br />Agile/Lean<br />command & control<br />efficiency<br />full capacity<br />conform to plan<br />reduce variability<br />large batches<br />large queues<br />aligned self-organization<br />focus on value<br />optimize flow<br />embrace change<br />reduce waste<br />small batches<br />reduce queues<br />
  17. 17. metrics<br />quadrants &queues<br />
  18. 18.
  19. 19. metrics quadrants*<br />Business<br />Lead Time<br />Cycle Time<br />Quality of Service (SLA)<br />Throughput<br />Business Value<br />Revenues<br />ROI<br />Customer Satisfaction<br />Bugs<br />Product<br />Process<br />WIP<br />Cadence<br />CI Failures<br />Rework<br />Impediments<br />Retrospectives<br />Reviews<br />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />*thanks to<br />MatteoVaccari<br />Paolo Perrotta<br />Fabio Armani<br />Team Maturity<br />
  20. 20. metrics quadrants*<br />Business<br />what!?<br />no velocity?<br />Lead Time<br />Cycle Time<br />Quality of Service (SLA)<br />Throughput<br />Business Value<br />Revenues<br />ROI<br />Customer Satisfaction<br />Bugs<br />Product<br />Process<br />WIP<br />Cadence<br />CI Failures<br />Rework<br />Impediments<br />Retrospectives<br />Reviews<br />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />*thanks to<br />MatteoVaccari<br />Paolo Perrotta<br />Fabio Armani<br />Team Maturity<br />
  21. 21. metrics quadrants<br />Business<br />Lead Time<br />Cycle Time<br />Quality of Service (SLA)<br />Throughput<br />Business Value<br />Revenues<br />ROI<br />Customer Satisfaction<br />Bugs<br />Product<br />Process<br />WIP<br />Cadence<br />CI Failures<br />Rework<br />Impediments<br />Retrospectives<br />Reviews<br />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />fragile<br />Team Maturity<br />
  22. 22. metrics quadrants<br />Business<br />Lead Time<br />Cycle Time<br />Quality of Service (SLA)<br />Throughput<br />Business Value<br />Revenues<br />ROI<br />Customer Satisfaction<br />agile<br />Bugs<br />Product<br />Process<br />WIP<br />Cadence<br />CI Failures<br />Rework<br />Impediments<br />Retrospectives<br />Reviews<br />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />fragile<br />Team Maturity<br />
  23. 23. fragility<br /> code quality<br /> technical debt<br />lack of advanced engineering practices<br />(i.e. TDD, CI) => rework<br />
  24. 24. code quality evolution<br />a short video<br />
  25. 25. agility<br />backlog<br />to do<br />in progress<br />done<br />2<br />2<br />
  26. 26. agility<br />being agile is not the goal,<br />it’s a mean<br />if you are really interested there are plenty of agility tests on the Internet:<br />Nokia Test<br />Scrum Open Assessment - ScrumAlliance<br />Agile Maturity Model<br />Agile Evaluation Framework<br />Comparative Agility Assessment<br />etc.<br />
  27. 27. impediments, retrospectives, reviews<br /># of questions answered<br /># of questions asked <br /># action items addressed<br /># action items assignedat previous meetings<br /># of WTFs<br />?<br />WTF!?<br />WTF!?<br />
  28. 28. backlogs & taskboardseverywhere<br />tasks/user stories<br />defects/SLA tickets<br />impediments<br />action items (reviews)<br />new<br />age based pruning<br />kill old<br />items!<br />old<br />
  29. 29. queues<br />add<br />cycle time<br />risk<br />variability<br />overhead<br />reduce<br />quality<br />motivation<br />stop starting start finishing<br />
  30. 30. cumulative flow diagram<br />arrivals<br />queue size<br />(WIP)<br />cumulative<br />quantity<br />time in queue<br />(cycle time)<br />departures<br />(throughput)<br />time<br />source: Donald Reinertsen<br />
  31. 31. cumulative flow diagramincreasing queue sizeincreasing cycle time<br />cycle time<br />WIP<br />cumulative<br />quantity<br />time<br />source: Donald Reinertsen<br />
  32. 32. cumulative flow diagramWIP is a leading indicator<br />cycle time<br />cumulative<br />quantity<br />WIP<br />time<br />source: Donald Reinertsen<br />
  33. 33. cumulative flow diagramlarge batches large queues<br />cumulative<br />quantity<br />time<br />
  34. 34. cumulative flow diagramsmall batches small queues<br />cumulative<br />quantity<br />time<br />source: Donald Reinertsen<br />
  35. 35. cumulative flow diagramsmall batches continuous flow<br />cumulative<br />quantity<br />time<br />
  36. 36. Kanban board<br />WIP<br />throughput<br />cycletime =<br />backlog<br />to do<br />in progress<br />done<br />2<br />2<br />cycle time<br />inspired by HenrikKniberg<br />
  37. 37. no WIP limit -> queue!<br />in progress<br />ready<br />backlog<br />to do<br />done<br />2<br />3<br />
  38. 38. no WIP limit -> queue!<br />ready<br />backlog<br />to do<br />done<br />in progress<br />2<br />3<br />flow= speed * density<br />
  39. 39. Slack (%)<br />optimize flow<br />absorb variation<br />
  40. 40. cumulative flow diagram<br />backlog<br />to do<br />in progress<br /># user stories<br />cycle time<br />WIP<br />throughput<br />done<br />time<br />
  41. 41. controlcharts<br />source: SamuliHeljo<br />
  42. 42. additional flowrelated metrics<br />active WIP<br />tasks that are really in progress and not waiting around (#,%,% of time spent)<br />buffered WIP<br />tasks waiting to be handed-off<br />process efficiency<br />active time / cycle time<br />technical debtWIP / standard WIP<br /># of projects a person works in parallel<br />
  43. 43. Happiness Index<br />niko-niko calendar<br />
  44. 44. how long since?<br />you talked to a customer<br />last useful retrospective<br />you learned something at work<br />your boss last freaked out<br />last critical bug<br />3<br />1<br />6<br />52<br />2<br />days<br />days<br />days<br />weeks<br />week<br />
  45. 45. and don’t forget<br />bus factor<br /># of key developers that need to be hit by a bus to kill a project<br />
  46. 46. “per una vera<br />mille sono finte”<br />F. De André<br />“for every true one<br />thousands are fake”<br />
  47. 47.
  48. 48. Gaetano Mazzanti<br />Gama-Tech<br />@mgaewsj<br />info@gama-tech.net<br />

×