How (fr)agile we are. ALE2011

2,035 views

Published on

Slides of my presentation at ALE2011

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,035
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
51
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • See also law of requisite variety
  • We can dance with the system – D.Meadows
  • metrics as learning & change agentsMetricheaiutano a capire e prendereunadirezionepiuttostocheun’altraif you're not making mistakes & changing your mind, you're not learning. If you're not learning why are you iterating & collecting feedback?shift from “build, measure, learn” to “learn, measure, build” (Lean Startup)
  • single is correcting an action to solve or avoid a mistake, double is correcting also the underlying causes behind the problematic actionLocal maximum, not global best … single = short termPDCAinspect. Single loop learning asks, “How can we do what we are doing better.”
  • Kaikakukaizen, toglierepilotaautomatico!Argyris & Schon's Theory of Action, Double loop learning asks “Why do we think this is the right thing to do,” Fix the causes not the symptoms. Inspect and adapt, single loop?
  • Focus on the positives. identifying the negatives and trying to fix them builds a wrong culture Metrics are needed to improve and not to punishBTW Failing is ok. self-definedsimplecontrollabletransparenttime-bound: created without extra effort, meaningful to all stakeholdersfocus on things that are actually controllable by the people being measuredLeading. prefer an imperfect forecast of the future to a perfect report on the past.visible and accessible without extra effortToo many metrics -> overload -> waste
  • help to carry meaning, promote communication and assist with understanding. They serve as both containers and carriers. BOs are highly abstract and generalized form of knowledge organization with considerable reification. Classification systems, ontologies, paper forms serve as BOs (where they are used by diverse groups). An prime example of a BO is an ERP order entry process, a shared information space, a product tracking number, RFID tag
  • Scorecard, sort of… Vanity metrics are things like registered users, downloads, and raw pageviews. They are easily manipulated, and do not necessarily correlate to the numbers that really matter: active users, engagement, the cost of getting new customers, and ultimately revenues and profits. The latter are moreactionable metricsThe only metrics that entrepreneurs should invest energy in collecting are those that help them make decisions. Eric Ries
  • Scorecard, sort of… Vanity metrics are things like registered users, downloads, and raw pageviews. They are easily manipulated, and do not necessarily correlate to the numbers that really matter: active users, engagement, the cost of getting new customers, and ultimately revenues and profits. The latter are moreactionable metricsThe only metrics that entrepreneurs should invest energy in collecting are those that help them make decisions. Eric Ries
  • Scorecard, sort of… Vanity metrics are things like registered users, downloads, and raw pageviews. They are easily manipulated, and do not necessarily correlate to the numbers that really matter: active users, engagement, the cost of getting new customers, and ultimately revenues and profits. The latter are moreactionable metricsThe only metrics that entrepreneurs should invest energy in collecting are those that help them make decisions. Eric Ries
  • Scorecard, sort of… Vanity metrics are things like registered users, downloads, and raw pageviews. They are easily manipulated, and do not necessarily correlate to the numbers that really matter: active users, engagement, the cost of getting new customers, and ultimately revenues and profits. The latter are moreactionable metricsThe only metrics that entrepreneurs should invest energy in collecting are those that help them make decisions. Eric Ries
  • Outcome trumps output and activityNo measures related to individuals, “The basic building block of work is a team, not an individual” (esther derby)
  • no clue abouteffectiveness/valueinducesextra effort/waste to correctly (!?) estimate -> don’t use it to predicteasy to be gamed ->don’t use it as a targetmeasure throughput instead (# of stories per iteration)
  • Technical debt = 1 / design qualityRefactoring code that has no value is a waste of time
  • Technical debt = 1 / design qualityRefactoring code that has no value is a waste of time
  • Technical debt = 1 / design quality
  • if nobody likes or wants to use your product, code quality does not really matter Technical debt = 1 / design quality Technical debt != bad codeWard CunninghamA little debt speeds development so long as it is paid back promptly with a rewrite.Every minute spent on not-quite-right code counts as interest on that debt.[Many] have explained the debt metaphor and confused it with the idea that you could write code poorly with the intention of doing a good job later.The ability to pay back debt [...] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.
  • Code quality leading indicator … successful products with poor quality, but …
  • It takes longer to reach the front of a large line, this increases risk (customer & market), and variability (we move to a higher level of utilization where variability is amplified), more queues=more tasks & projects to track & report on, delayed feedback means bad assumptions live longer in code etc., no need to hurry if downstream activities will happen weeks later
  • it isn’t easy to ignore a blocked and work on something else
  • it isn’t easy to ignore a blocked and work on something else
  • BIP Bugs In Process
  • Check also pizza index (overtime = pizzas -> should drop to zero)
  • Check also pizza index (overtime = pizzas -> should drop to zero)
  • Simple, controllableSome of these mentioned by ArloBelshee
  • How (fr)agile we are. ALE2011

    1. 1. how (fr)agilewe aremetrics in a complex world<br />Gaetano Mazzanti<br />Gama-Tech<br />
    2. 2. ???<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 />
    3. 3. 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 />
    4. 4. however, we can<br />watch, learn and work<br />with the system<br />
    5. 5. metrics<br />learn & change<br />
    6. 6. 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 />
    7. 7. 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 />
    8. 8. learn, change,move on<br />results<br />actions<br />values, assumptions<br />definemetric*<br />setexpirationdate<br />goal ok orexpiration<br />date passed?<br />metric<br />*shared, simple, controllable, transparent, time-bound<br />
    9. 9. metrics<br />quadrants<br />
    10. 10. inward & outwardlooking metrics<br />outward<br />loooking<br />inward<br />looking<br />feedback<br />R&D<br />Business & Other Stakeholders<br />boundary objects<br />
    11. 11. boundary objects<br />metric<br />business<br />R&D<br />boundary object [sociology]: something that helps different communities exchange ideas and information.<br />could mean different things to differentpeople<br />but allows coordination and alignment<br />
    12. 12. metrics quadrants<br />Business<br />outward looking<br />&<br />feedback<br />Product<br />Process<br />inward looking<br />Team Maturity<br />
    13. 13. metrics quadrants<br />Business<br />boundary<br />objects<br />Product<br />Process<br />Team Maturity<br />
    14. 14. metrics quadrants<br />Business<br />boundary<br />objects<br />agile<br />Product<br />Process<br />fragile<br />Team Maturity<br />
    15. 15. metrics quadrants<br />Business<br />Product<br />Process<br />Team Maturity<br />
    16. 16. 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 />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />Team Maturity<br />
    17. 17. 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 />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />Team Maturity<br />
    18. 18. 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 />boundary<br />objects<br />Bugs?<br />Product<br />Process<br />WIP<br />Cadence<br />CI Failures<br />Rework<br />Impediments<br />Retrospectives<br />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />Team Maturity<br />
    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 />boundary<br />objects<br />Bugs?<br />Product<br />Process<br />WIP<br />Cadence<br />CI Failures<br />Rework<br />Impediments<br />Retrospectives<br />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />fragile<br />Team Maturity<br />
    20. 20. 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 />boundary<br />objects<br />agile<br />Bugs?<br />Product<br />Process<br />WIP<br />Cadence<br />CI Failures<br />Rework<br />Impediments<br />Retrospectives<br />Morale<br />Code QualityTechnical Debt<br />Test Coverage<br />fragile<br />Team Maturity<br />
    21. 21. fragility<br /> code quality<br /> technical debt<br />lack of advanced engineering practices<br />(i.e. TDD, CI) => rework<br />
    22. 22. code quality evolution<br />
    23. 23. code qualityevolution<br />
    24. 24. 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 />
    25. 25. impediments, retrospectives, reviews<br /># of questions answered<br /># of questions asked <br /># action items addressed<br /># action items assigned(at previous meetings)<br /># of WTFs<br />?<br />WTF!?<br />WTF!?<br />
    26. 26. metrics<br />queues<br />
    27. 27. queues are bad<br />increase<br />cycle time<br />risk<br />variability<br />overhead<br />reduce<br />quality<br />motivation<br />stop starting start finishing<br />
    28. 28. 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 />
    29. 29. cumulative flow diagram WIP is a leading indicator<br />cycle time<br />WIP<br />cumulative<br />quantity<br />time<br />
    30. 30. cumulative flow diagramlarge batches large queues<br />cumulative<br />quantity<br />time<br />
    31. 31. cumulative flow diagramsmall batches small queues<br />cumulative<br />quantity<br />time<br />
    32. 32. Kanban board<br />WIP<br />throughput<br />cycletime =<br />backlog<br />to do<br />in progress<br />done<br />2<br />3<br />cycle time<br />
    33. 33. no WIP limit -> queue!<br />in progress<br />ready<br />backlog<br />to do<br />done<br />2<br />3<br />
    34. 34. 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 />
    35. 35. Slack (%)<br />optimize flow<br />absorb variation<br />
    36. 36. flow related metrics<br />active WIP -buffered WIP<br />tasks that are really in progress – task waiting to be handed-off (#,%,% of time spent)<br />process efficiency<br />active time / cycle time<br />BIP<br />Bugs In Process<br />technical debtWIP / standard WIP<br /># of projects a person works in parallel<br />
    37. 37. visualizing tasks dynamics<br />backlog<br />to do<br />in progress<br />done<br />2<br />4<br />1<br />2<br />3<br />4<br />inactive task<br />days<br />
    38. 38. cumulative flow diagram<br />not so helpful?<br />backlog<br />to do<br />in progress<br /># user stories<br />cycle time<br />WIP<br />throughput<br />done<br />time<br />
    39. 39. single column dynamics<br />WIP<br />
    40. 40. Kanbanboarddynamics<br />
    41. 41. controlcharts<br />source: SamuliHeljo<br />
    42. 42. metrics<br />easy but powerful<br />42<br />
    43. 43. Happiness Index<br />feedback board<br />niko-niko calendar<br />
    44. 44. Pizza Index<br />Pizza = Overtime => not good<br />Steve Denning<br />
    45. 45. 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 />6<br />3<br />52<br />2<br />1<br />days<br />days<br />days<br />weeks<br />week<br />
    46. 46. and don’t forget<br />bus factor<br /># of key developers that need to be hit by a bus to kill a project<br />
    47. 47. “per una vera<br />mille sono finte”<br />F. De André<br />“for every true one<br />thousands are fake”<br />
    48. 48.
    49. 49. Gaetano Mazzanti<br />Gama-Tech<br />@mgaewsj<br />info@gama-tech.net<br />

    ×