I'm a big fan of simple and lightweight processes to build product. An amazing team should rely more on communication than a rigid process (like Scrum) to get things done. It should be a flexible framework that focuses on communication, prioritization, and independence.
I believe the best place to start for any development team is the 6 week development cycle.
Basecamp, Intercom, and Buffer are just a few of the well-known companies using the 6 week cycle. Intuitively, six weeks seems like the ideal length for a development cycle. It's long enough to get something meaningful done, and short enough to plan with some accuracy.
The 6 week cycle is focused on execution. At the beginning of the cycle, the team commits to what they will achieve in the next 6 weeks. It could be part of a massive project, a couple of big features, or many small optimizations.
At the end of the 6 week cycle, the team has one to two weeks of "cooldown". This is an opportunity for the team leaders to plan the future and realign on priorities. The rest of the team can use this time to refactor, work on infrastructure, or take on a side project.
If you're thinking about starting the 6 week cycle, I recommend starting with this:
- Kick-off – The team discusses the upcoming work and what they will commit to for the cycle. Share with stakeholders and the other teams what you are committing to.
- Weekly Planning (Every week) – Have a quick chat about the upcoming week. Make sure to discuss any dependencies or concerns.
- Checkpoint (Week 3) – Schedule a team meeting to discuss the progress. It's OK to adjust your commitments at this stage. Make sure to communicate it!
- End the cycle – Wrap up the cycle, the goal is to start the next cycle with a clean slate.
- Retrospective – Review and discuss the previous retrospective to come up with action items for the next cycle.
- Cooldown – A 1-2 week break between product work to plan, fix bugs, refactor, and other tasks.
A few other tips:
- Buffer suggests the team should have something demoable by week 4. In my opinion, this is dependant on the size of projects you are running and how quickly you can prototype. The focus should be on having something deliverable ASAP.
- Basecamp recommends Friday social and mini-retros. It's an opportunity for the team to catch-up and discuss the cycle. In the above approach, I've used the half-way checkpoint instead.
- Some companies (Basecamp) use the 6 week cycle to limit the size of projects, while others (Intercom) are OK with projects spanning many cycles. It's up to you and your organization's risk threshold.
- Bugs and crisises will come up during the cycle. Make sure to agree as a team how you will handle any issues. Basecamp suggests pushing all non-critical bugs to the cooldown period.
- This is a cycle not a sprint. A 2 week sprint is exhausting, imagine how a 6 week sprint would feel. This is not meant as a burst of energy, but a sustainable approach to building product.
- Almost always, your plans will change during the cycle. That's OK!
- Protect your team from distractions.
- The cycle is not a release plan. The team should continuously deploy features or experiments throughout the cycle.
Interested in learning more? Here are some articles written about the 6 week development cycle: