One of the most ubiquitous conversations that occurs in organizations is about productivity, although the word itself is rarely used. The conversation might be about the need to get more value from the software development budget or the ability to deliver more new functions with the same staff. The concepts of labor, capital, material and total factor productivity are an undercurrent in these conversations even if the word productivity is not directly mentioned. There are several possible reasons why the word productivity is not used in polite software development company. Those reasons range from a mistaken belief that productivity concerns are reserved for blue collar occupations to the complexity of defining productivity in software development and maintenance environments. Complexity is often the most pernicious reason that keeps productivity in the background during strategic conversations that affect products and jobs. However, with the exception of total factor productivity, the mathematical computation of labor, material or capital productivity appears to be very straight forward.
The equation for productivity equals output divided by input. The simplicity of the equation obscures the complexity hidden in the term productivity.
Unwinding the complex concepts of measuring productivity begins with understanding and making three critical decisions that define the output side of the equation.
The first step in unwinding the hidden complexity of measuring productivity is deciding which output process or value chain we will measure. Deciding what to measure begins with defining the decisions the measurement will support. Douglas W. Hubbard in How to Measure Anything wrote that we care about measurements for one of three reasons. Most organizations measure productivity so they can make specific, key decisions. Understanding that decision is critical to deciding which output of a process needs to be measured. For example, to establish whether improving the processing power available to software developers in the form of new laptops would increase productivity requires measuring the output of software development (functional software). Measuring the organization’s whole value chain would be overkill and far less effective. Another example is a checking account that a retail bank delivers to a customer. The software required to account for checking transactions is part of the product and does not represent the full value chain needed to deliver a checking account. Organizations need to decide whether they are measuring the productivity of the overall product or a component that is part of the value chain. The software is often not the ultimate product or service delivered to an organization’s ultimate customer (most organizations are not software product companies like Microsoft or SAP). Defining the decision or the question that measurement supports is critical to deciding which output to measure.
The second required decision is the definition of a unit of measure. For a wooden pencil manufacturer, pencils would be their output unit of measure. However, what if the pencil manufacturer produced two models? To measure the combined productivity of both products, they would need some mechanism to normalize the output of both models. Software development has a similar problem, which the industry has solved using function metrics (for example, IFPUG Function Points) and a wide variety of physical (lines of code) and relative (story points) measures. In software development and maintenance, the functional software presents the whole process needed to deliver functionality. The whole process often includes: training, documentation, support, DevOps and more that some people might not recognize as part of the steps needed to deliver value from the software. Developing an agreement on a universal output measure for software is often fractious. The lack of agreed upon output measure can generate all sorts of bad practices, such as equating productivity to a number of hours worked.
The third decision in unwinding the complexity of the output side of the productivity equation is deciding which units of measure to count. Using the pencil manufacturer to illustrate this conundrum, if a mistake in manufacturing yields a pencil without the lead (the graphite in the middle for those that have never seen a wooden pencil), should that pencil counted when computing productivity. The simple answer is no. The only units that count for productivity are those that are complete and fit for use. In Agile software development, complete and fit for use would mean that functionality meets the definition of done and have been successfully demo’ed. The defective or unusable product is not counted regardless of whether you are counting pencils, function points or work orders. This puts the onus on organizations to define and enforce the definition of done.
Deciding why you are measuring productivity is the first step in unwinding the complexity of output side of the equation because it defines scope. Understanding the scope of what need to be measured provides guidance on which unit of measure will be useful to support why you are measuring productivity. Understanding the unit of measure establishes boundaries for defining what the words, “done”, “complete”, and “fit for use” mean so that we don’t count output that is not useful. Short cutting any of these decisions will reduce or erase the usefulness of measuring productivity.
Next Metrics: The Complexities of Productivity – Inputs