It's a question I've heard a lot over the years, from a lot of frustrated managers and stakeholders. They can't get past it.
"Seriously, why are my engineering teams so much slower than they used to be?"
I get it. The frustration is palpable. A team that used to cook along now appears to be stuck in molasses. They get slower and slower, and it's confounding to everyone waiting for the next major feature to be delivered, or even just looking at a burndown chart. It can be confounding and frustrating to the team, too.
But I'm here to tell you, the frustration is likely misplaced: Teams slowing down as they mature and grow is not only normal, it may be better.
After looking at the velocity of dozens -- possibly hundreds -- of teams over the years, and how it changes over time, here are the common threads among the "formerly fast" teams.
They finished the fast part#
Everything moves a lot faster when you're a cowboy, riding breathlessly across green fields. You can shift direction on a whim, you can explore, you can strike out in bold new directions. That's fast, and it's easy. But getting from something to something good takes a lot more time and effort.
No matter what the project, from software engineering to home renovations, smart people know that the first 80% is the easy part, and the work goes quickly. But the last part -- the sorting out and polishing -- takes much, much longer.
They're swimming in a bigger pond now#
In the early days, engineering efforts usually start off as an experiment, or perhaps a small team carefully curating their own little walled garden. But as the team matures and the codebase grows, it inevitably becomes part of a larger ecosystem. There are APIs to integrate and platforms to build on. Which means you are now part of an ecosystem. Ecosystems introduce interdependencies, and interdependencies slow things down.
When you were a young team you could do pretty much whatever you wanted, so long as you got your homework done. Now you have to play nice with others. You have to get permissions. You have to stop to read the instructions. These things take time.
They were good. Let's throw a party.#
And finally, success leads to slowdowns. Only successful programs live to grow and mature, which means as programs grow and are seen by more people, more people have thoughts.
Or, to put it another way, early on a team may only have to satisfy an idea, while later they have to satisfy a whole org chart. As more eyes are on the team, more demands are made.
The team may be cranking along like the same high-efficiency machine they've always been, but more demands means more backlog. While the throughput may not change, the time to satisfy any one request may get a lot longer, which makes each individual stakeholder think the team is now slower than they used to be. They're not, they just may be slower to get to your request.
This is still a good team.#
The irony is that all those factors are positive outcomes of a successful, maturing team. They are also, notably, largely out of control of the people on the team.
But still, most discussions around improving velocity start from the perspective of "how do we get these teams to go faster." And the short answer to that is that you don't. Assuming the team is continuing to work well together, then any perceived slowdown is probably not true -- they're likely working as fast as they ever did -- and also ignoring how the team and program has matured and works in a different context now.
So if you're a team getting hit with questions about why you've slowed down, what can you do?
Stay tuned for part two!
Published