Agile Analytics: A GQM Approach to Enterprise Metrics
16 likes•25,064 views
The document discusses the Goal-Question-Metric (GQM) approach to enterprise agile metrics, emphasizing the need for structured metrics in measuring performance at various organizational levels. It criticizes the extremes of having too many or too few metrics, advocating instead for balanced metrics that provide clarity in assessing team performance, program health, and portfolio effectiveness. The GQM approach aims to define relevant goals, ask the right questions, and identify measurable metrics to promote continuous improvement in agile environments.
Agile Analytics: A GQM Approach to Enterprise Metrics
- 1. © 2012 Fiserv, Inc. or its affiliates. The GQM Approach to Enterprise Agile Metrics Version 1.42
- 2. © 2012 Fiserv, Inc. or its affiliates. John Tanner SVP & Enterprise Transformation Consultant, LeadingAgile Ø 20+ years in Software Development Ø Roles in industry as Consultant, Engineer, Architect, Product & Project Manager Ø Implemented Agile in all the environments: o Non-profit o Corporate o Government [email protected] www.linkedin.com/in/tannerjs www.facebook.com/leadingagile www.twitter.com/leadingagile
- 3. © 2012 Fiserv, Inc. or its affiliates. Defining the Problem
- 4. © 2012 Fiserv, Inc. or its affiliates. Three views on metrics • We need maximum metrics, because we just don’t know what we don’t know • We need minimal metrics, because they just don’t add value • We need some metrics, because something is better than nothing
- 5. © 2012 Fiserv, Inc. or its affiliates. We need all of the metrics! “Metrics are how we measure success. So let’s capture metrics for everything.” • Metrics dashboards become prolific, and someone has to maintain them • Each Team winds up with a unique set of metrics to capture, but with no common expectation for using them • The organization spends more time creating metrics roll- ups than they do creating product • There is no cohesive strategy for tying the data together to make targeted improvements
- 6. © 2012 Fiserv, Inc. or its affiliates. We need none of the metrics! “Metrics do not add value, so they are waste. Let’s eliminate them altogether.” • Assumes all teams are currently producing working, tested product at high levels of efficiency • Only works when the organization doesn’t care if they ever improve the system… • … doesn’t care if they aren’t producing value • … doesn’t get hung up on details like making payroll
- 7. © 2012 Fiserv, Inc. or its affiliates. We need some metrics… “Metrics might help us improve, so we need measures of some sort.” • Without clarity, we often capture metrics for metrics’ sake • When we gather metrics without clear expectations around their use they can be wasteful, or even harmful • We focus on metrics in a way that ultimately drives “local optimization” at the expense of the overall system • We forget that the “why” and the “how” matters
- 8. © 2012 Fiserv, Inc. or its affiliates. The “why” and the “how”
- 9. © 2012 Fiserv, Inc. or its affiliates. Let’s talk about why, first… Backlog item Backlog item Backlog item Backlog item Backlog item Backlogs Team Teams Working Tested Product Working Tested Product
- 10. © 2012 Fiserv, Inc. or its affiliates. How we often approach the problem In Agile, we feel pretty confident we know how to measure success because… ... is Making and Meeting Commitments ... is Producing Quality Software The Team ... has a Stable Velocity
- 11. © 2012 Fiserv, Inc. or its affiliates. Team Backlog item Backlog item Backlog item Backlog item Backlog item Working Tested Product Makes & Meets Commitments Metric: Story Point Completion % Has a Stable Velocity Metric: Velocity Variance Produces Quality Software Metric: Escaped Defect Count How we often approach the problem
- 12. © 2012 Fiserv, Inc. or its affiliates. Problem Solved? Yay! We did it team! No, but seriously, many people think like that…
- 13. © 2012 Fiserv, Inc. or its affiliates. How does that work at scale? Team Team Team Team TeamTeamTeam Delivery Tier Team Team Team Program Tier Team Portfolio Tier
- 14. © 2012 Fiserv, Inc. or its affiliates. Goal-Question-Metric
- 15. © 2012 Fiserv, Inc. or its affiliates. What is GQM? The Goal-Question-Metric approach is a simple model where we approach measures from three distinct levels: Conceptual level (Goal) Operational level (Question) Quantitative level (Metric)
- 16. © 2012 Fiserv, Inc. or its affiliates. What is GQM? Conceptual level (Goal) A goal is defined for a team or system, to meet a specific purpose, with a focus on demonstrating a meaningful outcome for the business.
- 17. © 2012 Fiserv, Inc. or its affiliates. What is GQM? Operational level (Question) A set of questions is crafted to define an objective model for assessing the achievement of our goals.
- 18. © 2012 Fiserv, Inc. or its affiliates. What is GQM? Quantitative level (Metric) A set of metrics, based upon the objective model, is associated with every question in order to answer it in a measurable way.
- 19. © 2012 Fiserv, Inc. or its affiliates. • Identify the right goals for a team or system • Clarify our goals by asking the right questions • Identify measures and metrics that can answer the questions • Find ways to collect the data necessary to realize our measures and metrics • Analyze the data to assess whether we are answering our questions and achieving our goals • Use what we discover to improve our goals, questions, and metrics How do we use GQM?
- 20. © 2012 Fiserv, Inc. or its affiliates. Example: My goal for today Goal My audience doesn't fall asleep in the next half hour Question Did they even show up in the first place? Have they been thoroughly caffeinated? Are they paying attention so far? Metric Empty Seat vs Sold Seat (Actual vs Expected) Snore to Silence Ratio (Snore Complete / Silence Committed) Eye Contact Variance Heckling Density
- 21. © 2012 Fiserv, Inc. or its affiliates. Redefining the Problem
- 22. © 2012 Fiserv, Inc. or its affiliates. Redefining the Problem In Agile, we feel pretty confident we know how to measure success because… ... is meeting Commitments ... is Producing Quality Software The Team ... has a Stable Velocity
- 23. © 2012 Fiserv, Inc. or its affiliates. Redefining the Problem Let’s figure it out, GQM style In Enterprise Agile, we feel pretty confident we know how to measure success because…
- 24. © 2012 Fiserv, Inc. or its affiliates. GQM Areas to Discuss • Delivery Team Health (Scrum) • Technical Quality • Program Health • Product Quality • Portfolio Health • Portfolio Financials
- 25. © 2012 Fiserv, Inc. or its affiliates. GQM at the Delivery Tier
- 26. © 2012 Fiserv, Inc. or its affiliates. Teams can plan, coordinate, and deliver predictably enough to meet a release level commitment Has the team established a stable velocity? Does the team have the resources it needs to be successful? Does the team deliver the committed functionality each sprint? Story Point Completion % (SPs Complete / SPs Committed) Velocity Variance Team Stability Index Is anything preventing the team from delivering on commitments? Blockers Does the team deliver throughout the sprint or at the “last minute”? Sprint Completion Ratio (%SPs Accepted by Sprint End - 2) Delivery Team Health (Scrum) Goal MetricQuestion User Story Completion % (USs Complete / USs Committed) To what degree is the team encapsulated (i.e. make/meet commitments on its own)? % User Stories w/ outside dependencies
- 27. © 2012 Fiserv, Inc. or its affiliates. Teams can frequently deliver working, tested software of a high level of quality Is the team able to maintain the overall technical health of the product? Can the quality of the product being shipped be verified? Open Defects Technical Debt Are the teams able to address technical problems in a timely manner? Defect Aging Are technical problems getting past our quality checks? Escaped Defects Are technical problems being discovered in production? Latent Defects Goal Question Metric Technical Quality
- 28. © 2012 Fiserv, Inc. or its affiliates. GQM at the Program Tier
- 29. © 2012 Fiserv, Inc. or its affiliates. Program Health Program Management can make delivery commitments and successfully manage incoming requests Is the Program effectively managing orchestration / mitigating dependencies? Is the program delivering committed functionality each release? Is the roadmap of features sufficient to effectively maintain a ready backlog? Feature Roadmap Visibility % Ready Backlog User Stories w/ open dependencies Feature Completion Ratio How long does it take for an Opportunity to move from Idea to Delivery? Feature Lead Time Goal MetricQuestion Is the Ready Backlog sufficiently groomed to be predictably consumed by the DT? % Ready Backlog Is the Program (PO Team) focused on delivering value? % Value in Sprint
- 30. © 2012 Fiserv, Inc. or its affiliates. Goal Question Metric The organization delivers an intuitive experience and product features that delight our customers and produce the highest business value possible Did the delivered solution meet the business need? Product/Market Fit (Actual vs Expected) Does the Overall Product Delight the Customer? Net Promoter Score Did the Feature Delight the Customer? Pirate Metrics (Acquisition, Activation, Retention, Revenue, Referral) Product Quality
- 31. © 2012 Fiserv, Inc. or its affiliates. GQM at the Portfolio Tier
- 32. © 2012 Fiserv, Inc. or its affiliates. Portfolio Health 32 The organization delivers product features and capabilities with the best ability to deliver early ROI How long does it take for an opportunity to move from “good idea” to ”done”? Is the system delivering consistently? Epic Lead Time Due Date Performance Are we investing in the right type of work? Portfolio Investment Mix Are we focusing only on the most important things? Value Stream WIP Abandoned WorkAre we starting on too many things? Goal Question Metric
- 33. © 2012 Fiserv, Inc. or its affiliates. Portfolio Financials 33 Goal Metric The Portfolio is meeting its strategic, financial obligations and objectives Are we getting the right return on our investments? Are we spending too much just to keep the lights on? Value to Cost Ratio CAPEX to OPEX Ratio Are we getting the expected results from this Portfolio? Variance to Results ($ or % Market Share) Question Are we meeting our targeted spend rates? Variance to Spend Target Are we hitting our targeted value and maintenance blend? Variance to Value/Maintenance Target ($ or % Spend)
- 34. © 2012 Fiserv, Inc. or its affiliates. Redefining the Problem (Solved)
- 35. © 2012 Fiserv, Inc. or its affiliates. At the Enterprise Level, we feel confident we know how to measure success because… The Portfolio ... consistently delivers product features & capabilities with a focus on time to market and early return on investment (Portfolio Health) ... consistently meets its strategic financial objects (Portfolio Financials) The Program ... can make delivery commitments and successfully manage incoming requests (Program Health) ... can ensure the organization delivers the most effective experience and product features to delight our customers and produce the highest business value possible (Product Quality) The Delivery Teams ... can plan, coordinate, and deliver predictably, in order to meet a release commitments (Team Health) ... can frequently deliver working tested code of a high level of quality (Technical Quality)
- 36. © 2012 Fiserv, Inc. or its affiliates. So now what?
- 37. © 2012 Fiserv, Inc. or its affiliates. üIdentify the right goals for a team or system üClarify our goals by asking the right questions üIdentify measures and metrics that can answer the questions • Find ways to collect the data necessary to realize our metrics and measures • Analyze the data to assess whether we are answering our questions and achieving our goals • Use what we discover to improve our goals, questions, and metrics Next Steps
- 38. © 2012 Fiserv, Inc. or its affiliates. Final Thoughts