These days wherever you move you hear a lot of buzz words. People manager, are you? There’s one for you. Oh, you are more into leading projects, I understand. Try with hyper-productivity. You will definitely hear it here and there. Well, maybe it is a way to go?
For the sake of this discussion let’s consider there are no well-grounded doubts about figures standing behind the idea. Let’s consider hyper-productivity was never called bullshit. Let’s consider you can make your team hyper-productive, whatever this might mean. But before we come to this I have a question.
Why, the hell, won’t you make your team just productive in the first place?
The problem I see over and over again isn’t with teams which are performing very well and struggle to improve even more. The problem is an average team can hardly be called productive. Just productive.
We keep wasting our time because we organize our work poorly. We face way more interruptions than it is necessary. We don’t really care about making our estimates a bit better to avoid panic (and counterproductive) rescue actions at the end of the project. We hire, and then keep, people who don’t give a damn about learning. We promote wrong people who are living proofs of Peter’s principle. We keep making stupid lists of examples just to prove the point which everyone agrees with from the very beginning (well, that might have been wrong example).
No, hyper-productivity isn’t an issue. If we were able to make average team just productive we’d see hyper-productivity paradise. If you want to optimize system performance you don’t make champions even better – you work to get average majority to another level.
So don’t tell me how to make my distributed team hyper-productive. Give me an advice how to make a bit more fun out of our mundane tasks or help me improve my recruitment skills instead.
Hyper-productivity shouldn’t really bother us, even if it isn’t just a buzz word.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
6 comments… add one
Couldn’t agree more.
For me this is the same argument as ‘effectiveness before efficiency’. Before we start trying to get better at what we do, we need to actually do it first. Its the same argument as premature optimisation at the technical level.
It’s like trying to make fancy meal even better while you have trouble making a simple sandwich. Yet somehow in cooking business no one tells you to go into advanced lessons until you master basic ones. In software business it is pretty common though.
Pawel,
I agree, we shouldn’t let hyper-productivity bother us. It is, however, a great hyper-marketing term. It grabs your attention and can be used as a vision, something to aspire to. I’m with you, get productive first and then we can talk about hyper-productivity. (I understand this to be a 400% or better improvement in velocity, which I’m sure takes a great blend of technical practices and teamwork, meaning that you need people who are very engaged, technically skilled types who love to learn and grow, are collaborative, effective communicators…)
Dave,
Actually I’m neither convinced we should sell the term hyper-productivity to our teams nor I believe most of teams would buy it.
I believe we can deliver the message without marketing gibberish, especially that we (mostly) talk with engineers. And if they have problems with understanding what simple productivity means, selling them hyper-productivity won’t help anyway.
By the way: if 400% velocity improvement is what you measure it is also what you’re going to get but I wouldn’t say the productivity has changed that much. I don’t have hard data at hand but we’re running a new project which includes new technology. I can already see our productivity increased a few times. How? Well, the simple answer is we got fluent with new technology. Note: we didn’t have to learn each other, we didn’t have communication issues and we didn’t struggle with product design or architecture. Should I call us hyper-productive? Well, I didn’t think so.
Pawel,
I agree, and I wasn’t clear. I didn’t intend to sell hyper-productivity itself to the teams, but merely point out that the concept exists, and that there is a highly productive state to aspire to. We’ve talked about “high-performing teams” in my organization vs. hyper-productivity.
I’d like to get clarification on your point about velocity improvement. If you are improving your velocity (assuming that your user stories are relatively sized and that sizing remains constant), then you must be working better as a team and/or adopting technical practices that help you to improve. A velocity improvement should be an indicator, although I personally like to understand exactly what teams are doing and how they are going about it as my final “measure.”
For example, we’ve certainly seen productivity benefits from having automated unit tests, particularly when it came time to refactor. Refactoring has been performed with confidence and in far less time than if we were relying on manual testing to verify that the refactoring had not changed the behavior of the code. And refactoring enables us to add new features quicker because we don’t have to invest as much effort refactoring to keep our code maintainable — and our velocity reflects this. (This may come down to the standards and the definition of done that you have, as you can improve velocity in the short term by ignoring the fact that you need to support the software in the long term.)
When you say that you got fluent with new technology, it sounds like you were on a learning curve, and as people got familiar with the technology they naturally became more productive. (Is this correct?) If so, that’s to be expected, but as you move forward, wouldn’t you also need to continue to look towards other means such as teamwork and technical practices to improve?
You make a good point. If you’re starting from a less than productive situation, you have a greater chance of achieving a 400% improvement than another team that was productive in the first place, yet still improved. I didn’t invent the term, but perhaps it should be “hyper-improvement.”
Dave,
I don’t try to discourage anyone to use, what we call, best engineering practices. Of course I share the opinion that most of them help teams to improve productivity, especially when people get fluency using them.
However that’s what I consider as a normal behavior of healthy team of professionals. We want to get better. We want to keep our code maintainable. We want to deliver good results possibly fast.
On the other hand, and this is basically my point, lack of refactoring or loose approach to unit testing seldom is the most important issue. Most of the time basics are screwed. Either communication doesn’t work or there’s no real collaboration between people or leader doesn’t lead or product owner doesn’t own a product etc.
These are basically things we should look for in the first place when thinking about productivity improvements. If they are all fine which, and I’ll keep repeating this, is a rare case we can move further to practices which build “hyper-productivity.”
And even then I’d be far from big words like that. Continuous improvement should be the goal of every team after all. If you improve long enough or you have pretty low starting point you should soon hit 400% mark.
In given example of course the reason why productivity increased so much was we got fluent with the technology. And yes, that was expected. Of course now we have others issues to deal with, luckily teamwork isn’t one of them, and hopefully we’ll get even more productive. But would it be super-duper-productivity? Well, whatever… Who cares after all?