Our team just finished their most successful sprint to date. It's astonishing how positive and motivated everyone is for the sprint to come. 'A job well done, but far more to come' is the feeling in the camp. It's like motivation and desire just became way more contagious.
It's made me realise something important. It's something I've suspected for a long time but which I hadn't seen for myself. Speed matters for software teams. It matters because speed acts a signal of underlying team health. Shipping fast and achieving ambitions represents a team that trusts each other, understands the role each member plays, and feels comfortable with the human and technological systems around them. It's a sign of a happy team, and a happy team is a productive team.
Why Speed Matters
- The best way to learn to do something is by doing it lots of times. The faster you do it the faster you learn. That applies to writing code just as much as it applies to running effective sprint retros. Try stuff, get feedback, and try again. It's how you get better.
- When tasks stay on the backlog sprint after sprint, it leaves a bad taste in everyone's mouth. Progress feels like it's non-existent. People become reluctant to add new tasks and the environment becomes stale. Ideas, creativity and inventiveness - the things needed to build great products - don't thrive in stale environments.
- In the long run, teams that work quickly receive more opportunities. If you're known to move fast, more work is sent your way. This exposes you to different problems and tools, helping you to solve existing and future problems better and faster. It's a virtuous cycle in which you get better and better and faster and faster.
- Speed is like a magnet. As I mentioned, speed acts as a signal of underlying team health. A healthy team is an alive team, and people like life. Moving quickly makes people want to help you and talent want to join you. The faster you move the better you get, and the better you get the faster you can move.
How To Move Quickly
- Our team has grown significantly faster as we've spent more time together. We're a remote team, but after spending time in person, the dynamic totally shifted. Not only has each member grown more secure in their respective positions, but the interconnections between them have grown stronger. Bonding takes time, and I'm not sure there's a way to accelerate it, or if you'd even want to.
- Go slow now so that you can go fast later. It's easy to add a new feature to the front-end when you've taken the time to configure and understand the backend. It's easy to decide what to build when you've taken the time to understand the domain. Solid foundations provide the support needed to move fast.
- Put in your reps. The best way to learn anything is to do it lots of times. Speed is no different. Push yourself to go faster than you think you're capable of. There's no speed limit to growth.
This isn't to say that you should prioritise speed above everything else, but rather that it's worth considering speed in the decisions you make. Is this going to help us move faster? If not, is it worth the trade-off? How much learning are we missing out on by moving slowly?
There will be times where it's necessary to move slowly, and the best leaders are good at identifying those times. But as a general rule, prioritise speed.
p.s. Some of these are hunches and I'm trying to verify them in practice. That will probably take a few years and a few different teams, but I think it's worth noting these initial thoughts and observing how they change over time.