The document discusses measuring productivity in agile projects. It introduces a complexity rule for normalizing functional complexity to measure productivity per backlog item. The complexity rule defines business complexity independently of technical aspects, effort, risk, or team experience. Continuous improvement is emphasized through root cause analysis of outliers to iteratively refine processes and tackle performance issues. Metrics should not be used to control people or evaluate individuals, but rather to enable learning across teams.

1. Learning Shot :
"How to Measure Performance in Agile Projects"
São Paulo, SP, Brazil
March 28, 2015

2. Is it possible to
measure Productivity
in Agile Projects ?

3. Today I'm going to share
some insights on how to
make more money
by squeezing your
team to the edge
and how to get good
productivity metrics
to nicely report your
performance to
Corporate

5. Yes, its
possible !

7. It
IS NOT
about
People

8. it's all
about how
people's
work is
being
affected

9. Why ?

11. Enable continuous improvement

12. no process,
tools &
methods
at all
bad
process,
tools &
methods
unappropriated
use of all of
them (lack of
skill)
most common causes of unproductivity

14. How do we know
where our
benchmarks are ?
Are we improving ?
Are our teams able
to learn from each
other ?

15. Metrics ?
Productivity ?

16. What we are doing

17. Productivity per backlog item

18. Root Cause Analysis on Outliers
RCA → poor
code quality
RCA → stories
not ready
RCA → lack of
knowledge
RCA → huge
manual effort
RCA → c'est la
vie

19. Continuously and
tirelessly tackle the
most harmful
performance
offenders by fixing
or adapting the
process in order to
solve the root
causes.

20. K
A
I
Z
E
N
K
A
I
Z
E
N
Continuous Improvement
RCA → poor
code quality
RCA → stories
not ready
Code Standards
Tech Dojos
Code Review
Change Workflow
Review DoR
DoR Checklist

21. New Baseline : new boundaries, new challenges

22. RCA on Outliers - Again !
RCA → many
browsers
RCA → lack of
knowledge
RCA → huge
manual effort

23. normalized functional complexity
Productivity
effort to deliver it

24. How we are doing it

25. Normalizing
Functional Complexity

26. Complexity vs Risk vs Effort vs Experience

27. The model measures business complexity, not effort.
Once evaluated as "small", the complexity of a given requirement will be always “small”,
regardless the team experience and/or eventual risks that may affect its deveopment
Normalized Functional Complexity

28. complexity rule
● A model to determine software functional complexity
● unique, objective and easy to apply
● universal business and software engineering vocabulary
● decoupled from technical aspects
● standard and stable enough to be immutable over time and among
different teams
● enables normalizing points estimating regardless effort, risk and
team experience
● defines a common language among the whole team

29. Complexity Rule

30. Complexi'tyRule(examples)
for the detailed version, please go to:
https://docs.google.com/a/ciandt.com/spreadsheet/ccc?key=0ApLLTqlWeEv6dGEwQzd0NWRYd2RwT0VrdTRzdGxnOXc#gid=24

31. + →
complexity rule
(XS, S, M, L, XL)
Complexity Assessment of Functional Scope

32. Effort
logging
development
code review
agile rituals
tests
bug fixing
tech grooming

33. Productivity per backlog item

34. +26 %
Proven effectiveness

35. final thoughts

36. Possible groups:
- business context
- technology
- type of solution
- client
- what else ?
the pitfalls of comparison

37. Do not compare teams
instead
Enable continuous improvement
and coach them to take
the most of it!

38. do not use it to control people
do not use it to evaluate
individual performance
do not expose reputation
do not mess
with trust !

39. ● scope governance
● estimating & planning support ( calibration )
● #noestimates
some (future) benefits

41. Contact info
Fernando Ostanelli
ostanelli@ciandt.com
www.ciandt.com
www.ciandt.com/u/ostanelli
G+ : https://plus.google.com/+FernandoOstanelli/posts
Linkedin: br.linkedin.com/in/ostanelli

42. To learn more…
Article: Measure productivity in Agile before is too late!
Part 1: http://www.ciandt.com/card/guidance-for-measuring-enterprise-agile-productiviity
Part 2: http://www.ciandt.com/card/measure-productivity-in-agile-before-its-too-late
Part 3: http://www.ciandt.com/card/measure-productivity-in-agile-before-its-too-late-part-three
CI&T Complexity Rule
https://docs.google.com/a/ciandt.com/spreadsheet/ccc?key=0ApLLTqlWeEv6dGEwQzd0NWRYd2R
wT0VrdTRzdGxnOXc#gid=24

43. THANK YOU!

44. The world greatest digital garage