Measuring Team Productivity

Convener: Ted Bardusch

35+ people attended

Topics covered:

Some teams much more productive than others – how do you know if all teams are living up to potential

• There is no silver bullet (as Fred Brooks wrote)
• Points don't work
• Differing debt and complexity make teams appear different that really aren't
• Whatever measure you invent can be gamed (developers do invent algorithms for a living)
• Why measure? 
• Measuring can be used for differential rewards
• Measuring can be abused when poorly understood
• Repeat: there is no silver bullet

Any good tips to make up a notion of value & track that

• Turned into a discussion of the first point
• There is a book on value, name was not captured, if the person who put that forward can add it that would be great
• Another book on Product Flow was recommended.  Some readers of the book found it highly repetitive after the Poppendieck books

What is productivity?   Quantity vs quality.   What does "Done" mean

• Done was briefly discussed.  Obviously "done" is not code-complete but when is it?
• Done was mostly thought of as when systems are providing or exceeding the value predicted by the product owner

Measuring teams that don't want to be measured

• many teams have a level of distrust based on time-card type measurement systems
• Most measurement systems can be gamed, resulting typically in short-term measurement gain and long term real pain

Topics not covered but posted:

• Don't do it!
• Measure Cycle time, Quality, Cyclometric Complexity
• Peer Review
• $
• Self organizing teams are supposed to hold each other  responsible.  It doesn't work, they cover for each other
• Avoiding the tendency & pitfalls of comparing teams
• Teams defined their own idea of productivity
• Measurint productivity on highly constrained / shared resources
• Why measure productivity
• Realizing and measuring a projects touted value