Dunelm

The word "productivity" has got a bad reputation in the software development world… and rightly so; poor understanding and appreciation of what's involved persists in many organisations.

But, it doesn't need to be a dirty word.

Productivity gains are not about cracking the whip, working harder, and burning out-they're about building the right things, in the right way, and minimising constraints. If we’re doing the former, at best, we’ll see a short term boost followed by a longer term decline and our best engineers waving goodbye as they head off to pastures new.

There are many approaches to improving productivity in a constructive way that benefit both the team and the wider business. They include cultural, technical, and operational concerns that with the right focus can deliver more value, more quickly and more safely.

TEAM HAPPINESS

It sounds a bit clichéd, but the happiness of the development team is by far the biggest influencer of productivity. This goes beyond the headline-grabbing beanbags, free coffees, and foosball tables. More important are the cultural considerations like psychological safety, a sense of belonging, ownership of services, and the empowerment to achieve outcomes through creative problem solving. Engineers are natural problem solvers, we should give them problems to solve, not solutions to implement.

Alongside this, we need to encourage appropriate flexibility of working hours and location, relax any dated dress code mandates and take the time to organise hack-events that foster innovation and the use of shiny technology.

CHOP IT UP!

Generally, as things get bigger, they get harder to manage, and teams become less productive. This is as true for problems as it is for teams and architecture. Smaller teams working on smaller increments in smaller contexts win the productivity game.

For problems, being able to slice them up into digestible pieces that can be prioritised according to value; de-risks development activity and ensures deliveries are quick and consistent. Within teams, communication and collaboration are key and these get exponentially more difficult with size. The optimum team size is somewhere between five and ten people and it’s important they’re cross–functional with minimal dependencies on others. With architecture, monoliths can be broken up into microservices and micro-frontends that promote reusability, reliability, and most of the other x-abilities!

EXPERIMENT

There’s no better way to understand what users of software really want, rather than what they say they want, than seeing what they actually do. If we’re not preceding all significant development work with an experiment, then we’re running the risk of building features that won’t be used and are reduced to bloat.

"“Productivity” no longer needs to be a word that results in groans and blank stares of disbelief; it can be something we rally around, buy into, and actively seek to improve"

Effective feature flag management also opens the door to the new kid on the continuous delivery “block”; progressive delivery (separating the release of software from the release of features). This de-risks the most dangerous aspect of software development, leading to less production downtime and therefore increasing productivity.

MEASURE WHAT MATTERS

Measuring engineering productivity is notoriously tricky and emotional. In many ways software development is more of an art than a science and how would we measure the productivity of Michelangelo? If we try measuring metrics like lines of code, story points, or number of commits, we’ll likely have an adverse effect on morale and productivity. Instead, a good starting point is to use the DevOps Research and Assessment (DORA) metrics, which were identified by a seven year program to understand what differentiates a high performing team.

The key DORA measures are deployment frequency, lead time for changes, mean time to recovery, and change failure rate. If we start measuring these as soon as possible in a product’s life and get them trending in the right direction, we can be sure of smaller increments, delivered faster and safer, and engineering productivity will trend upwards.

RE-USE

If we’re reinventing the wheel, we’re wasting engineering effort. Software development is expensive, so it’s vital that most things we build have the potential to be re-used elsewhere in the estate.

On the back-end, application programming interfaces (APIs) allow the functionality of an application to be used by other applications, these can be independent or stitched together and used in ways that weren’t originally foreseen.

On the front-end, a design system for standardising user-interface elements combined with a component library for the code that enables them can provide a centralised repository of reusable assets. These accelerate delivery of features but also allow for future application-wide changes and make it worthwhile to pursue often de-prioritised features like sensible validation and accessibility.

These approaches improve software development productivity in a way that also boosts morale, team cohesion and customer experience. “Productivity” no longer needs to be a word that results in groans and blank stares of disbelief; it can be something we rally around, buy into, and actively seek to improve. As smaller pieces of software get delivered quicker and safer, customers get more functionality, more reliably, and businesses can differentiate themselves in a meaningful way.