Much has been talked about how productivity is different in software industry, the challenges in not only measuring and interpreting but in defining productivity itself. Productivity is just about efficiency – the ratio of the output to input. Input is typically the human effort involved. Though it appears easy to get this through logs done by team members, there are challenges in getting the actual efforts spent due to variety of reasons. Besides, the team members do a variety of tasks which may not be directly related to the work on hand and the challenge is in dealing with efforts on such work. On measuring output the issue is in determining what is to be considered as output – Lines of Code, Function Points, Story Points, variants of these, Business Value delivered etc. Martin Fowler has discussed in detail and concludes that productivity cannot be measured.
Is productivity still relevant?
Productivity is defined and measured at different levels – individual, team and organization. It is measured to compare the efficiency in the production of software with respect to other organizations in the industry, across teams and between individuals. This efficiency determines the cost and the profitability at project and organization level. Hence, productivity is a critical input to budgeting of internal product development projects and estimation of costs for bids in fixed pricing model projects for customers (of course, the underlying big assumption is that the software requirements have been sized correctly!). At an organization level it is about profitability. However, in order to analyze organization’s profitability and improve the same, there is a need to define and measure productivity at a lifecycle level. At the same time going to individual level productivity measurement can impact team work and collaboration amongst team members leading to in the worst case pockets of high efficiency and overall degradation in productivity. Agile methodology appears to be not/less focused on productivity. The focus there is on delivering value incrementally in every release with product quality. However, the velocity with which value is delivered assuming a stable team exists is the focus – this comes with its own similar challenges. Treating software work as a flow is another possibility so that methodologies like Kanban and Theory of Constraints can be applied effectively. For some lifecycle steps, it is very straight forward to apply Kanban approach and measure productivity as well as other throughput measures like inventory and cycle time. Steve McConnell author of ‘Code Complete’ – the popular book on best practices in software production – has discussed various aspects of productivity in his talk. He has proposed a scorecard approach for productivity in which the involvement of stakeholders and their perspective on what is business value is considered. Other alternatives are to break down the work in the software industry into its lifecycle steps and deal with productivity in each step. Organizations and teams do have their own variants in this regards as per context.
Thus, organizations and teams need to identify why they want to measure productivity given their context (nature of work done, project lifecycles, execution methodologies, management policies and organization culture), define it appropriately along with other alternative metrics to productivity, measure them to the extent required, analyze the measured performance carefully to draw insights and use the same!
Dr. Selvaraj Vadivelu 
One thought on “Software Productivity – Is it still relevant?”