I recently gave a talk at the Enterprise IT Strategy Forum about maximising software development productivity. As shown in the photo below, despite reading through my slides numerous times, I clearly forgot to proof read the opening one…oops! Typos aside, it was all good fun and led to many interesting conversations and connections afterwards. If you missed it, this post summarises the chat.

Let’s Talk Dirty….Productivity!

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, productivity 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 cliched, 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 (to use Spotify parlance — “we need to cross the river” versus “build a bridge”).

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!

My answer to pretty much all probelms — and probably the reason I’m not a doctor… 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. Jeff Bezos famously talked about “two pizza teams”, which depends somewhat on the size of the pizza and how hungry people are, but is generally understood to mean about eight people. The optimum team size is probably 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

Experimentation may sound a bit sinister, but 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.

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.

AND FINALLY…

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.

Let us know in the comments if there’s anything you’d add for maximsing software development productivity