Measuring delivery team productivity, can be a divisive topic. Especially for the people being ‘measured’.
A case in point is the recent McKinsey article, which has touched a bit of a nerve in the developer community.
While tech leaders need to understand team productivity, it’s also important to acknowledge that their people, goals, and projects are unique. Be too scientific, too process-driven in assessing productivity, and we risk measuring the wrong thing, and reaching the wrong outcome.
As Albert Einstein once said: “not everything that counts can be counted and not everything that can be counted counts.”
It’s more than lines of code…
Software engineering has a long – and not very glorious – history of trying to measure productivity. Tell a team it’s being assessed on deployment frequency, and they’ll happily churn out code to production for you day and night. But does this get us any closer to the actual business value the project’s looking to deliver? Probably not.
The lines of code example, and today’s rather more scientific metrics, don’t always reflect the complexity of a project. Maybe the team is working on something brand new, pushing boundaries, finding solutions to intricate problems. In this case, they won’t be deploying to production five times a day. They’ll be experimenting, failing and starting again.
What’s stopping progress?
If you’ve got a smart, self-motivated team, I’ve always believed measurement should be about identifying what prevents engineering productivity.
As we’ve talked about before, a good place to start is at the high level: does everyone understand their mission? From here you drill down into what could stop your people being productive. Does the team have a healthy backlog that’s been planned and discussed with all stakeholders? Do individuals have the autonomy to choose what systems, tools and technologies they work with? Are they being held back by other departments, lack of access to infrastructure, limited budgets?
Ultimately, teams are rarely ‘unproductive’ without a reason. The point of this kind of analysis is to uncover the constraints it faces and address them. Then everyone’s empowered teams to do their best work.
Finding the flow
I’m a firm believer in giving teams the tools for success, then letting them get on with it, in their own way. But it also pays to check-in from time to time. For that, a burndown can be great indicator of a sprint or project progress.
Burndown charts (and there are many different ones) tell us a lot about workflow and how our teams are really working.
A steep incline above the benchmark, for instance, could highlight that the team’s bitten off more than it can chew – maybe it’s not breaking down its work effectively and needs to revisit the project plan. On the other hand, while being ahead of schedule may look good, it might be good. If things are progressing more quickly than expected, it’s possible the work isn’t being delivered to spec and teams are closing tickets having only delivered a small portion of what was asked. Either way, any deviation is cause for a closer look.
Burndown charts are great for visualising progress and are hugely useful for managing both workloads and expectations. They’re also great in keeping teams focused on the end goal. More than any of this though, they flag whether teams need support – without making things too complex.
Keep it simple
I’m not averse to measurement. It certainly serves a purpose. However, attempts to measure productivity 100% objectively or scientifically can be a bit hit and miss.
Software engineering isn’t a production line, and software engineers shouldn’t feel like they’re working in one. And just like counting lines of code didn’t work in the old days – and certainly didn’t inspire innovative thinking or problem solving – I’m not sure getting more granular with today’s metrics is the answer. It could get in the way of teams achieving the one measure that really counts…value to the business.
In our experience, it’s important to keep things simple, identify and eliminate the blockers at the very beginning of the project. Then trust your people to deliver. It works for us!
If you’d like to chat further about anything covered in this blog, just give us a shout.