February 2022 – The Progressive CIO

🎹 Music for this post: https://www.youtube.com/watch?v=JSCVOQv4j6E.

Prologue

I don’t think I’m alone in feeling that the pandemic has made professionally-oriented content feel overtly trite. Families and personal lives are eminently more important than they have been in our lifetimes. Out of respect for my readers, I’ve deliberately reduced my blogging for several months, writing occasionally rather than prolifically. My sense here in February 2022, though, is that people are slowly resuming their interest in new things about our work lives, as long as these things are simple and refreshing. This is the first in a series of columns written in that mold.

Many years ago, when I was in the habit of interviewing software engineers on a regular basis, I would often ask:

Apart from the Sprint itself, what do you feel is the most essential ‘ceremony’ in the Scrum framework?

I never kept count of the answers I got over the years, but there is no doubt that the most frequent answer — by a long shot — was the Daily Scrum. In many cases, this was the only ceremony the candidate was familiar with, which was a handy sign that he or she really didn’t have a full understanding of Scrum.

I recently shared a poll on LinkedIn posing this question, and received the following results:

Sprint Planning: 18%
Daily Scrum: 32%
Sprint Review/Demo: 32%
Sprint Retrospective: 18%

Is there a correct answer? Strictly speaking, of course not. But as a leader whose organizational responsibilities have included “agile transformation” for as many years as I can remember, I’ve developed an opinion that there is, in fact, one ceremony that is particularly essential in delivering on Scrum’s “inspect and adapt” principles. That ceremony is the Sprint Review.

The Sprint Review is where all of Scrum’s magic happens. Scrum without a Review is a tree falling in the forest with nobody to listen. The Review is the home of “inspection” and the springboard for “adaptation.”

The poll tells me that the majority of my readers’ brains are perturbed right now. Please allow me to elaborate.

First off: The Sprint Retrospective. Sprint Retrospectives are immensely powerful tools, and a place where inspection and adaptation — of process rather than product — takes place. Many Scrum practitioners are dogmatic about Retrospectives — but I like to say that the only place where dogma is acceptable is in religion. Woe be unto you if you treat Scrum as religion. As Scrum teams mature, with healthy self-empowerment and active daily conversations, Sprint Retrospectives are likely to decrease in relevance. It’s perfectly OK — arguably, healthy — to skip a Sprint Retrospective or two in a Scrum team that has been performing consistently well for weeks or months on end. A high-performing team will always ask itself, and answer honestly: do we need a Retrospective? If not, it’s OK to move on.

Secondly: The Daily Scrum. Here’s something controversial for you: Arguably, the Daily Scrum is the least important ceremony of Scrum. Why? Because high-performing and tightly-communicating Scrum team members are more likely to understand each other’s progress, work to come, and barriers as artifacts of their interactions throughout the day. Daily Scrums are absolutely essential for new teams and teams that are not good at identifying and articulating barriers (which is, admittedly, a whole lot of teams.) The most mature Scrum teams I have worked with have incredibly short Scrums, and even occasionally skip them to no ill effect.

Thirdly: Sprint Planning. I know what you are thinking: How can you have a Sprint, let alone a Review, without Sprint Planning? Isn’t Sprint Planning equally as important as the Review, if not more important? (More important? Let’s not get carried away! A planned and executed Sprint with no Review is a waste of time.) Here’s the rub: It is entirely possible to start an agile initiative with a Review of work that was not borne of a Sprint Planning session: A Review that consists of a display of skunk-worked/hobby-level/unplanned work that a team believes has merit. I call this sort of Review a “Big Bang Demo”; an “origin of the universe” kind of event. Once it happens, one of two things follow: a fizzle, or a proper Release/Sprint Planning session.

Of course, most Scrum initiatives start with some form of Release Planning, following up with Sprint Planning, so I can appreciate those of you who argue for Sprint Planning as the most essential answer in my little poll. But: apart from the very first Sprint Planning session, all subsequent Sprint Planning is informed by the outcome of a Sprint Review! Without those Reviews, there is nothing to adapt for subsequent Sprint Planning. If your Sprint Planning sessions don’t incorporate adaptation from your Sprint Reviews, I would argue that you have enough certainty in your project to merit a waterfall approach, and that you’ve chosen the wrong tool for the job!

This is why, to me, there is no doubt that Sprint Planning is a close second to the Sprint Review in terms of its essence. Scrum is a project management tool for uncertain initiatives.

The Sprint Review is where we learn. It is the fulcrum for all decision-making. If there is no Review, there is no learning, there is nothing for the Product Owner to approve, there is nothing to adapt from, and there is nothing that has been thoughtfully approved for release to the customer.

But all of this is more than a mere thought exercise. If your organization is on an agile transformation journey, you will do well to prioritize the quality of your Sprint Review culture over everything else in your Scrum process.

Make sure that your Product Owner attends and participates in every Review.
Do whatever you can to ensure that the Review grabs attention. Don’t ramble; stay focused.
Condition your Product Owners to be honest — yet respectful —about their feelings. Accepting work that the Product Owner is too uncomfortable to reject is a recipe for disaster — and arguably one of Scrum’s most frequent failure points.
Condition your implementation teams to avoid defensiveness. They should be ready to set aside all or part of a Sprint’s work if that is what the Product Owner decides.
Script and rehearse the Review so that there are no surprises. Don’t review work that hasn’t been reviewed and tested.
The team should strive to ensure that the Review is a learning experience, each and every time. If there is no learning, there is no point in employing Scrum.
Try to have as much fun as you can! Make the event something everyone looks forward to. Bring donuts. Or ice cream. At the very least, bring a few good jokes and a roomful of smiles.

The Review should feel like the point of Scrum. It should feel like Christmas morning, or the first day of Hanukkah, or any other day that you used to look forward to each year as a child. Done well, it is the “push” for the snowball that is your project, and each and every Review will see your snowball moving with greater momentum. If you get your Reviews right, your team will bring a positive and focused spirit to all of the other ceremonies of Scrum, from Sprint Planning through Daily Scrums and, yes, even to Sprint Retrospectives.

Discuss this specific post on Twitter or LinkedIn.