It’s very reasonable to ask how a development team can improve; it’s not reasonable to ask how it can go faster. Most senior managers want their teams to improve, and there’s nothing wrong with that; the team members themselves usually want to do things better, too. But occasionally I come across someone who wants their development team to go faster, and that’s rarely a good thing.

The problem with demanding greater speed from a team is that “better” is really about delivering more value, not about delivering more features. When we look for things that slow down a team’s raw speed we see things like time spent in meetings, time spent writing tests, even speed of typing. Cowboy coders, who hussle code out the door regardless of quality, score well; careful coders, who write maintainable code that can be built on over time, score poorly. We ignore code quality and the consequences are more bugs, more dependencies on particular individuals, and in general a codebase that makes feature delivery slower.

Seeking greater speed ultimately drives the speed towards zero. It’s much like a jockey who beats his horse to make it go faster, and beats it more when that doesn’t produce the desired results. Eventually the horse collapses, the jockey still in the saddle, beating it and beating it, and watching the other riders gallop past, wondering what’s wrong with his horse.

“Better” is about value, not speed. That means a strong focus on the quality of the requirements going into the team. It means continuous engagement between the team and whoever decides what “success” looks like. That in turn means an embedded product owner or product manager, and it means some kind of mechanism to get rapid feedback from the end users. Then there’s the need to be able to respond quickly to that feedback. And of course it all needs clarity on what success means—how to recognise and measure value, and know when you’ve achieved it and can move onto the next most valuable thing.