Sprint Driven Development
Agile talks about doing work in sprints, but it never felt like a “sprint” to me. It just feels like we’re chopping work up arbitrarily into 2-week chunks. When I run, sprinting is a top-speed run focused on getting to a clear destination as soon as possible. I need a long rest before I can sprint again. The agile version of this doesn’t seem like it has much in common.
What if sprints were more like running?
A long time ago I was working for a startup. I pitched the CEO an idea to let me rewrite the entire component. I wrote up a 1-pager, convinced everyone in the company (it was a small company) that it was the right thing, and then I went offline for 1-2 months. I barely communicated. I worked extremely hard, and at the end I had a very big contribution that made a large impact.
I wish agile sprints were like that.
A team can be in one of two states:
- Sprint Mode
- Planning Mode
Sprint mode is a period of maximum productivity. You know what you’re doing and how to get there. The only unknown is how long it will take. If you want a team to be very productive, keep them in sprint mode as much as possible.
Planning mode is when the team isn’t 100% sure where they’re going. They’re feeling it out. They might pivot in a new direction at any point. Put simply, they’re not sprinting.
If a team is in sprint mode, let them stay there for as long as you can manage. If you have 2-week iterations, cancel sprint planning until the productivity starts to cool. Don’t fix what’s not broke. Momentum is hard to build, but easy to maintain. Maybe think about dialing back things like code reviews and other processes that get in the way of delivering quickly.
Honestly, it’s not easy to get a team into sprint mode. It doesn’t happen often in practice. Sprint mode is a rare state where the team
- Knows where they’re going
- Knows how to get there
- Has everything they need to get there, except time
It takes a lot of planning and alignment work to get there.
The goal of planning mode is to get the team into sprint mode. Don’t attempt to exit planning mode until you’re sure you can (and should) stay in sprint mode for a long time. Estimate how long it long it’ll take to get to sprint mode. Hold yourself accountable. If you sprint in the wrong direction, you’ll end up in the wrong place.
Cool! How do I get there?
It seems like sprint mode is good, but clearly there’s trade-offs. How do I put this into practice?
The elephant in the room is that top manament typically wants visibility into what’s going on. You can’t usually go dark for 1-2 months like I did, that’s a thing that really only happens in startups. The answer is a combination of two things:
- Communication
- Trust
That’s what it always is. It doesn’t go away simply because you’re in sprint mode.
If you’re a manager or team lead, you need to communicate clearly to your management what’s happening. Communicate your philosophy and expectations. Tell them before the team goes into sprint mode that they’ll be heads-down for a while. In my experience, this is a suprisingly easy conversation to have. VPs love it when you tell them “we’re in execution mode right now and we don’t need any direction”. But there’s also a trust component; if you go dark without pre-briefing them what’s happening, you may find yourself on a much shorter leash in the future.
If you’re an engineer or other individual contributor, you can’t dictate what the team does, but you can often negotiate a different operating mode for yourself with your manager. Tell them about planning vs sprint mode. Tell them what your plans are. Let them know that you want to go into sprint mode. You may have to settle for daily updates delivered early before your brain gets going, or late when you’re tired. Just make sure you can do it in a way that’s not disruptive to your flow.
Also, figure out how to track the amount of rework or wasted work, as an indicator that you may need to come out of sprint mode for a time. Communicating these upwards can help buy you the trust needed to stay in sprint mode for longer.
In summary, be agile. Adjust your process to fit the team. People over process.