Misunderstandings on Productivity Measurements in IT
We get a lot of questions on measuring “productivity” within organisations in relation to Agile or Lean adoptions and today was no different than any other, the big productivity questions came in our direction again. This was the trigger for me to write down some things related to productivity measurements which I find valuable to share. First of all we need to distinguish between “Leading” and “Lagging” indicators on measurements about productivity.
- Leading = Before things are in production/used
- Lagging = After things are in production/used (for a while)
The most popular method of measuring productivity is measuring output which comes from our industrial past where the amount of output pretty much equals the factory’s true productivity. Below some examples of well known measurements used in knowledge work, IT related.
- Function points delivered - What about work that needs to be done that is/can not be counted in function points? Tackling technical debt for example, refactoring…
- Story points delivered - What about quick feedback? What about extending the DoD? Why wouldn’t we just increase our estimates on our backlog items?...
- Lines of code produced - No comments needed anymore I guess! Plain stupid, google around and you’ll figure this out yourself.
- Features delivered - What about variation of work needed to deliver features? Why wouldn’t we just focus on delivering easy, small features?...
All of the above mentioned measurements we could consider as “Leading” indicators in knowledge work and they have no linear impact on the organisation's productivity as such! They might provide some feeling on the final outcome but they do not guarantee it. All of the above are measuring output and a report from the Standish group on output delivered in IT projects shows us that 64% of the output delivered cannot really be considered as true productivity.
How many of your project deliverables are really used in the field? Do you know? Could it be that you are capitalizing your projects on leading indicators today? Does it feel right?
If leading indicators do not provide a true measurement on productivity then what does? The only true measurement for me is ROI or closest, actual measurement: EBITA (Earnings Before deduction of Interest, Tax and Amortisation). On organisational level EBITA is continuously measured and considered very important! But... organisations do not seem to find a way to get this measurement applied within their departments. Why? Lots of organisations are organised according the technical architecture or components of their products. Lots of organisations run projects on top of their (long or short lived) products. A single architectural component or a single project can never be measured towards EBITA by itself and as such organisations tend to leave this kind of measurement for what it was and focus on leading indicators as mentioned above. There is a solution to have EBITA measured within the organisation and thus lower level structures!
This means reorganising the entire organisation towards “Products” with a “Customer Centric” view as described in the LeSS Framework for scaling Business Agility. This kind of product oriented setup provides us the capability to measure EBITA on a product. A product is clearly defined and product outcome has a direct, linear impact on its ROI or the company's EBITA. If you are not able to measure true outcome in EBITA on your product, you might want to reconsider your organisational structures to change towards a bigger product definition. Impossible?
The LeSS framework is giving us the tools to organise 100’s of people on a single product. Bigger products provide us with the opportunity to apply a lagging indicator on productivity (EBITA), allowing us to evaluate the accuracy of leading indicators that might or might not be in place. As such giving us a true sense on productivity within parts of the organisation. Why are a lot of organisations not managing to get this applied? Change is hard, unaware of the possibilities or maybe it is Larman’s Laws of Organisational Behavior that plays out. Who knows?
Productivity is a highly overrated and misunderstood aspect within IT organisations worldwide, as most of the organisations apply leading indicators to get a sense of productivity which have no linear connection to true outcomes. Focusing on those will induce risk of playing around with the numbers with lots of unwanted side effects. Whether or not to measure productivity is an obsolete question, you want to measure and every company is measuring it in the end: EBITA. How to get this translated to parts of the organisation, that’s the true question to answer. Setting up customer-centric, big product oriented teams is one way to get there and I’m curious on other ways to get a lagging indicator on productivity in place. Looking forward to get to know other options and I can only hope this post might trigger you to start experimenting with lagging indicators and sharing your findings. Have a nice day.