I made the case in my Installing ramp meters on your product roadmap post that a simple way to improve planning and execution in an organization is to align on the same operating cadence.
For folks who try this, one obstacle becomes apparent: the Gregorian calendar. Seriously – have you ever thought about how bizarre it is that months have different number of days, and that we add in an extra day in February every 4 years for funsies?
In my experience, it’s useful to get ahead of this problem by setting up your operating cadence well ahead of time. This allows you to iron out the weird calendar issues – and ensure availability of the folks who need to attend – by getting meetings scheduled early.
I decided to use some of my rusty programming skills to create an interactive tool for visualizing an operating cadence. See the full version, or check out the embedded version below:
I built it with two fantastic tools: a visualization toolkit called D3 and an interactive data playground called Observable. You can “fork” the code and duplicate the underlying google sheet data source so that you can adapt it to your own needs.
I'm a fan of a multi-day in-person annual planning process because it allows the spaciousness for teams to build camaraderie, do some dreaming, dig into nuanced topics, and set broad strokes annual goals.
In my experience, a productive team can build and release (and learn from!) a solid version of just about any feature / project / etc. in 3 months. Thus, quarterly planning is a good cadence for reassessing your goals and initiatives, and redirecting teams as needed.
I find that organizations that set quarterly goals and then rely solely on bi-weekly team sprints for execution don't have time and space during the quarter for the cross-team discussions necessary to monitor progress against goals and make tweaks to stay on track. I recommend using a monthly half-day meeting for this purpose, with a follow-up all-hands meeting for sharing prioritization changes and rationale. I'll share a template for this meeting in a follow-up post.
I've tried just about every agile process out there – scrum, kanban, etc. – and have landed on a simple two week process, with a kick-off and check-in meeting for level-setting on team goals, priorities, progress, etc. I like Linear's approach on this topic – including renaming "Sprints" to "Cycles" – because it reinforces continuous improvement over rigid release plans and an unsustainable pace.
For teams that really want to tie their release process to a fixed window of time, I've found that 3 week sprints are preferable to two week sprints because it allows the team a half week buffer for releasing and planning.
It may be blasphemous, but I don't like daily synchronous (in-person or video) stand-ups! It's challenging for folks to (a) succinctly describe their own status update and (b) have enough context and/or focus to pay attention to others'. That said, I do think it's important that the team is actively collaborating and unblocking daily. I prefer good async work hygiene to do so, where team members have a clear place to share their daily updates (asana, trello, jira, slack, etc.) and there are folks on the team who are responsible for watching for blockers, missed assumptions, chances for collaboration, etc. and making the necessary connections.
Perhaps the hardest thing to do in an organization is to get humans aligned on a set of goals, priorities, etc. One way to help is to ensure they are at least using the same planning cadence. The approach outlined here is one of many ways to do it; please share what's worked for you!