Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Effective Agile Metrics, Cuneyt Gul


Published on

Effective agile metrics to trace productivity, quality and improvement.

Published in: Technology
  • Be the first to comment

Effective Agile Metrics, Cuneyt Gul

  1. 1. EFFECTIVE AGILE METRICS Agile Turkey Summit 2015 Cüneyt Gül SBM
  2. 2. CÜNEYT GÜL PMP, PSMI 2010 Agile Solutions and ADC Manager, SBM 2009 Architech, Milgem Project, Havelsan 2002 Development Manager, Sahinler Holding 2000 Developer, Core Banking Project, Finansbank & Cybersoft 2000 Marmara University, Computer Engineering
  3. 3. WHY METRICS DO TRACK METRICS •Measurable and Create actionable insight •Align with core business and team tenets •Changes the way you behave •Be able to stand alone DO NOT TRACK METRICS •Force you to look at more data •You can’t do anything about •You can’t somehow track back to something is important “A method of measuring something, or the results obtained from this.” —metrics defined by Google
  4. 4. KAIZEN = CONTINUOUS IMPROVEMENT WHY METRICS “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” —From Principles behind the Agile Manifesto Measuring Agile Metrics Lead to Improvement
  5. 5. WHY METRICS Drive the strategy and direction of the organization Provide focus for an organization, department or employee Help make decisions Drive performance Change and evolve with the organization Produce good internal and external public relations
  6. 6. PERFORMANCE METRICS KPI - “Quantifiable metrics which reflect the performance of an organization in achieving its goals and objectives KPIs are Graded Metrics – have explicit thresholds that grade the difference (or gap) between the actual value and the target.
  7. 7. Measure teams and processes not people THE HAWTHORNE EFFECT Positive Hawthorne Effect Features Accepted Sponsor Confidence Customer Satisfaction Defect Cycle Times Negative Hawthorne Effect Lines of Code Written Function Points Delivered Hours Worked
  8. 8. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals - From scrum-guide WHO IS RESPONSIBLE FOR TEAM PERFORMANCE IN SCRUM
  9. 9. FEEDBACK LOOP COLLECT - Collect data MEASURE - Do your analysis REACT - Apply Adjustments REPEAT - Continuously analysis and adjust
  10. 10. SOURCE SYSTEMS FOR TRENDS AND DATA * From Agile Metrics In Action, Christopher W. H. Davis
  11. 11. QUESTIONS How fast can you deliver changes to your consumer? How much change is happening in your codebase? How well are you serving the consumer? Are you delivering the right things? How consistent is the team in completing work? How good are the team’s requirements? And more .....
  12. 12. QUESTIONS DIFFICULT TO ANSWER Are you delivering the right things? Project tracking Application monitoring How good are the team’s requirements? Project tracking Source control • Easy To Answer With Project Tracking Data How good your team is at estimating work ?
  13. 13. TRENDS AND DATA FROM PROJECT TRACK SYSTEMS How well does your team understand the project? How fast is the team moving? How consistent is the team in completing work? Burn down, Release Burnup Velocity Cumulative flow, Lead time Bug counts (Escaped, Found )
  14. 14. PROJECT TRACK SYSTEMS Burn down Cumulative flow Velocity
  15. 15. TRENDS AND DATA FROM SOURCE CONTROL How much change is happening in the codebase? Who is working on what? How much effort is going into the work? Pull requests Merged pull requests Commits Reviews Comments CLOC (help risk calculation)
  17. 17. TECHNICAL DEBT Describes code that causes the system to be less extensible and more expensive to maintain. - from Agile Performance Improvement, Bob Winter Like borrowing money. Eventually you have to pay it back, with interest Measure technical debt with tracking quality metrics and static code analysis
  18. 18. REFACTORING New feature : A functionality that did not exist Refactoring : Changing the internal structure without changing the external functionality A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. - from Martin Fowler Make It Work and Then Make It Clean
  19. 19. TRENDS AND DATA FROM CI AND DEPLOYMENT SYSTEMS How fast are you delivering changes to your consumer? How consistently does your team do their work? Are you producing good code? How consistently you’re delivering ? Total number of tests Percentage of passing and failing tests Static analysis Test coverage percentage Code violations
  20. 20. INTEGRATION DELIVERY TESTING CONTINUOUS DEVELOPMENT Continuous development is a series of practices — of developing and testing software in a way that lets organizations quickly issue updates anytime. CONTINUOUS
  21. 21. FIRST STEP : CONTINUOUS INTEGRATION The practice of continuously building and testing your code as multiple team members update it Reduced risk No longer integrations Easier to find and remove bugs Increase visibility Remove barriers to frequently deployment CONTINUOUS TESTING It’s the practice of having tests continuously running on your codebase as you make changes to it.
  22. 22. CONTINUOUS DELIVERY “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” —Principles behind the Agile Manifesto Allow smaller changes deployments Quicker get user feedback and improve software. Reduce deployment risk
  23. 23. TRENDS AND DATA FROM APPLICATION MONITORING How your consumers are using your product? What experience your consumers have with your applications? Consumer usage Convertion rate Server health statistics Semantic logging analysis
  25. 25. Team Metrics 40% Customer Satisfaction 20% D/C 20% Innovation Rate 20% Lead Time Improvement 10% Quality 20% Velocity consistency 10% TOTAL 100% AGILE PERFORMANCE MEASUREMENT AT SBM TEAM METRICS
  26. 26. Team Assessment 30% TEAM Mgr1 Mgr2 Technical knowledge 10% 50% 30% 20% Business Knowledge 10% Focus on delivering quality work 10% Communication skill 10% Analytical thinking 10% Agile Process Knowledge 10% Contribute to the self-organizing 10% Learning and research skills 5% Team cohesion 10% Responsibility 10% Compliance with corporate rules and procedures 5% AGILE PERFORMANCE MEASUREMENT AT SBM TEAM ASSESSMENT
  27. 27. AGILE PERFORMANCE MEASUREMENT AT SBM SURVEY AT THE END OF EACH SPRINT Sprint Metrics 30% Participating in planning 25% Individual contribution to Sprint goals and team’s output to/commitment 25% Contributing to empirical process. 25% Focus on delivering quality work 25% TOTAL 100%
  28. 28. AGILE PERFORMANCE MEASUREMENT AT SBM INDIVIDUAL SCORE Weight Score (1-5) TOTAL TOTAL SCORE (5) Team Metrics 40% 3,700 1,480 Team Assessment 30% 3,485 1,046 Sprint Survey 30% 3,250 0,975 Participating in planning 4,00 1,000UP Individual contribution to Sprint goals and team’s output 2,00 0,750DOWN Contributing to empirical process. 2,00 0,500DOWN Focus on delivering quality work 4,00 1,000UP TOTAL 100% 3,501