“Working hard, or hardly working?”
It’s an age-old jibe around the office – often answered with a polite laugh, or a nod and grimace.
It’s a harmless (and mildly cringy) joke. But it harkens back to a deeply entrenched belief that at work: you need to be productive at all times.
Google ‘productivity’, and you’ll be hit by millions of results – whether it’s self-help books, TED talks, or productivity apps – like ‘how to be more productive at work’, ‘how to maximize productivity’, and ‘how to make the most of your workday’.
But while those productivity solutions are often marketed as new, the concept of productivity isn’t.
In fact, psychologist Oliver Burkeman noted that we only really turned our attention to productivity during industrialization, when we needed to maximize resources and minimize wastage.
On the one hand, productivity is a good thing – ensuring we spend our work time meeting our goals. On the other, it can creep nefariously into workplaces to mask unsustainable practices that can quickly become counterproductive.
Let’s take a look at the productivity trap – what it is, what it means for your workforce, and how you can avoid the common pitfalls before it’s too late.
Developer velocity and the productivity trap
Before we dive into the productivity trap in more detail, let’s quickly establish what we mean when we say, ‘developer velocity’.
Developer velocity refers to the rate at which a team of developers is able to complete a certain amount of work, typically measured in story points or tasks. It’s a metric used to measure the efficiency and productivity of a development team.
But it’s important to note that developer velocity is not a perfect measure, and should be used in the proper context. More on that later.
For now, the simplest explanation is that developer velocity can be a useful tool for planning and estimating project timelines, but it shouldn’t be overemphasized as the sole measure of success.
The goal should be to work as efficiently as possible without placing unrealistic pressure on the team to constantly meet velocity targets.
Dodging the pitfalls of productivity
A problem arises for developers when productivity itself is set as the primary goal, meaning that anything less than peak efficiency is considered a failure. This in turn can lead to additional stress and, eventually, burnout – something that, according to one study, 83% of developers suffer from.
But productivity is too helpful to ignore completely. On a basic level, it forms a good barometer of a team’s efficiency and helps the team set appropriate goals and priorities.
So it’s important to toe the line carefully when it comes to how you use productivity in a development setting.
For instance, if it’s used as a short-term measure of current activity, then developer productivity can be a useful gauge.
But the trap lies in the fact that this often isn’t the case – in fact, when productivity is misused as a measure, it can detrimentally impact developer workflow, and have a counterproductive effect on their output.
In his book Four Thousand Weeks: Time Management for Mortals, Burkeman noted that “becoming more efficient just makes you more rushed, and trying to clear the decks simply makes them fill up again faster”.
It’s like trying to empty a bathtub of water with a cup while leaving the tap on – no matter how hard you try, the water will keep on rising.
Like the idiom “a good deed never goes unpunished”, when your primary goal is productivity, you’ll always find that finishing one task means another one is always lurking around the next corner.
The same goes for developers:
- Finish more tasks…
- … This sets an unsustainable precedent that their developer velocity will always be this fast…
- …So new work mounts up and the cycle repeats.
So this is the biggest pitfall to avoid when it comes to productivity. It’s a useful measure only if the work pace is kept constant.
Hyperfocusing on productivity and using it as a motivator to create more work means that in the end, nobody can ever be productive.
Instead, they’ll be dashing to keep up with their previous pace, all while the tasks keep getting heaped on them.
And the bathtub will keep on filling up.
A real-life productivity riddle
Picture the scene. You’re in charge of developers in the middle of a project. You’ve decided on the agile methodology to get the work done. But you also need to decide how to spread out the work and hit your deadlines and go-to-market window.
Let’s say you’ve set your first sprint goal of 60 story points based on developer velocity from previous work. But you notice that after three weeks of the sprint, your team’s actual velocity is closer to 45 story points, meaning they’re underperforming on their previous velocity.
What do you do?
So you have two options:
- Option A: tell the team to pull their socks up, knuckle down, and be more productive to keep up the pace of work – they’re missing the KPIs, after all!
- Option B: you look into other possibilities for the slower work pace
If you chose Option A, you may be in for a rude awakening. If the pace of work is clearly unsustainable, demanding that your team works harder may create more problems while achieving less. In this case, measuring developer velocity has worked against your team, causing stress, burnout, and a much lower likelihood of quality work.
If you chose Option B, you’re keeping your options open. You may find that this project pace is slower because it’s more complex, or you’re down a team member, or the processes for one project may not necessarily apply to the other. In this case, measuring developer velocity has worked for your team, helping to identify and solve problems, and reduce stress levels to lead to better work.
Finding the right balance between velocity and efficiency
Long story short, developer velocity can be a great measure of productivity, but it needs to be exercised with caution.
Why?
Because velocity is never a perfect metric, and developers need to apply it in the proper context.
Ultimately, it’s about achieving the right balance between developer velocity and efficiency. This will make sure that the right levels of productivity are achieved, without overworking your dev team and causing more harm than good.
Interested in learning more about striking that balance?
Download our whitepaper to discover how you can harness the power of developer velocity while ensuring your team’s well-being and overall productivity.
