It’s an issue that plagues every project manager – productivity.
How do I get my team to work better/smarter/more effectively?
I was pondering this question recently and while we are all aware that there has been plenty of theories, formal studies and processes available, I wondered if there was something that can sum it up for me – something like a formula that I can apply. ( I don’t know about you but I like things to boil down to just a few simple steps that I can easily follow or absorb to carry around in my back pocket).
As it turns out, there is – I mean there is, beyond the normal “how many widgets did we deliver against our baseline/target”.
Agile software’s approach to measuring productivity – velocity
Agile software development has a some really nice ways of creating a predictable gauge of progress. By time boxing each sprint we can work out how much a team can get done in that time. The best way to do that is not by how many “stories” or “features” can they produce in that time, but instead, they use a points system.
By time boxing each sprint we can work out how much a team can get done in that time. The best way to do that is not by how many “stories” or “features” can they produce in that time, but instead, they use a points system.
The best way to do that is not by how many “stories” or “features” can they produce in that time, but instead, they use a points system.
They allocate points to each story or part of a feature they want to achieve. Once achieved they can claim those points as the measure of achievement within each time box. This then becomes the team’s “velocity“. That is, how many points can be achieved in each sprint’s time-box. You keep one variable constant – time. Brilliant.
The main issue in determining productivity is in measuring the size of the things you want to deliver. The allocation of points is a great way of doing that even if it can be a bit arbitrary. Agile get over this arbitrariness by using the whole team to estimate the points. At least then they aren’t getting just one person’s viewpoint. And there is a sense of being part of the estimate by ALL members of the team – it’s like “we set the scale, so we can’t complain”.
Agile get over this arbitrariness by using the whole team collectively to estimate the points. At least then they aren’t getting just one person’s viewpoint. And there is a sense of being part of the estimate by ALL members of the team – it’s like “we set the scale, so we can’t complain”.
Of course, as the project progresses and the more sprints completed, the more accurate the velocity becomes.
The main thing is that agile projects don’t necessarily use this measure as a measure of productivity – but more as a baseline prediction tool to measure what can be achieved over time – say to the next release of their software deliverable.
The quality dimension
The other point is that if we start fixating about velocity, we can forget one very important aspect of delivery – quality.
There is little point in our team being proud
It is an important human, team and project trait. We tend to get fixated on what we measure.
If we are to be judged by say our velocity, we may let other measures drop.
This is a classic assembly line problem. Measure how many widgets are coming off the assembly line, then we forget that each widget might end up being rubbish. All because we are being measured by velocity.
We need quality.
Most team leaders realise this – and it is an important aspect of every project and every team. No point pumping out junk – you can, but the team won’t last long! Customers won’t want to buy what you are producing, or at the very least, your product owner will not be happy.
Equally, letting the quality dimension only drive the equation, you may very well achieve nothing (Oh that sounds like perfectionism!)
So, what is productivity?
That’s great – but what about other projects / other teams? No two teams are the same, no two circumstances are identical. We are not all agile project teams, in fact, a lot of teams produce something and are not a project – like client-support teams, or call center teams – they produce help or sales and not “things” as such.
Generically speaking then, productivity can be measured by the volume of quality things being produced per unit of effort in a set amount of time.
The issue we need to consider is the negative impact of inefficiencies.
As we all realise, if we have to be constantly stopping to check where we are at we slow down. So process efficiency is a big consideration in determining our team’s productivity.
So we need to keep process to a minimum, otherwise, we negatively impact productivity. Be constantly looking out for ways to improve efficiency especially as teams grow and layers of bureaucracy creep in.
A general formula
So is there a formula or some type of model we can use to conveniently talk about productivity?