Our product and engineering teams at FishingBooker work in six-week cycles. This fixed cadence serves to give us an internal sense of urgency, works as a soft limit to keep projects from ballooning, and provides a regular interval to decide what we’re working on.
We’ve tried scrum, quarterly OKR cycles, and we’ve tried no plan at all. All of these models were cool to try but fell apart within weeks or months.
Problems with quarterly OKRs for product
We’ve found that this simple truth applies: the further out you plan, the more inaccurate your commitments become.
- Our team was spending too much time planning upfront. Planning is necessary, but great teams want to be building. So much time spent planning means the job is less fun and hands-on.
- No matter how hard we tried, our plans were mostly fiction. As a result, the team either felt scared to commit (because we were overambitious) or de-motivated (because the goal was too easy to hit).
- People across the company soon realized that our plans aren’t reliable, so the product team risked losing credibility.
- Our plans felt like artificial constraints that we were constantly having to re-adjust, while never being able to actually break free.
Now, instead of using a quarterly cycle, we keep our roadmaps prioritized in three timeframes: this cycle, next, or later. That’s it.
The general concept of cycles extends to all departments, whether in six weeks (product and engineering) or 12 weeks (how long an OKR cycle lasts). It provides us with a regular rhythm, much needed flexibility, and a large enough timeframe to accomplish big things six weeks at a time.
Accountability matters
The scope of each six-week cycle project is specific, and people are held accountable for their completion. We don’t expect perfection. Missing goals happens. But teams should feel good about what they’re committing to – that it’s achievable and something they’d feel proud about delivering in six weeks. Missing goals shouldn’t be painless.
They’re not delivery cycles
Our planning and commitment timeframe is six weeks, but not everything we decide to work on has to take that long. One project might be designed, built, and released in just a couple of weeks, while others will span across a couple of cycles. Engineers are expected to release product the whole way through a cycle. And sometimes you’ll hit your main goal in week three or four. That’s all totally fine. Six weeks is simply our planning and commitment timeline. It’s our structure to help give our team the right level of predictability and foresight.
For sizing, we’ve introduced Big Batch and Small Batch work. In Big Batch, we work on a single feature that’s likely to take the entire six weeks. In Small Batch, we work on stuff that won’t take longer than two weeks at the most. So we can get more like 3–5 smaller things done in a single cycle.
We will typically spend the first week of a cycle cooling down, dealing with various backlogs or bug smashes, and figuring out what we should tackle next.
We’re currently naming the cycles after fish species. Previous names include Sailfish, Kingfish, Ladyfish, Mahi Mahi, and Zander.