Sprint goals suck too
Back in about 2014, I remember Matt Thompson help bring in ‘heartbeats’ to the Mozilla Foundation. As he explained in this post for opensource.com a couple of years later, using that word instead of ‘sprint’ is useful because:
Heartbeats can create a great sense of purpose, and ebb and flow in your team. They can be set to any length—a week, two weeks, a month. It’s really just about bringing people together in a regular, predictable cycle, with a ritual and set of dance steps to ensure everyone’s on the same page, headed in the right direction, and learning and accomplishing important things together.
I was reminded of Matt’s work when I saw Steve Messer’s post about helping a GOV.UK team implement a new model for agile delivery. Similarly, he points out that you don’t need to do two-week sprints.
This is something that Laura and I have been discussing on a project we started last month with a new client. There’s an expectation these days that to work in an ‘agile’ way you have to do sprints. You can use them. But you don’t have to.
Traditional two-week sprints and Scrum provide good training wheels for teams who are new to agile, but those don’t work for well established or high performing teams.
For research and development work (like discovery and alpha), you need a little bit longer to get your head into a domain and have time to play around making scrappy prototypes.
For build work, a two-week sprint isn’t really two weeks. With all the ceremonies required for co-ordination and sharing information – which is a lot more labour-intensive in remote-first settings – you lose a couple of days with two-week sprints.
Sprint goals suck too. It’s far too easy to push it along and limp from fortnight to fortnight, never really considering whether you should stop the workstream. It’s better to think about your appetite for doing something, and then to focus on getting valuable iterations out there rather than committing to a whole thing.
Source: Boring Magic
Image: Matt Collamer