A Simple, Definitive Metric of Software Development Productivity

Developer productivity is made of two components: 1-) the speed at which work is done when work is getting done, and 2-) the amount of time that is lost when anything stands in the way of getting work done, or more specifically, of getting "value-added" work done.

The most common mistake in measuring software developer productivity is the failure to take both components into consideration.

Productivity is what's left over when you subtract the amount of time lost to non-value-added work from the total time spent working. If you only ever measure your pace when doing value-added work, the results will be a massive over-statement of developer productivity.

Complicating matters further, developers' natural pride in workmanship can make classifying work as "non-value-added" a difficult task. Without an environment that is entirely supportive of transparency, learning, and improving, truthful measurements of productivity are just not possible. Far too many personal preservation mechanisms will get in the way.

The hard, cold truth about developer productivity is that a truthful measure of productivity on a typical software development team is in the 10% to 30% range. Getting a clear picture of the reality of software productivity on your team remains a necessary effort - even in light of the difficulties of undertaking it.

Non-Value-Added Work

Pride in workmanship is what keeps most developers engaged in the work, but it's a double-edged sword. Peter Drucker's famous quote applies: "There is nothing so useless as doing efficiently that which should not be done at all".

We have to come to terms with non-value-added work. We have to consent to it. Non-value-added work simply is.

If we're willing to consent to the reality of non-value-added work, then we'll be open to seeing it. Seeing it is the first step toward measuring productivity meaningfully, which is the first step to developing an action plan for restoring productivity.

If you can get comfortable with the reality of non-value-added work, then you can get comfortable with using its proper name: waste.

Here are a few things that we do that are waste - regardless of any pride we might have in the hard work and perseverance involved:

• Teasing apart code to understand how it works, especially when this effort is repeated whenever a team member confronts that code
• Performing deep and complex setups of data in an external system (or systems) in order to prove that changes to a local system are correct
• Hiding distributed systems behind interfaces that pretend that remote objects are local objects
• Failing to create transparency in objects' interfaces as to their underlying latency, or network and storage protocols
• Creating development infrastructure, tools, or automation that is only readily-understood by people who have had extensive experience with them
• Failing to properly codify or tag tests so that knowledge of which tests to run and how to run them when a change is made is obvious
• Designing tests who's failures aren't definitive proof of either defacto functional errors or mistakes in setting up or operating up the test environment
• Failing to recognize excess tests as coupling problems that obstruct needed design changes
• Designing tests with either excess specificity, test granularity, or penetration into adjacent modules
• Underestimating the destructiveness of ambiguity in any code or any other development artifact in general
• amongst many other things that can appear as hard-won effort

In short, any work you do that isn't directly related to adding desired capabilities to the system is waste. Any work that you do to resolve obstructions to getting your work done is waste - even if that work improves the overall quality of the system. The reason is simple: obstructions are mistakes that you haven't yet learned not to make.

Some design challenges are due to unforeseen changes in direction in technology or business. As long as you can make those changes without also having to deal with negligent design choices and expediencies of the past, then you're still adding value. The moment you have to deal with obstructions to the work, you're incurring waste - no matter how attached you might be with the designs, mechanisms, and even human organizations and processes that underly the obstructions.

There may always be some waste in the work, but the presence of it doesn't excuse an aversion to seeing it for what it is, accepting that it's there, consenting to its presence, and developing the means to aggressively and progressively eliminate it.

Measuring Productivity

Here's how to get a clear, honest look at software development productivity:

The moment you're forced to divert to non-value-added work, write down the time. The moment you're back on track doing value-added work, write down that time. At the end of the day, add up all the non-value-added time and subtract it from your total work time.

Your work time shouldn't include things that aren't time spent on developer activities unless they're directly related to dealing with an obstruction. For example, a lunch break isn't non-value-added time. However, a walk to the break room to blow off the steam building up from dealing with frustrating design mistakes is counted as non-value-added time. A standup meeting isn't non-value-added time, but a meeting to address an obstruction or to resolve an ambiguity is non-value-added time.

You'll inevitably come across grey areas where some time spent isn't easily classified as non-value-added or value-added. This is especially-true of explicit improvement efforts. Discussing these grey areas with your team and coming to some conclusion is a valuable part of the larger improvement journey that you're on.

Make all the factors feeding your considerations explicit and come to the best decision you can for the circumstances you face. And most of all, understand that different circumstances might lead to different conclusions. Make these differences explicit as well. Open dialog and flexibility is an absolute must, but so is rigor. Keep an open mind (an open heart is also helpful), but be vigilant against allowing a discussion to become a zoo.

If you do a daily standup or status meeting, or have an activity stream app like Campfire, an IRC channel, or even email, report on your productivity every day. Even if you're the only person on your team undertaking the exercise (note: this isn't really sustainable), you can report your productivity.

The goal is to be transparent about the truth of your software development productivity. Once the truth is laid out for all to see, it has a chance of affecting the moment-by-moment decisions that you and your teammates make that continue to confound progress.

Next Steps

Wherever there's waste, there's an accumulation of excess complexity that encourages even more waste. The goal is to fix the design problems that cause it, and to restore productivity to sensible levels. And ultimately, to fix the processes that encourages the waste that exacerbates the design problems that take up long-term residence.

We have to remain utterly unattached to the efforts we invest in solving problems that should not have existed in the first place. If we're not capable of adopting such a disposition, we're incapable of harvesting enough learning about counter-productivity to restore productivity.

If you can measure your productivity truthfully, then you can work with your team to collectively improve the situation, and to continue to improve it.

The start of an improvement effort begins with recognition of a problem and a pathology. Being able to make measurements of the problem is essential to recognizing the problem and also to monitor progress. By developing the ability to recognize waste, you've also given yourself some basic tools to monitor your progress. Measurement might be a bit depressing at first, but it also becomes encouraging as you make progress.

The anatomy of an improvement effort is the subject for another day, but suffice to say that what you're trying to create is a Learning Culture. Doing this isn't a quick-fix, but undertaking it will yield some benefit immediately, and continue to yield a constant stream of value along the way.

---

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Kaizen: "Relentless", Rather than "Continuous"

"Kaizen" is usually translated from Japanese to English as "Continuous Improvement". It loses its power in the translation.

"Continuous" is perfectly reasonable and correct, but it doesn't really convey Kaizen as the underpinnings of a way doing work. Kaizen is certainly continuous, but it's continuous as a side effect. More importantly than being continuous, Kaizen is relentless.

"Continuous Improvement" can become a flaccid thing - yet another empty corporate mission. At its worst, it reinforces workers' cynicism about cultural initiatives that don't really make work or outcomes any better. "Continuous Improvement" is passive. It's even apologetic and deferential. "Relentless Improvement" is active. It's even fair to say that Kaizen is aggressive.

Often, the real problems robbing an organization of its productivity are the smaller, pervasive problems that are finely-woven into the fabric of the way that work is done and conceptualized. When you solve problems that are inherent in the DNA of the work (and consequently, the organization), you'll likely free up more resources than you might have imagined. A Kaizen culture understands that microscopic, pervasive rot causes a kind of osteoporosis in the bones of the work that can't be seen without actively hunting it with fine optics, or until the bones start to break.

A Kaizen culture doesn't wait for problems to show up. It looks for problems. It's imbued with an awareness that negligible problems often aren't negligible at all - especially when they're pathological and pervasive. It knows that pathological and pervasive problems are often charged with the greatest potential for destruction. Kaizen is literally "looking for trouble", knowing that if it doesn't, trouble will find it. It challenges its belief that these negligible problems are not worth effort or attention. It grounds its exploration in meaningful but practicable, and accessible measurements, rather than in methodology mysticism. In progressively learning what measurements are interesting and practical, it learns to ask better questions.

When a Kaizen culture doesn't see problems, it wonders first whether its vision needs improvement, and sets out to sharpen its eyes rather than rest on its laurels and dull its senses. The adage, "If it ain't broke, don't fix it", is a fallacy. Waiting for problems to come to you means that you're dancing to their tune. The downward, entropic cycle of fire-fighting and decay isn't transformed into a greater capacity to keep moving forward without constantly losing ground.

In the end, "Continuous Improvement" is useful because it's a standard term. But when it's time to actually do Kaizen, "Relentless Improvement" sets more realistic expectations about how it achieves pervasive dominance over pervasive problems.

---

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com