Downloaded 55 times
![boundary objectsmetricbusinessR&Dboundary object [sociology]: something that helps different communities exchange ideas and information.could mean different things to differentpeoplebut allows coordination and alignment](https://image.slidesharecdn.com/metricsale2011-110910035416-phpapp02/85/How-fr-agile-we-are-ALE2011-11-320.jpg)
Uploaded byGaetano Mazzanti
How (fr)agile we are. ALE2011
This document discusses metrics for agile product development. It argues that traditional metrics designed for linear processes do not work for complex and unpredictable agile systems. Instead, it recommends focusing on metrics that allow for learning and change over time through single and double loop learning. The document presents a framework with four quadrants of metrics for measuring business outcomes, products, processes, and team maturity using metrics that serve as "boundary objects" between teams.
More Related Content
Similar to How (fr)agile we are. ALE2011
How (fr)agile we are. ALE2011
- 1. how (fr)agilewe aremetricsin a complex worldGaetano MazzantiGama-Tech
- 2. ???agilemetrics for alinear, deterministic worldtraditionalno metricscode & fixrigidprocesstop-downno processchaosorderedchaoticcomplex
- 3. product development iscomplex“self-organizing, non-linear,feedback systems areinherently unpredictable,they are not controllable“D.Meadows
- 4. however, we canwatch,learn and workwith the system
- 5.
- 6. single loop learningresultsactionsleadtohowwhich shape futureefficiencydoing things right incremental change
- 7. double loop learningresultsactionsvalues,assumptionsChris Argyrisguidehowwhylead to new/improved effectivenessdoing the right thingsefficiencydoing things right question assumptionsradical changeincremental change
- 8. learn, change,move onresultsactionsvalues,assumptionsdefinemetric*setexpirationdategoal ok orexpirationdate passed?metric*shared, simple, controllable, transparent, time-bound
- 9.
- 10. inward & outwardlookingmetricsoutwardloookinginwardlookingfeedbackR&DBusiness & Other Stakeholdersboundary objects
- 11. boundary objectsmetricbusinessR&Dboundary object[sociology]: something that helps different communities exchange ideas and information.could mean different things to differentpeoplebut allows coordination and alignment
- 12. metrics quadrantsBusinessoutward looking&feedbackProductProcessinwardlookingTeam Maturity
- 13.
- 14.
- 15.
- 16. metrics quadrantsBusinessLead TimeCycleTimeQuality of Service (SLA)ThroughputBusiness ValueRevenuesROICustomer SatisfactionBugs?ProductProcessWIPCadenceCI FailuresReworkImpedimentsRetrospectivesMoraleCode QualityTechnical DebtTest CoverageTeam Maturity
- 17. metrics quadrantsBusinesswhat!?no velocity?LeadTimeCycle TimeQuality of Service (SLA)ThroughputBusiness ValueRevenuesROICustomer SatisfactionBugs?ProductProcessWIPCadenceCI FailuresReworkImpedimentsRetrospectivesMoraleCode QualityTechnical DebtTest CoverageTeam Maturity
- 18. metrics quadrantsBusinessLead TimeCycleTimeQuality of Service (SLA)ThroughputBusiness ValueRevenuesROICustomer SatisfactionboundaryobjectsBugs?ProductProcessWIPCadenceCI FailuresReworkImpedimentsRetrospectivesMoraleCode QualityTechnical DebtTest CoverageTeam Maturity
- 19. metrics quadrantsBusinessLead TimeCycleTimeQuality of Service (SLA)ThroughputBusiness ValueRevenuesROICustomer SatisfactionboundaryobjectsBugs?ProductProcessWIPCadenceCI FailuresReworkImpedimentsRetrospectivesMoraleCode QualityTechnical DebtTest CoveragefragileTeam Maturity
- 20. metrics quadrantsBusinessLead TimeCycleTimeQuality of Service (SLA)ThroughputBusiness ValueRevenuesROICustomer SatisfactionboundaryobjectsagileBugs?ProductProcessWIPCadenceCI FailuresReworkImpedimentsRetrospectivesMoraleCode QualityTechnical DebtTest CoveragefragileTeam Maturity
- 21. fragility code quality technical debtlack of advanced engineering practices(i.e. TDD, CI) => rework
- 22.
- 23.
- 24. agilitybeing agile isnot the goal,it’s a meanif you are really interested there are plenty of agility tests on the Internet:Nokia TestScrum Open Assessment - ScrumAllianceAgile Maturity ModelAgile Evaluation FrameworkComparative Agility Assessmentetc.
- 25. impediments, retrospectives, reviews#of questions answered# of questions asked # action items addressed# action items assigned(at previous meetings)# of WTFs?WTF!?WTF!?
- 26.
- 27. queues are badincreasecycletimeriskvariabilityoverheadreducequalitymotivationstop starting start finishing
- 28. cumulative flow diagramarrivalsqueuesize(WIP)cumulativequantitytime in queue(cycle time)departures(throughput)timesource: Donald Reinertsen
- 29. cumulative flow diagramWIP is a leading indicatorcycle timeWIPcumulativequantitytime
- 30. cumulative flow diagramlargebatches large queuescumulativequantitytime
- 31. cumulative flow diagramsmallbatches small queuescumulativequantitytime
- 32. Kanban boardWIPthroughputcycletime =backlogtodoin progressdone23cycle time
- 33. no WIP limit-> queue!in progressreadybacklogto dodone23
- 34. no WIP limit-> queue!readybacklogto dodonein progress23flow= speed * density
- 35. Slack (%)optimize flowabsorbvariation
- 36. flow related metricsactiveWIP -buffered WIPtasks that are really in progress – task waiting to be handed-off (#,%,% of time spent)process efficiencyactive time / cycle timeBIPBugs In Processtechnical debtWIP / standard WIP# of projects a person works in parallel
- 37. visualizing tasks dynamicsbacklogtodoin progressdone241234inactive taskdays
- 38. cumulative flow diagramnotso helpful?backlogto doin progress# user storiescycle timeWIPthroughputdonetime
- 39.
- 40.
- 41.
- 42.
- 43.
- 44. Pizza IndexPizza =Overtime => not goodSteve Denning
- 45. how long since?youtalked to a customerlast useful retrospectiveyou learned something at workyour boss last freaked outlast critical bug635221daysdaysdaysweeksweek
- 46. and don’t forgetbusfactor# of key developers that need to be hit by a bus to kill a project
Editor's Notes
- #4 See also law of requisite variety
- #5 We can dance with the system – D.Meadows
- #6 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)
- #7 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.”
- #8 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?
- #9 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
- #12 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
- #13 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
- #14 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
- #15 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
- #16 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
- #17 Outcome trumps output and activityNo measures related to individuals, “The basic building block of work is a team, not an individual” (esther derby)
- #18 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)
- #19 Technical debt = 1 / design qualityRefactoring code that has no value is a waste of time
- #20 Technical debt = 1 / design qualityRefactoring code that has no value is a waste of time
- #21 Technical debt = 1 / design quality
- #22 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.
- #23 Code quality leading indicator … successful products with poor quality, but …
- #28 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
- #34 it isn’t easy to ignore a blocked and work on something else
- #35 it isn’t easy to ignore a blocked and work on something else
- #37 BIP Bugs In Process
- #44 Check also pizza index (overtime = pizzas -> should drop to zero)
- #45 Check also pizza index (overtime = pizzas -> should drop to zero)
- #46 Simple, controllableSome of these mentioned by ArloBelshee