Working in Sprints
When your team sets off on a new expedition, you’re navigating unfamiliar terrain. It’s not clear what the team will encounter. We might find a new route that will lead the team and company to unforeseen prosperity, or, we might encounter new threats that if unavoided lead to certain peril—Blockbuster might figure out how to thwart Netflix, or, it might go out of business. As we proceed we may find we need new skills and resources. Or, we might find we need to change our destination entirely. Since we don’t know what we’ll encounter ahead of time there is no way to make a long-term plan. The only rational way to proceed is to send out scouts and explore a bit, reconvene and reflect, and make decisions for which direction to move next a little at a time.
Software teams discovered this way of working long ago; they call it agile. After decades of scrapping plans and schedules due to unanticipated technical challenges or changing customer needs, software teams came up with a new way to work. In lieu of following a strict plan, agile teams operate in short cycles called sprints: they gather a small amount of data, formulate a short-term plan, carry it out, and use what they learn to inform the next sprint, and so on. Mission-driven teams can and do adopt their own nomenclature for sprints. In this series, we’re going to stick to the most commonly used language so you can find additional resources, if you are so inclined.
As the Program Director of the Blockbuster Youth Engagement Team, your first job is to establish how long your team should explore before it reconvenes to reflect on what it’s learned. By default, 2 weeks is a good sprint duration. As a general guideline, seldom should a team sprint for longer than a month. As most organizations operate on a quarterly rhythm, sprints exceeding a month give only 3 or fewer opportunities per quarter to change direction. Since we’re trying to maximize a team’s ability to respond to what it learns, we want to set a cadence that’s just long enough to do meaningful work and just short enough to give our team opportunity to react.
Sprints have specially formatted meetings within them to coordinate the team’s activities. While different flavors of agile offer different meeting rituals is important the ones you choose are are kept sacred, non-optional, are a big portion of what makes the team behave like a team. Here are the set of meetings we’ll use:
- Sprint Planning: deciding what activities the team should do during the next work cycle
- Check-in Meeting: synchronizing the team, clearing roadblocks
- Friday Ship: synchronizing with stakeholders
- Backlog Scrub: staying prioritized for the next Sprint
- Retrospective: making time for continuous team improvement
For a 2-week sprint, this is how the team’s calendar gets laid out:
The meetings specified in the above cadence are designed to engage the attention of the full team. They eliminate calling folks into meetings “just in case they are needed.” Assuming a 40-hour work week using this cadence a team will spend more than 93% of its time working on work—not in meetings. As the Program Director of the team, it’s your job to send out the invites and get these rituals on the calendar.
Pro-tip: create 2-week calendar events that clearly label each sprint, and, schedule each sprint-related meeting long in advance
It’s also your job to set up and maintain a place the team can use to access its tasks and documents. This place is called the Sprint Board. Remember the 2-day and 2-week tasks you collected from the project Kickoff meeting? The Sprint Board is where they’ll be added. We’ll describe how to set it up in the next module.
