Don’t start your Sprint on Mondays
The cadence of the traditional working week has created an obvious rhythm for an Agile team to follow. Sprints are predominantly described as lasting 1, 2, 3 or 4 “weeks”, never 7, 14, 21, or 28 days. As a result, it makes sense to run that sprint in accordance with our calendar definition of a week.
In any case, on Monday morning your head is at it’s freshest, right? You’ve already thought of ten solutions to last week’s tasks and you’re energized and ready to put them into action. You’ve also been thinking about the Sprint retrospective all weekend, and planning how you can implement the improvements you and the team agreed (whether communication, management or meeting facilitations).
However, your dev team, who massively outnumber you, haven’t. They’ve been relaxing, not thinking about work at all, and completely dismantled the mental architecture they’d built to solve last week’s problems. Right now on Monday morning, they’re catching up on the weekend activities around the water-cooler and checking the emails that came in over the weekend. They’re yet to get into the frame of mind that will allow them to focus, assess and plan the sprint ahead. Suddenly Monday morning doesn’t seem like the best time to get them together.
To compound that issue, it’s inevitable that several times a year, your Monday Sprint planning meeting will fall on a national holiday, one of six or seven throughout the year. Failing that, your lead developer is out sick (not surprising since one-third of all sick days are taken on a Monday) or your sole UX designer is on PTO, finishing up a long weekend skiing with her family.
In that case, you could start your team’s sprint on a Tuesday, which surveys suggest is the most productive day of the week. But then you have a hanging final Monday of the Sprint when the team knows they have to rush to finish up all their work. As a result, you may see more of them coming in on the weekend than they’d really like to.
Thursday seems innocuous enough, but once you’ve spent most of the morning in a planning meeting, and then Thursday afternoon warming up, the team’s innate psychology may be to breeze through the first Friday and “start the real work” on the following Monday.
And of course, no good work gets done on a Friday. Who in their right mind wants to spend Friday afternoon going over everything that didn’t go right that week? Your team will be so eager to get to the pub that there will be no desire to contribute any ideas on how they could work better. And just as with Mondays it’s increasingly likely that someone could have left for a long weekend, meaning they’ll miss arguably the most valuable meeting of the Sprint.
By process of elimination, we arrive at Wednesday, aka Humpday. The longest possible time from one precious weekend to another. However, it’s not just that Wednesday is the least-worst option; its position in the middle of this week makes it unique in complementing another key element of this practice: start AND end your Sprint on the same day.
Asana, who should know a thing or two about productivity, are known for having No Meeting Wednesday — one precious day for those on a makers schedule to work uninterrupted. In your new Wednesday-Wednesday Sprint, you’ll flip this on its head and have ALL of your team meetings on one day. In doing so, you’ve turned the two “half-days” in your last sprint cycle (Monday afternoon and Friday morning), into one whole day. In a two-week Sprint, your team now has 9 full days of working uninterrupted! As Paul Graham of Y Combinator argues:
“Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.”
By combining two half-days into one, you are creating time. Congratulations. This must be what the Big Bang felt like.
The New Plan
Here’s an outline of how your new All Meetings Wednesday looks:
9am — 10am: Development team has an hour for individual wrap-up. The Scrummaster can complete the final burndown chart and individually assess what was completed and what wasn’t.
10am — 11am: Sprint review. Gather the whole team and the product owner together to review everything you accomplished.
11am — noon. Sprint retrospective. Discuss any learnings and how the team could have performed better.
Noon — 1pm. Team Lunch. It’s a great time to relax, celebrate a deploy or launch and allows the team to catch-up and build the empathy necessary for high-performing teams to collaborate and perform at their best.
1pm — 2pm. Sprint Planning. Judges are at their most positive immediately after lunch. Likewise, with full bellies, the team may be more receptive and positive about the goals for the next Sprint. Moreover, the retrospective and review will be fresh in their heads — just an hour old by the time you start planning. Had you waited a weekend, this would be more like a 60-hour gap.
From there on, Wednesday is the teams to begin gathering resources and prioritizing tasks. There may even be time for a little development work before the day is out.
— — — — — — —
Let me know what you think of this idea in the comments below, particularly if you disagree! I’d love to keep the conversation going.
If you liked what you read, please Recommend. For more on Agile, Org design and teaming, please hit follow above and/or on Twitter