Software development ironically might be one of the most human things to manage. Productivity is mostly tied to intangible resources such as knowledge/experience and the motivation of developers. And the outcomes aren’t as straightforward to measure as in sales or manufacturing.
First thoughts:
– writing more code =/= writing good/great code
– engineers tend to evaluate their personal productivity by measuring how much solitary “work” they’ve done – like writing their code undisturbed, it doesn’t matter to them if the code is actually useful
In a recent paper “The SPACE of Developer Productivity” (2021) – Nicole Forsgreen proposed an idea of a holistic framework for measuring developer productivity.
S – Satisfaction and well-being – self-explanatory
P – Performance – business outcomes; also quality (code and service)
A – Activity – the volume of development, design, and operations
C – Communication and collaboration – documentation, work reviews, and network
E – Efficiency and flow – efficiency of project management, perceived “flow” state, time measures like value-added time (eg. time not spent setting up the development environment)
It can be grouped further into 3 areas – like Jellyfish identifies
“Business alignment – Performance (being the most important one)
People management – Satisfaction, Communication, and Collaboration
Engineering execution – Activity, Efficiency, Communication and collaboration”
These measures can be used on an individual level, team level and global level.
What must be added, measuring productivity is not an easy feat and can be tackled wrongly. Metrics selected can be counterproductive or irrelevant.
Examples would be measuring lines of code – that incentivizes bloated code. Measuring scrum story points –can be artificially inflated. Measuring commits count or time spent working just by itself, is even worse. That doesn’t mean these metrics can’t be used elsewhere, just that they aren’t that strongly correlated with productivity. It’s important to notice, that what is necessary, is to combine, maybe even hedge individual metrics to gain a bigger picture.
Performance is the most important part of developer productivity as it entails the why of the development efforts – to bring business outcomes. Yet it might be the hardest to measure, especially if the end-product is used by humans, not machines where you can say “this cut our operational costs by 5%”.
Other factor, is that performance is relatively hard to apply to individuals – it’s harder to tie individual contribution to such an upgrade.
Further reading:
- The SPACE of Developer Productivity – https://queue.acm.org/detail.cfm?id=3454124
- GitHub – measuring enterprise developer productivity – https://github.blog/2021-03-10-measuring-enterprise-developer-productivity/
- Can You Really Measure Individual Developer Productivity? https://blog.pragmaticengineer.com/can-you-measure-developer-productivity/
- Jellyfish – What is SPACE framework? https://jellyfish.co/blog/what-is-the-space-framework/
- The ecstasy and agony of measuring productivity for Software Engineering & Development – https://www.getclockwise.com/blog/measure-productivity-engineering-and-development