[go: up one dir, main page]

DEV Community

Steve Hallman
Steve Hallman

Posted on • Originally published at theagilecouch.com on

What difference could it possibly make?

15 Reasons to Change Sprints Mid-Week (and hold the Scrum Events as intended).

The ironic thing about assumptions is we’re generally unaware of them. Like fish saying, “What’s water?”, we are surrounded by things we assume must be true. Which means we’ve never even considered doing them any other way. Weeks start on Monday, months start on the 1st, the batter starts on home plate. These feel so natural.

Do Sprints have to start on Monday and end on Friday? The answer is not only “No”, there are significant advantages to changing Sprints mid-week. (It is also worth contemplating the Sprint length, and other factors, but we shall discuss that another day)

I argue that mid-week Sprint change is a technique of hyper-performant teams– just as important as holding every event, performing each event as intended, with the right participants present, at the right time. Here are 15 advantages of the mid-week Sprint change, and the Scrum Events held unapologetically. Can you think of others?

  1. Sprint Planning should be the first event of a Sprint. Time spent on anything else (other than the preceding Sprint) introduces a Cost of Delay to your efforts. You need adequate time to plan. This means a working meeting free from “meeting guilt”. We’re not ashamed, we have no imposter syndrome, we know we are solving novel problems, and this takes time for the customers and Scrum Team to plan. That means avoiding the worst day of the week for meetings.

  2. Start with the maximum Event length your Scrum Master or Agile Coach is ever going to ask for. The proportional Sprint Planning length is 8 hours for one month, 4 hours for two weeks, and so on. It’s very easy to take less time if you find you have completed the outcomes expected of Sprint Planning. Meeting guilt is always going to pressure people from increasing the time. When you’re 6 days into the Sprint and realize you don’t know the details of the feature you’re supposed to build, you will think back to Sprint Planning, when some folks felt pressed for time, and DOR was skipped because “everyone knows what the green button is for”. Skipping the three sections of Sprint Planning (you know all three, right?) will inevitably introduce COD in the system.

  3. This ratio has been validated for more than 30 years. A lot of teams have done a lot of Scrum, and not all of it good. The Sprints that went well are planned well, and follow Sprints that were closed well. If hyper-performant teams use 8 hours to plan a month long Sprint, and it boggles the mind, it’s worth asking, “What are they doing that we’re not doing?”

Given that two weeks is most common, 4 hours can be done. There are ways to resolve all the most common rebuttals and complaints. Take breaks, set time blocks for different groups of customers, adapt!

  1. Adequate time for a full Review. Sprint Review is the second most important Event in a Sprint. It does for the work, what the Retrospective does for individuals and interactions. Review ≠ Demo. Review may include a demo of features, but the purpose is to produce specific outcomes (a new Product Backlog) and discuss factors that affected the work itself. If you’re breezing through a 30 minute demo, I challenge whether you are doing “Transparency, Inspection, and Adaptation”.

  2. Adequate time for a full Retrospective. The single most important part of Scrum. Raise you’re hand if you’ve been on a team that had a “Review & Retro” single event on the calendar. These are distinct, and each has it’s own outcomes and timebox. If the Retrospective is sharpening the saw after every day of cutting lumber, what are we doing if we pencil-whip a few “pat-on-the-back” cards in our Retro plug-in and call it an early Friday? Sharp tools are safer, they cut better, they require less compensation with technique (or personal strain). I will guarantee you a Scrum Team that breezes through Retrospective is relying on heroics, and heroics are not Sustainable Pace.

Advantages of Mid-Week Sprint Change

Given the importance of the Events outlined above, we want to take advantage of any hack that allows us to squeeze the maximum value from them. The mid-week Sprint change is that hack.

  1. Monday and Friday are the most frequent national holidays.

  2. Monday and Friday are the most frequent company holidays.

  3. Monday and Friday are the most frequent employee vacation days.

  4. Monday is the most frequent sick day.

  5. Monday and Friday are usually the “busiest” or most hectic days. Monday is the day everyone “puts their work brain back on” and tries to remember what they were doing last Friday. The weekend is a break in momentum. Picking up on Monday is usually hectic (see more below) and you’re entering that chaos without the memory of what you were excited about on Friday.

  6. Monday and Friday are the most common days scheduled for reporting, starting, and ending of other projects. This frequently causes meeting conflicts. Since everyone else is hosting kick-off meetings that you’ll get roped into, avoid holding your most important events on the same day. Unless you’re the bride, don’t wear white to a wedding. Having your key events mid-week helps you to Be Fully Present for other stakeholder’s events. They’ll thank you for it.

  7. Review and Retrospective should be the last thing that happens in a Sprint. These are the two most important Events in Scrum. It’s no secret that people tend to “zone out” on Friday afternoon, or they are impatient to start the weekend. Possibly leave work early, get a jump on that traffic on the way to the lake. If you hold Review and Retro early, you have cut your time to produce value before these. The last possible moment would be the end of the day, on the last day of the Sprint. If you make that a Friday, good luck getting anyone to think about “inspect and adapt” with enthusiasm while they are groaning and watching the parking lot empty.

  8. Releases to PROD often happen coincident with Sprint closing. This leads to bugs that show up on Friday and cause a panic fixing them last minute. Or having to troubleshoot on the weekend. Or, people miss Review or Retro because they are troubleshooting just-released code. While there are plenty of technical tactics to avoid this, we’ll leave that for another time. One thing you can do to prevent this is mid-week Sprint change. If you push everything to PROD with a prayer and voodoo dance around the server, you’ve got 2-3 regular work days to catch something, and you’ll be in a better mind to deal with it than sweating while your wife is waiting in the parking lot with the beach trip luggage and kids slathered in sunscreen.

  9. A mid-week change gives a full, uninterrupted week during the Production Episode to focus. Your whole team does understand the Production Episode pattern, right? With mid-week Sprint change, the entire (assuming a two week Sprint) cycle takes place over three calendar weeks. You start on a Wednesday or Thursday, have one full, uninterrupted week in the middle, then half a week till wrapping on Tuesday or Wednesday.

If one of your team’s goals is to reduce meeting fatigue, find enough time to focus on work with some momentum, and hide from customers and the Product Owner (I kid, I kid), you’ve never known peace like a Production Episode with a whole blissfully uninterrupted week in the middle of it. Also, remember that stuff at the top about actually having a FOUR HOUR SPRINT PLANNING!? Guess what, holding all the Events for their recommended duration goes a long way to put out the little “meeting fires” that pop up when the team discovers unanswered questions during the middle of the Sprint. You have time in the Retrospective to ask questions like, “Why do we keep having ad hoc meetings? Why can’t I concentrate on something for more than 30 minutes between meetings? I want to mob with Judy and Tom, why can’t we find even an hour that overlaps!?”

  1. The 2-3 days at closing, and 2-3 days after planning feel like “mini-sprints” and help focus on the most important things that need to happen “right now”. Let’s use the example of closing Sprint 1 on Tuesday and starting Sprint 2 on Wednesday. Wed, Thurs, Fri feel like a little 3 day Sprint. You’re invigorated from Sprint Planning, and you’re full of fresh ideas for some new experiments. If this was Monday, there is a psychological temptation to think, “I’ve got all week”. And by the end of a typical Monday, everyone else’s chaos has ground the oomph out of you.

Similarly, returning from a weekend with 2-3 days remaining till Sprint close, you have a little pretend pressure and a smaller timebox to think, “OK, what do we need to wrap everything up and land the remaining planes in the air?”

  1. A bonus! While everyone else has the mid-week doldrums, you will come out of Sprint Review and Sprint Planning invigorated right in the middle. I’ve seen downstream internal customers that were ecstatic coming out of Sprint Review. They were positively giddy and looked forward to opening their Christmas presents in the middle of the week. It lightened their mood and gave them a few following business days to think of new ideas, changes, or additional details based on what they had just seen. This captures psychological momentum. Hold Review on a Friday afternoon and you’re likely a customer overlooks a bug or style problem while they’re watching the traffic back-up, and then any chance of continuing their product thought excitement is flushed down the drain once Friday is officially in the books.

What did I leave out? Can you think of other reasons to emphasize the importance of Event scheduling, timeboxing, and mid-week Sprint change?

Top comments (0)