The Deming Way to Measuring Software Developer Productivity

Many software folks pay lip service to Bill Deming and his work. Few if any pay any attention to the implications. Let’s break the mould and dive into how the great man himself might look at software developer productivity (a subset of collaborative knowledge worker productivity more generally).

This isn’t just a thought experiment; it’s an invitation to rethink our existing assumptions and beliefs about productivity.

Why Traditional Metrics Don’t Cut It

If Deming could peer over our shoulders, he’d likely be aghast at our fascination with shallow metrics. Lines of code? Bugs fixed? DORA? SPACE? These are mere surface ripples that fail to delve into the depths of what truly constitutes productivity. Deming was a systems thinker, and he’d want us to look at productivity as an outcome of a complex system. It’s influenced by everything from the quality of management practices to the clarity of project goals, and yes, even the standard of the coffee in the break room.

Aside 1

Let’s not get too hung up on staff productivity and the measurement thereof.

Deming’s First Theorem states that:

“Nobody gives a hoot about profits.”

A corollary might be:

“Nobody gives a hoot about software developer productivity.”

Which, drawing on my 50+ years experience in the software business, rings exceedingly true. Despite all the regular hoo-hah about productivity. Cf. Argyris and espoused theory vs theory in action.

Aside 2

While we’ve on the subject of measurment, let’s recognise that measuments will only be valid and useful when specified by and collected by the folks doing the work. I’ve written about this before, for example in my 2012 post “Just Two Questions“.

Aside 3

Let’s remember that the system (the way the work works) accounts for some 95% of an individual’s productivity. Leaving just 5% that’s a consequence of an individual’s talents and efforts. This makes it clear that attempting to measure individual productivity, or even team productivity, is a fool’s errand of the first order.

Here’s the Deming Approach

So, how would the statistician go about this? Hold on to your hats, because we’re diving into an eight-step process that marries statistical rigour with psychology and humanistic care.

1. Understand the System

First things first, get to grips with the holistic view. Understand how a line of code travels from a developer’s brain to the customer. This involves understanding the various elements in the software development lifecycle and how they interact.

2. Define Objectives

Random metrics serve no one. Deming would urge us to link productivity measurements to broader business objectives. What’s the end game? Is it faster delivery, better quality, or increased customer satisfaction?

3. Involve the Team

The people on the ‘shop floor’ have valuable insights. Deming would never neglect the developer’s perspective on productivity. Involving them in defining productivity criteria ensures buy-in and better data accuracy.

4. Data Collection

We’ve got our objectives and our team’s perspective. Now it’s time to roll up our sleeves and get to work on data collection. But this is Deming we’re talking about, so not just any data will do. The focus will be on meaningful metrics that align with the objectives we’ve set.

5. PDSA Cycle

Implementing the Plan-Do-Study-Act (PDSA) cycle, any changes aimed at boosting productivity would be introduced in small, incremental phases. These phases would be assessed for their effectiveness before either full implementation or going back to the drawing board.

6. Feedback Loops

You’ve made changes; now listen. Feedback from developers, who can offer a real-time response to whether the changes are working, is invaluable.

7. Regular Reviews

Productivity isn’t a static entity. It’s a dynamic component of a system that’s always in flux. Regular reviews help recalibrate the process and ensure it aligns with the ever-changing landscape.

8. Leadership Commitment

Finally, if you think increasing productivity is solely a developer’s job, think again. The leadership team must be as committed to this journey as the developers themselves. It’s a collective journey toward a common goal.

The Long Game

Deming never promised a quick fix. His was a long-term commitment to systemic improvement. But the fruits of such a commitment aren’t just increased productivity. You’re looking at more value for your business and greater satisfaction for both your developers and customers. So, let’s stop paying lip service to Deming and start actually embracing his philosophy. After all, a system is only as good as the assumptions and beliefs that shape it.