During the last couple of months, I had the privilege of chatting with 30+ Directors, VPs, and Technical Program Managers (TPMs) from companies I admire like Apple, Amazon, Cisco, Docker, Microsoft, and others.
At the same time, I also keep an eye on Twitter to get exposure to interesting thoughts and trends.
Since I've been immersed in these two worlds for a while, I started noticing an interesting pattern. Most Directors, VPs, and TPMs are expanding their Continuous Integration and Continuous Delivery (CI/CD) initiatives, but they still care a lot about having fixed-date milestones in their roadmap.
On the other hand, folks on Twitter seem to be doubling down on continuous delivery but avoiding fixed-date milestones. I'm sure this is just another example of Twitter being a poor platform for discourse. Whoever shouts the loudest usually gets the most attention.
Nonetheless, I think it's worth exploring whether or not fixed-date milestones make sense in a world of sprints, kanban-like workflows, and continuous delivery.
Why sprints are good
The idea behind a sprint is simple:
- Choose an arbitrary amount of time. Usually that's 2-3 weeks.
- Estimate how many work items your team can execute during that period.
- Those work items should compound into something you can demo at the end of the sprint, and get feedback from stakeholders.
- After you commit to the work and start a sprint, new work that pops-up is added to a backlog, not to the current sprint.
The good thing about a sprint isn't so much that your team will have something to demo at the end of those 2 weeks. Actually, if your team achieves this by cutting corners, sooner or later you'll have to pay the price for the technical debt they've accumulated over time. You'll see your lead time, the time a customer files an issue until the issue gets fixed, increasing as you move faster and faster.
Sprints are good because they are an effective way to visualize and put a limit on the amount of Work in Progress (WIP) for a team. And if you've read Accelerate, you know that visualizing and limiting WIP is a good predictor of high-performing teams.
It doesn't really matter if you have a Kanban board, post-it notes, or a list of Github issues. If you're doing sprints, you probably have a way to visualize the tasks you're working on during the sprint.
When you're working on smaller engineering teams, sprints are great. You have visibility into what your team is doing, everyone is working towards that demo, and you have a clear idea of what to work on next.
But sprints also have their challenges, specially as your company grows or the support team gets understaffed. In both of these situations, your engineering team needs to be highly responsive and can't just wave their hands and say they'll look into that issue in 2-3 weeks.
Why milestones are important
Fixed-date milestones are a great way to manage and decrease risk by forcing everyone to sync, and integrate their work at a specific point in time. This happens a lot in the hardware industry.
Imagine someone at Motorola is running an initiative to put Motorola on the map again. They're shipping Flippy, the next-gen
flip phone foldable.
Now, if you want a successful launch, you'll probably try to have your phone in the shelves of Best Buy during Black Friday. If that's the case, you already have a couple of fixed-date milestones ahead of you:
- Order all components in March,
- So you can have them assembled by June,
- So you can deliver the phone to retailers by September,
- So retailers have everything ready for Black Friday.
Fixed-date milestones are all about reducing risk. Retailers impose a fixed date to manage risk on their side, and in turn you create a couple of milestones for your contractors to reduce risk for yourself. This is useful for hardware and software companies alike.
When companies are still small, you only track a few external milestones like a conference or deliverables from contractors.
Over time your team grows and communication becomes harder. Even if your tech stack is loosely coupled, you'll end up in situations where you'll have one team depending on the work of others.
A fixed-date milestone, is a good way to explicitly track agreements between teams. That way, teams can make progress independently, and synchronize when they hit the milestone.
Sure, milestones have their challenges too. If one team is supposed to have something ready, and that milestone ends up slipping, it will affect other teams depending on it.
So when you have milestones you should actively monitor progress during execution and avoid last-minute surprises.
Sprints vs milestones. Different tools for different problems
When we frame it this way, we can see that sprints and milestones address different problems. Sprints try to create sanity during the development cycle by agreeing upfront on what is going to be done, doing it without interruption for a short amount of time, and then getting feedback from stakeholders.
Milestones try to reduce risk by creating points of explicit synchronization.
Sure, you can abuse both sprints or milestones, and create a culture where processes or dates matter more than shipping products people love. But if you see that happening, dig deeper and you'll probably notice dysfunctional leadership, not so much broken tools.