Metrics for the efficiency of a software development process

Fundamental metrics in software development

In this article we assume that a software development process is good, if it maximises the following three fundamental metrics:

• Speed – a faster development will deliver more services and richer products to customers. If the team is in the prototyping phase and does not have customers yet, it could also benefit from higher speed. If the team is faster it will make more experiments and more iterations and in this way raise its chances of finding a good product-market fit. All in all the speed of development is crucial for the innovation readiness of the team and hence also of the company.
• Quality – delivering software fast is not sufficient, it needs to be of good quality. Good quality will have different meaning for different projects and domains.
• Team Happiness – software development team consists of people. A good development process will contribute towards maximising the people’s happiness.

Alignment between customer needs and the development team is of course also crucial for success, however we consider it out-of-scope in this writing.

Can software development teams improve among all fundamental metrics? Or one should compromise and make trade-offs? In Perelik Soft we firmly believe that teams and companies can improve on all three metrics simultaneously. No trade-offs.

At the same time:

If you cannot measure it, you cannot improve it.

Peter Drucker, William Thomson

So how can we measure how good a software development process is in regards to Speed, Quality and Team Happiness?

We have already presented some measurable metrics for the quality of a software engineering process and in this blog post, we will expand further the list.
Albeit not entirely thorough, the presented metrics can be used to self-assess and gain some insights in the current state of the development process in a given team.

Measurable metrics for the efficiency of a software development process

In the following table one can see 11 easy to measure metrics, which could shed some light on the current development process. When a metric is a series of data points (e.g days a code review stays open) one can take the median. Median is better than average because average can be too heavily influenced by outliers.

Conclusion

This brief article presents 11 concrete metrics for the assessment of a software development process. Every metric can be measured easily, so one can gain some real number representation for the somewhat vague concepts Speed, Quality and Team Happiness.

It could be interesting to assess the metrics in regular time intervals, in order to understand better the effects of changes introduced to the process.

Further it is important to note that looking on metrics in isolation might not yield sensible results (it can be even damaging). One needs a holistic approach.