A good number for a birthday but not for a metric!

A good number for a birthday but not for a metric!

The world can be complex; it is comprised of a myriad of processes each with their own slice of complexity. We all fear being sucked into that whirlpool of complexity, as evidenced by the laundry list of bestselling books that purport to provide the tools we need to take control of our personal and professional worlds. In the process improvement world, we have adopted models to ameliorate that complexity. Models, whether statistical or flowcharts, are used to represent order and to characterize the software development and maintenance processes most of us use or interface with on a day-to-day basis. A team’s productivity or velocity represents a model of the team’s behavior.  The model synthesizes all of the team’s capabilities and project attributes into how much output a team can generally deliver. Detailed models of productivity show how output varies depending on a range of variables such as complexity, size of project or schedule compression. Many models use non-linear regression lines to show how productivity or velocity varies. Representing productivity (or productivity or cost per unit of work or any other significant metric) a very simplified model of the real world that has little predictive power.

For example, single number representations do not reflect the changes in economies and diseconomies of scale seen projects of differing sizes. For example as projects get larger they tend to require larger teams which require more meetings and time to communicate reducing the overall productivity on the project. Smaller projects tend to exhibit higher levels of productivity for this reason. This is one of the reasons behind the idea of time-boxing projects seen since 1990’s (Champy and Hammer, Reengineering the Corporation, 1993 revised 2006). Data shows that as projects get larger productivity tends to follow a curve that falls faster at the beginning and then tends to flatten. Representing productivity as a single number would misrepresent the performance at both ends of the spectrum (small and large projects).

Models are abstractions of the real world and they are important so that we can understand, even approximately, how the real world works and how people in the real world react to changes of inputs. When abstractions become of abstractions it is easy to miss-read what the model means and to make incorrect decisions. As an example a single industry or team productivity average is used to plan a project then chances are low that plan will be accurate.  The lack of accuracy in a plan or estimate can lead teams into poor behaviors such as shortcutting testing or even talking to users yielding less value than they would want. A single number removes all of the nuances that relate to size and complexity or to team size and productivity. A model of productivity represented by a single number can border on uselessness and can also be harmful. A better model would be represented as a curve that varies based on project size and other attributes.

 

Advertisements