Milyin Featured 3

Engineering Productivity – An Illusion

16th October 2023 | 5 Views

Info: This Creation is monetized via ads and affiliate links. We may earn from promoting certain products in our Creations, or when you engage with various Ad Units.

How was this Creation created: We are a completely AI-free platform, all Creations are checked to make sure content is original, human-written, and plagiarism free.

Toggle

Need to Measure

One reason is the old saying, “Time is money”. Organisations often feel that increasing productivity would mean effort savings and hence has direct impact on revenue earnings.

While other reasons includes objectives like tracking progress over time identifying and rewarding high performing individuals/teams plan resource allocation.

As more and more Projects are embracing the Agile delivery methodology, it is very important to nurture the culture of putting together highly motivated individuals into the Agile Teams/squads to fully realise the benefits of Agile methodology. However, I have seen that in the practical scenarios of dynamic operating environment of teams, organisations more often end up practicing hybrid Agile methods, where the Agile Teams/Squads are a mix of individuals with variety of experience and motivation levels. This necessitates the Project Leads to explore Tools & Techniques to measure and keep track of developer’s productivity. 

As they say – What gets measured gets done. Therefore, it’s important to track the right metrics to understand their overall efficiency.

Measure What Matters

If you’re using software development productivity metrics to evaluate developer performance, then you’re doing it wrong. For best results, tie them to business outcomes.

For example, if you are measuring “Lines of Code”, you are just focusing on quantity over quality, incentivizing developers to spend more time in expanding lines of code and ignoring the quality of work done by those who could achieve the same with less lines of code, hence less time.

Additional work hours could even reduce average productivity per hour. People who overwork may suffer burnout and clock negative productivity, characterized by an increase in errors and oversight.

Similarly, Measuring the numbers of user stories or story points delivered, is just asking developers to break down features into more stories or inflate their story point estimates.

Again, measuring the number of tickets/defects closed, can lead to people gaming the system by creating more tickets or, picking up the easy ones to fix to reflect the ticket volume closed.

If you explore more, you will find that there’s no single metric to measuring developer productivity. Your contract, Technology, Operating model/software delivery process, deployment methodology, team structure, development environment etc will impact how you measure team and individual performance. 

You can however build the right strategy and metrics for your team and individual developers to help them focus on the right tasks and meaningful results. 

The most effective measure for developer productivity could be a mix of measuring the work completed (in combination with the importance of the work i.e., MVP/working software in Agile terminology) and the savings on effort to do the work (of similar size/estimate) the quality of the work

Use metrics with a strong correlation with business outcomes (e.g., revenue) or, at a bare minimum business functions usability (e.g., feature). 

These metrics should address all output, including non-engineering work essential to the software delivery process (e.g., scoping, Planning, Design,  communicating with stakeholders etc).

Attributes of a good metric

A good measure/metric should have the following attributes:

  • Correlates productivity with revenue
  • Includes all type work output (including non-engineering work such as testing, documentation etc.)
  • Gaming-proof (i.e., should not be easily manipulated)
  • Objective/measurable and Independently verifiable
  • Software Language/Type agnostic
  • Comparable across different projects

Most organizations want to measure Engineering productivity because doing so effectively leads to more revenue. Therefore, every organisation has been striving to come-up with metrics which could effectively measure the same. However, what they don’t realise that the influencing factors typically are so high that if proper thought and research is not done to identify the right mix of metrics, the benefits of engineering productivity might seem to be an eluding mirage or, an illusion.

I believe that while this is a very critical element of success, has been neglected by most. With new technologies like ChatGPT coming up, the debate is now turning into a different direction altogether. The question now is “What should be considered as productive work?”

swarup biswas

@swarup-biswas

Following0
Followers0


You may also like

Leave a Reply