EFFECTIVE AGILE METRICS
Agile Turkey Summit 2015
Cüneyt Gül
SBM
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
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
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
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
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.
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
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
FEEDBACK LOOP COLLECT - Collect data MEASURE - Do your analysis REACT - Apply Adjustments REPEAT - Continuously analysis and adjust
SOURCE SYSTEMS FOR TRENDS AND DATA
* From Agile Metrics In Action, Christopher W. H. Davis
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 .....
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 ?
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 )
PROJECT TRACK SYSTEMS
Burn down Cumulative flow
Velocity
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)
TRENDS FROM SOURCE CONTROL
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
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
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
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. CO
NTI
NU
OU
S
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.
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
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
AGILE PERFORMANCE MEASUREMENT AT SBM
TEAM METRICS (KPIs)
TEAM ASSESSMENTS
SURVEYS AT THE END OF EACH SPRINT
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
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
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%
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,000 UP Individual contribution to Sprint goals and team’s output 2,00 0,750 DOWN
Contributing to empirical process. 2,00 0,500 DOWN
Focus on delivering quality work 4,00 1,000 UP
TOTAL 100% 3,501
QUESTIONS &
THANK YOU