Patty Aluskewicz started a spirited discussion on LinkedIn with a poll, What is your favorite Scrum Event to facilitate and why? I really like the level of engagement it received – there were over a thousand votes to this poll and many weighed in with comments.
IMHO, whether or not an event is a favorite to facilitate is almost beside the point. You may as well ask the team which meetings they enjoy or find useful. There will almost always be some who say “no meetings” are enjoyable or useful. And that leads me to my main point – all the events in Scrum have a clear purpose and contribute to the whole. Whether or not we enjoy a particular Scrum Event seems beside the point. None should be skipped.
Unfortunately, it seems that some teams do pick and choose the ones they like and some skip events they don’t enjoy or value. So I asked a slightly different question – which Scrum Event is your team most likely to skip and why? My findings are below.
OK so maybe you and your team don’t skip Scrum events. Ever. That is awesome. If you have never skipped an event, this blog post is not for you. (Perhaps you should skip an event in your next sprint as an experiment!)
Unfortunately, I have seen many teams skip Scrum events. The reasons given for this are varied:
Can you skip an occasional Scrum event? Sure you can skip some meetings. But which ones?
I was curious about this question. My personal favorite meeting is the retro simply because when used effectively it can really help the team improve. But what are others finding? How did they answer the question of the most likely event their team would skip?
In my LinkedIn poll, only 7% said that they skip Sprint Planning. What happens if you skip Sprint Planning? Would you actually start a new sprint? What would you work on in the sprint? Perhaps you rolled over 7 backlog items from the previous sprint and you can just keep on chugging. What kind of results should we expect from you?
The poll showed that this was the least likely Scrum event to be skipped. It wouldn’t make any sense to skip it unless you didn’t need to plan.
In my LinkedIn poll, 15% said that they were likely to skip the Daily Scrum.
I can see why more people want to skip this one. It is the most common meeting and though it was intended to be short, I’d wager that there are more people who go over 15 minutes a day than stay under it.
And some people see meetings of any type as a waste of time, especially a daily meeting. Why meet every day when you could skip those and save the time and effort involved? That would be the best way to increase individual efficiency, right?
Frequently when I hear of the daily Scrum being a waste of time, it is from people who are on multiple teams (not recommended – see avoid fractional people assignments). If each team member is on four or five teams, they could easily chew up 2-3 hours per day in those daily meetings.
Which. They. Definitely. Should. Not. Be. Doing.
The Scrum Framework works when people are on one or at most two teams. Spreading people around to multiple teams ensures that they will be multi-tasking and context switching – bad things in other words.
A full 24% of LinkedIn respondents said that their team is most likely to skip the Sprint Review. This is one that unfortunately I see way too frequently. The reasons vary. It could be that the stakeholders aren’t available. Or the stakeholders are not interested or they were never invited to be part of this key event.
The purpose of the Sprint Review is to get feedback on the product being built. Can the teamwork function without that feedback? Sure, that is called Waterfall and you can read a history book to learn how to use it.
Finally, there were 58% of respondents to my LinkedIn poll that said that their team is mostly likely to skip the retrospective. This is really sad to me. The Sprint Retrospective is not only my favorite meeting to facilitate, it is also arguably the most important of the meetings. It is the meeting where the team examines how they are working together and collectively comes up with new ideas for improvements. Done well, the retrospective supports continuous improvement.
As noted in the comments, there may be reasons to skip the end of sprint retrospective. Perhaps the team is doing the equivalent of a retro on a daily basis. No point in batching up all your improvement ideas and discussions until the end if you can do it continuously.
Now I would say that an occasional skip to the retrospective isn’t going to kill anyone. I’ve seen teams head to a local pub for a liquid retro and done occasionally, that may be more valuable than a room full of people staring at their feet while an unskilled facilitator asks them what did not go so well in the last sprint.
Here is what I have seen that I don’t really like – cancelling the retro entirely. I have also seen teams that rescheduled the retrospective to the middle of the next sprint because everyeone was too busy. That is a complete waste of time and it undermines the cycle of empirical process control that Scrum is based on.
Some people see the simplicity of the Scrum Framework and completely overlook the power behind that simplicity. Scrum is based on empirical process control. It is this: Plan -> Do -> Check -> Act (or PDSA if you prefer – Plan -> Do – > Study -> Act).
We plan on multiple levels. Formally we plan during Sprint Planning but every day in the Daily Scrum the team gets an opportunity to make fine-tune adjustments and check to see whether they are on track to hit their sprint goals.
Check happens in multiple places including the Daily Scrum, Sprint Review, and Sprint Retrospective.
And introducing new actions be discussed and introduced at various points including the Daily Scrum, Sprint Retrospective, and Sprint Planning.
I get it, everyone is busy and most people have too many meetings. While it may be tempting to pick apart the Scrum Framework and pick and choose which you want to use for your team, including the Scrum Events. Unfortunately, it is not designed to work that way. You can’t treat Scrum like an ala carte menu.
As Scrum co-creator Ken Schwaber says, “Scrum is simple, just use it as is!!”