Effective agile metrics to trace productivity, quality and improvement.

1. EFFECTIVE
AGILE METRICS
Agile Turkey Summit 2015
Cüneyt Gül
SBM

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. 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. 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. 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. 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. 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. 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. FEEDBACK LOOP
COLLECT - Collect data
MEASURE - Do your analysis
REACT - Apply Adjustments
REPEAT - Continuously analysis and adjust

10. SOURCE SYSTEMS
FOR TRENDS AND DATA
* From Agile Metrics In Action, Christopher W. H. Davis

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. 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. 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. PROJECT TRACK SYSTEMS
Burn down Cumulative flow
Velocity

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)

16. TRENDS FROM SOURCE CONTROL

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. 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. 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. 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. 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. 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. 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

24. AGILE PERFORMANCE
MEASUREMENT AT SBM
TEAM METRICS (KPIs)
TEAM ASSESSMENTS
SURVEYS AT THE END OF
EACH SPRINT

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. 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. 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. 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

29. QUESTIONS
&
THANK YOU