Not quite a Google bus

Not quite a Google bus

Labor, raw material, and capital productivity are easy concepts to understand.  For example, labor productivity is the ratio of the products delivered per unit of effort.  Increasing the efficiency of labor will either increase the amount of product delivered or reduce the amount of labor needed.  Raw material or capital productivity follow the same pattern. The issue is that while labor, raw materials, and capital explain a lot of the variation in productivity, they do not explain it all. And in software product development other factors often contribute significantly to productivity improvement. Total factor productivity (TFP) is not a simple ratio of output to input, but rather is a measure that captures everything that is not captured as labor, capital or material productivity. Factors included in total factor productivity include attributes such as changes in general knowledge, the use of particular organizational structures, management techniques, or returns on scale. The components in TFP are often the sources of productivity changes in software development. 

Total factor productivity seeks to account for all of the inputs used to create a product leaving a residual impact on productivity that isn’t directly traceable to inputs.  Conceptually I find it easier to consider residual as the effect of non-direct inputs. The formula typically to calculate TFP, the Solow residual, is:

Solow residual

Y = Total Output

A = Total Factor Productivity

K = Capital Input

L = Labor Input

(The superscripts are the percentage contribution of capital and labor to productivity).

Calculating TFP is like removing parts of a picture to identify and appreciate what remains. Very, very, very few software development and maintenance organizations take the time to calculate TFP, but everyone involved in managing software development or actively involved in making and assessing change must understand TFP conceptually and the factors that it represents. The factors that comprise TFP are often very effective levers for changing software development and maintenance productivity. Several of factors that contribute to TFP include technological change, general improvements in social well-being, changes in management approaches, and reallocating resources from low productivity endeavors.   Often we can measure the impacts of the changes in these factors in the other types of productivity indirectly.

Technological change.   Most of us have lived through the period governed by Moore’s Law, and even if we did not personally get access to new, faster processor every year we were impacted by the increase of processing power.  Networks became faster and we can find new ideas to solve problems on the internet, which leads to more and more innovation in how work is done, therefore, increasing productivity. Over the years, many in the software measurement field have noted a constant upward drift attributed to more efficient programming languages.  For example, the venerable coding language COBOL, developed in 1959 has continued to evolve (IBM’s current version is COBOL for x/OS ).  Each version made the language more powerful than the version before it. Technological change is a major contributor to productivity improvement in software development and maintenance.

General improvements in social well-being.   These types of changes include factors such as political stability, transportation infrastructure or general improvements in a country or area’s educational system.  Several organizations I talk with regularly source work in the Ukraine.  During the height of the recently political problems, they saw a significant drop in both amount and quality of functionality delivered.  The same people were working on code and everyone was at work, however, the reduction social well-being disrupted productivity. At an organizational level, companies often work hard to improve the social well-being of their employees and families. Google’s buses to move employees in and out of the core of San Francisco is a reflection of this the need to improve productivity through increased social well-being.

Changes in management approaches.  Why does Scrum typically lead to higher productivity?  The humans on teams are not generally improved nor is the capital or raw materials; however the change in management approach embodied in Scrum provides a basis for higher performance and increased productivity. For example, embracing Scrum as a management structure allows team members to make decisions faster which improves the efficiency of the team.

Reallocating resources from low productivity endeavors. Business Process Management (BPM) and Business Process Reengineering (BPR) are fields that improve work processes.  They represent a field of operations research that optimizes processes by identifying what an organization does efficiently.  Reducing low productivity activities allows organizations to spend money, effort and other resources on delivering the products and services they are efficient at delivering.  This reallocation is one the reasons continuous process improvement is powerful.

TFP measures the impact of all of these factors and others.  Unfortunately measuring by subtraction is far less straightforward than just measuring labor productivity and pretending we have covered all bases. In software development, TFP represents many of the levers that organizations have to influence productivity. However, labor and capital productivity are often used as proxies to measure the impact of these changes.  While the path from a change in management structure may not be direct, we can at least see the ripples caused by the change in other more straightforward measures.  Interpreting the impact of indirect changes requires more careful analysis and often more explanation.

Next: Productivity Gone Wild