Smell #6: Not Performing All of the Scrum Ceremonies
Scrum has a number of time-boxed events, collectively referred to as Ceremonies, that must be performed in order to support the framework. Omit any of the ceremonies and you aren't doing Scrum. I know there are those of you reading this that think I'm a purist and that some of the things we do in Scrum are only marginally useful and therefore a waste of time. But the truth is, if you are doing them correctly, none of them are a waste of time, and together they make a strong and well-supported framework on which you can do good development.
Here are the Scrum Ceremonies:
- Scrum (aka: Daily Stand-up)
- Sprint Planning
- Sprint Review (formerly called the Sprint Demonstration)
- Sprint Retrospective
- Release Planning
- Release Retrospective
- Periodic/Weekly Story Sizing (this only applies if you don't do sizing as a part of Release Planning)
Every team I've worked with, even before I was familiar with Scrum, I had a standing rule: "I will never commit my team to unnecessary meetings. If a meeting has limited or no value, it gets eliminated. If you think a meeting is unnecessary, tell me and we'll discuss its elimination."
The six/seven Scrum ceremonies are all necessary. But here's how it tends to break down when people try to do Scrum buffet style:
- All teams do the stand-up. Unfortunately, a lot of groups think that by doing just this one thing, they are "doing Scrum".
- Most teams do Sprint Planning, since it's an obvious necessity.
- Slightly fewer do the Sprint Review, with those dropping out thinking that it is an unnecessary formality. "The customer will see the product when it's shipped."
- More teams drop the retrospective, since "it's just going to be a bitch-fest, anyway."
- There's then a big drop in groups performing Release Planning. The excuses start mounting up: It's harder to coordinate; it takes time away from "productive" work; "We really don't know what's ready to work until we get to sprint planning, anyway."
- And there's a huge drop in groups doing Release Retrospectives. Again, it can be difficult to coordinate. "Besides, we covered all that in the Sprint Retrospective, right?"
My teams have always done the morning Scrum, Sprint Planning, Sprint Review, Sprint Retrospective and Weekly Story Sizing. If I tried to drop any of those ceremonies, there would be Hell to pay because my teams know those ceremonies have value. We worked as a team to ensure that they were (and are) valuable experiences.
We dropped the Release Planning and Retrospective at one point. Not intentionally, but because those two ceremonies are hard to coordinate at times. Especially since Releases are only marginally related to Sprints and Releases can overlap, with work beginning on a new release often weeks before the current release is delivered to Software Configuration Management. I realized after almost a year of not doing them that I wasn't doing Scrum -- I was missing two important tent poles. So I bit the bullet and worked with my Product Owners to re-introduce them.
The result was amazing -- and it shouldn't have been.
Almost to the person, my team members came to me afterward and told me how good these meetings were; how they improved their perspective on the on-going direction of the product; and why weren't we doing these before? My team members aren't gluttons for punishment. They tell me when they've been to a bad or worthless meeting. And here they were, again, almost to the person, telling me how much they appreciated these "new" meetings.
Scrum is not a buffet -- don't do it a la carte.
Smell #7: Not Respecting the Sprint Time Box
The following conversation actually occurred, though it may be a bit paraphrased. Some of you may think I'm making this up; I assure you I am not. Others may recognize it because, they too are not respecting the time box.
The participants in this dialog are a Product Owner from another set of teams in my company, denoted as "PO", and me.
PO: It looks like one of my teams is going to have two stories incomplete this Sprint. It's so frustrating.
Me: I understand, but they'll get finished at the start of the next sprint, so they'll still make it into your release.
PO: Oh no. They have to stay unfinished for at least another sprint. Our next sprint is already full.
Me: (doing a coffee spit-take) Excuse me? How can it be full already?
PO: It's full. There's no room for those stories to be finished.
Me: Oh, so these stories are lower-priority than the stuff that's already in the sprint?
PO: No, they are higher priority. This keeps happening and it's really annoying.
Me: (doing spit-take number two after foolishly sipping my coffee again) WHAT? I'm missing something here. Why are higher-priority, unfinished stories not at the top of your next sprint.
PO: Because the sprint has already been planned.
Me: Already planned? Today is Friday. Your next two-week Sprint starts on this upcoming Wednesday, right?
PO: Yes...
Me: So... (realization dawns) ...when did you do Sprint Planning for next week's Sprint?
PO: Two days ago, on Wednesday, before the team realized these stories wouldn't get finished.
Me: (safely not spitting more coffee on my monitor because I saw it coming) So, let me get this straight, your TEAM is doing Sprint Planning a week before the sprint starts while the current sprint is on-going?
PO: Of course. There's no time to do it any closer to the sprint -- we'd be in a whole day of meetings.
Me: (More coffee on the monitor, darn-it) You realize that it takes the same amount of time whether its on the same day as the demo and retrospective or not, right? I mean you don't actually lose a day. You just allocate it differently.
PO: You guys do something different?
Me: (Feeling faint.) Yes. We do Sprint Planning for the new Sprint after the Sprint Review and Retrospective for the prior Sprint. That way we automatically transfer unfinished stories to the top of the new Sprint if we have to.
The good news is that, as a result of that conversation, the Product Owner's teams reorganized so that the Sprint Time-box was no longer intermingled with the prior sprint.
The Time-boxes were created so that Scrum processes work. Respect them so that you can work, too.
No comments:
Post a Comment