How (fr)agile we are. ALE2011
•Download as PPTX, PDF•
4 likes•1,239 views
Slides of my presentation at ALE2011
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to How (fr)agile we are. ALE2011
Similar to How (fr)agile we are. ALE2011 (20)
More from Gaetano Mazzanti
More from Gaetano Mazzanti (12)
Recently uploaded
Recently uploaded (20)
How (fr)agile we are. ALE2011
- 1. how (fr)agilewe aremetrics in a complex world Gaetano Mazzanti Gama-Tech
- 2. ??? agile metrics for a linear, deterministic world traditional no metrics code & fix rigidprocess top-down no processchaos ordered chaotic complex
- 3. product development is complex “self-organizing, non-linear, feedback systems are inherently unpredictable, they are not controllable“ D.Meadows
- 4. however, we can watch, learn and work with the system
- 5. metrics learn & change
- 6. single loop learning results actions lead to how which shape future efficiency doing things right incremental change
- 7. double loop learning results actions values, assumptions Chris Argyris guide how why lead to new/improved effectiveness doing the right things efficiency doing things right question assumptions radical change incremental change
- 8. learn, change,move on results actions values, assumptions definemetric* setexpirationdate goal ok orexpiration date passed? metric *shared, simple, controllable, transparent, time-bound
- 10. inward & outwardlooking metrics outward loooking inward looking feedback R&D Business & Other Stakeholders boundary objects
- 11. boundary objects metric business R&D boundary object [sociology]: something that helps different communities exchange ideas and information. could mean different things to differentpeople but allows coordination and alignment
- 12. metrics quadrants Business outward looking & feedback Product Process inward looking Team Maturity
- 13. metrics quadrants Business boundary objects Product Process Team Maturity
- 14. metrics quadrants Business boundary objects agile Product Process fragile Team Maturity
- 15. metrics quadrants Business Product Process Team Maturity
- 16. metrics quadrants Business Lead Time Cycle Time Quality of Service (SLA) Throughput Business Value Revenues ROI Customer Satisfaction Bugs? Product Process WIP Cadence CI Failures Rework Impediments Retrospectives Morale Code QualityTechnical Debt Test Coverage Team Maturity
- 17. metrics quadrants Business what!? no velocity? Lead Time Cycle Time Quality of Service (SLA) Throughput Business Value Revenues ROI Customer Satisfaction Bugs? Product Process WIP Cadence CI Failures Rework Impediments Retrospectives Morale Code QualityTechnical Debt Test Coverage Team Maturity
- 18. metrics quadrants Business Lead Time Cycle Time Quality of Service (SLA) Throughput Business Value Revenues ROI Customer Satisfaction boundary objects Bugs? Product Process WIP Cadence CI Failures Rework Impediments Retrospectives Morale Code QualityTechnical Debt Test Coverage Team Maturity
- 19. metrics quadrants Business Lead Time Cycle Time Quality of Service (SLA) Throughput Business Value Revenues ROI Customer Satisfaction boundary objects Bugs? Product Process WIP Cadence CI Failures Rework Impediments Retrospectives Morale Code QualityTechnical Debt Test Coverage fragile Team Maturity
- 20. metrics quadrants Business Lead Time Cycle Time Quality of Service (SLA) Throughput Business Value Revenues ROI Customer Satisfaction boundary objects agile Bugs? Product Process WIP Cadence CI Failures Rework Impediments Retrospectives Morale Code QualityTechnical Debt Test Coverage fragile Team Maturity
- 21. fragility code quality technical debt lack of advanced engineering practices (i.e. TDD, CI) => rework
- 24. agility being agile is not the goal, it’s a mean if you are really interested there are plenty of agility tests on the Internet: Nokia Test Scrum Open Assessment - ScrumAlliance Agile Maturity Model Agile Evaluation Framework Comparative Agility Assessment etc.
- 25. impediments, retrospectives, reviews # of questions answered # of questions asked # action items addressed # action items assigned(at previous meetings) # of WTFs ? WTF!? WTF!?
- 26. metrics queues
- 27. queues are bad increase cycle time risk variability overhead reduce quality motivation stop starting start finishing
- 28. cumulative flow diagram arrivals queue size (WIP) cumulative quantity time in queue (cycle time) departures (throughput) time source: Donald Reinertsen
- 29. cumulative flow diagram WIP is a leading indicator cycle time WIP cumulative quantity time
- 30. cumulative flow diagramlarge batches large queues cumulative quantity time
- 31. cumulative flow diagramsmall batches small queues cumulative quantity time
- 32. Kanban board WIP throughput cycletime = backlog to do in progress done 2 3 cycle time
- 33. no WIP limit -> queue! in progress ready backlog to do done 2 3
- 34. no WIP limit -> queue! ready backlog to do done in progress 2 3 flow= speed * density
- 35. Slack (%) optimize flow absorb variation
- 36. flow related metrics active WIP -buffered WIP tasks that are really in progress – task waiting to be handed-off (#,%,% of time spent) process efficiency active time / cycle time BIP Bugs In Process technical debtWIP / standard WIP # of projects a person works in parallel
- 37. visualizing tasks dynamics backlog to do in progress done 2 4 1 2 3 4 inactive task days
- 38. cumulative flow diagram not so helpful? backlog to do in progress # user stories cycle time WIP throughput done time
- 39. single column dynamics WIP
- 42. metrics easy but powerful 42
- 43. Happiness Index feedback board niko-niko calendar
- 44. Pizza Index Pizza = Overtime => not good Steve Denning
- 45. how long since? you talked to a customer last useful retrospective you learned something at work your boss last freaked out last critical bug 6 3 52 2 1 days days days weeks week
- 46. and don’t forget bus factor # of key developers that need to be hit by a bus to kill a project
- 47. “per una vera mille sono finte” F. De André “for every true one thousands are fake”
- 49. Gaetano Mazzanti Gama-Tech @mgaewsj info@gama-tech.net
Editor's Notes
- 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