If you are in broadly understood context of Agile you eventually has had to hear about being hyperproductive. Sources reporting a few hundred, or even as much as more than a thousand, percent productivity improvement aren’t unusual. In fact, 200% improvement seems to be “guaranteed” by some.
That’s great! Good for them! They’re going to get hyperproductivity badge or something. Yay!
What Hyperproductivity Is
Let’s start with the basics though. What is this whole thing? When a team becomes hyperproductive? How much do they have to improve? Oh, and by the way, if a super-crappy team improves three times and guys that were already great only by 20% would that mean that hyperproductivity was reached by the former, the latter, or both?
The most common metric I hear about in the context of hyperproductivity is velocity. Actually, I consider using velocity to measure productivity evil or dumb. How much should my team improve? By the factor of three? Nothing easier. Oh, and by the way, we don’t use our estimation poker card worth 1 that often anymore.
Note: I don’t deny teams improve. I merely point that stating so purely on a basis of velocity improvement is naive at best. There are so many potential dysfunctions of such approach that I don’t even know where to start. How the scope of work is split into individual tasks? What is a distribution of point estimates? How has it changed over time? What do we understand as a task in the first place? How do we account for rework?
In other words without understanding a specific context mentioning hyperproductivity is meaningless. Just a marketing fad, which it might have been in the first place.
Efficiency As a Goal
Even if we agreed on a reasonable proxy for measuring productivity there’s a bigger problem ahead. We are not in a business of writing most code, delivering most features or achieving best velocity. If you think you are, go talk to your clients, but this time try to actually listen to them.
If you spend about 5 minutes looking for sources pointing how notorious software industry is in not building the right stuff you may change your mind. Is a half of the stuff we build utterly useless? How about two third? Oh, and by the way the rise of the methods that are literally aimed to avoid building things unless we know we’re going to need them tells a story as well.
So yeah, focus purely on productivity and you’re going to achieve your goal:
Processing waste more effectively is cheaper, neater, faster waste.
The most painful problem of software industry is not efficiency. If it was, we’d already be in haven, given how much easier it is to build a software app these days than it was a couple decades ago. The problem is we are building wrong stuff.
We may as well be efficient, but unless we are effective in the first place, i.e. doing the right thing, there’s no glory waiting for us.
How We Create Value
This brings me to the utter failure of pursuing hyperproductivity. Let’s (safely) assume that our goal is to deliver value to our clients. We do that by building stuff. Except the value almost never is clearly defined. In almost every case software development is a knowledge discovery process.
This has some serious consequences. If we go by this assumption we may take all the functional specifications with a tongue in a cheek. It’s just a sketch of a map and most of the time not even an accurate sketch. This also means that amount of artifacts, like code, features, etc., we produce is not nearly as important as figuring out where exactly the value is, which bits and pieces we should build and which should be ignored.
This happens when we discuss the features, look for solutions, research options, prototype, A/B test, change stuff back and forth to see what works. This happens when we don’t score on velocity or any other productivity metric.
But wait, to become hyperproductive we should rather avoid that…
That’s exactly why I don’t give a damn about hyperproductivity.
I use to say software development is a happiness industry. We thrive only as long as our clients are continuously happy. We don’t make them happy by delivering more stuff. We make them happy by delivering stuff that has value for them and their customers.