Dealing With Impending Deadlines on a Scrum Team

Episode 48

February 23, 2012

15:32

TBD

tbd

The Agile Weekly Crew discuss impending deadlines on a Scrum team.

Episode Notes

Clayton Lengel-Zigich, Roy van de Water and Jade Meskill discuss a ‘hypothetical’ scenario in which a Scrum team has a deadline approaching and it looks like the team will not be able to complete all of the features to meet the release. How do you deal with this situation that happens to so many teams regardless of software process.

Do you throw out the process?

How do you break it to the product owner owner?

Would removing the overhead of the process make things better?

At what point do you, as a Scrum Master, step in and prevent the team from self organizing themselves in to fatal failure?

 

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the ScrumCast. I’m Clayton Lengel‑Zigich.

Roy van de Water:  I’m Roy van de Water.

Jade Meskill:  And I’m Jade Meskill.

Clayton:  Today we’re going to be talking about a hypothetical scenario that we’ve probably seen, in a few different permutations. The gist of it is, you’ve got the Scrum team and there’s a deadline approaching.

Maybe the business, or management, or product, or somebody has to set it that, “In order to release at this deadline, we need all these features, because these are things that we’ve promised to our customers. The sales guys are out there selling the stuff and we need all these features. So, there’s this finite demand of work that we think needs to be done by the release.”

The team for…maybe we’ll talk about some potential reasons…but the team, for whatever reason, maybe they’re underperforming. If you were to draw the release plan out, you would realize that. Say based on their recent velocity that there is no way that the recent velocity is going to be able to consume enough points to get all of the features done that the product team thinks needs to be done.

In that scenario what would you do? Do you treat it like a fixed‑scope project and say, “We’re not going to do Scrum anymore”? Do you switch to Kanban and try and get as much as you can done? What are some ideas?

Jade:  My question is, “How does getting rid of your framework or the processes or anything you’re doing actually fix the problem”?

Roy:  I can answer that.

Jade:  OK. Go.

Roy:  If you don’t have release planning, you don’t have to worry about a lot of the stuff that won’t get done until the actual release date, so you can put off that conversation for at least another month, if that’s how far the release date out is.

Jade:  [laughs]

Clayton:  There’s probably some validity to that. To answer that question further ‑‑ that’s a good topic to go down. Maybe the team thinks there is some waste in there or they think the process is slowing them down so they feel like if we just got rid of the process and had more time to work ‑‑ we need more time to code ‑‑ so if we stopped having these stand‑ups and these planning meetings and these retrospectives we’d have more time.

Jade:  Let’s just turn our brain off and we’ll get more done?

Roy:  Right. Being honest, how much behind are they? Are they behind enough that they’re considering throwing out their entire process, then is cutting out a 15‑minute stand‑up a day going to speed them up that much?

I would argue that it would even slow them down because now you have a bunch of independent people working and not communicating with each other. You are going to come to everybody trying to put their pieces together at the end and everything is going to hit the fan. It is going to be a total pain in the ass.

The overhead of those ceremonies don’t seem to be that big of a deal.

Jade:  Let’s talk about that. What do you do? Clayton gave us the scenario. Do you let them throw it away?

Roy:  I don’t know. If you realize that based off of the current velocity that you are not going to be able to meet your release plan, then that is the team’s time to have an honest conversation with the product owner. To explain to him that it’s not realistically possible.

Doesn’t matter what process you throw around. It doesn’t sound like these guys are just barely missing their target. It sounds like these guys are massively missing it. It doesn’t matter what process you put around it at that point. There’s no magic bullet to fix that.

Realistically, the stuff is not going to get done before the release date. They have to have that conversation.

Jade:  What if they won’t?

Roy:  I can’t help you if you won’t have that conversation.

Clayton:  Let’s flip that on its head, too.

What if they think, if we just had more time to code? Maybe we didn’t have a certain person on that team? I think we should implement this big feature this certain way, but these people disagree with me. If only they could just let me do the work, and they didn’t have their arguments, then we’d be OK.

What if they’re being hopeful?

Roy:  I don’t know. It seems like wishful thinking. It doesn’t seem very realistic.

It seems like you’re trying to throw out all the data and ignore it. Then say, “We hope everything is going to turn out alright. We choose to remain optimistic that everything is going to be great in the end. ”

Jade:  We don’t like what the facts are telling us. Let’s get rid of those.

Clayton:  Do you think this is why some people get to the cross roads when they’re trying something like Scrum, or any agile framework where things aren’t working out? They confuse the fact that scrum is just highlighting the problems. They think that it’s part of the problem.

They get to the cross roads where they start throwing things out or start creating scrumbutts?

Jade:  Of course! It is showing you what the problem is.

First, your reaction is to run away from that or to stop the pain. What do we do when we have a headache? We’re going to take something to get rid of the headache instead of understanding there is probably some source for that.

Maybe I need glasses. Maybe my neck is out of alignment. Maybe there is actually some real root cause that is causing my pain. I might blame it on something else in order to not address the root cause.

Roy:  Clayton, it sounds to me like this hypothetical team wants to throw Scrum out the window and just play it by ear. What’s going to happen when the release date rolls around and they still haven’t even gotten close, probably not even as close as their velocity would have indicated they’d get?

Clayton:  If you think about, what would happen on a traditional team, let’s say, we’re doing waterfall and we say, “Six months ago, we set this, drew the line in the sand, and said the ship date is this, the release date is this,” whatever. If things are taking longer, what usually happens to a waterfall team?

Roy:  You work overtime at the end and you start working 80‑hour‑work weeks to try to pull through…

[crosstalk]

Clayton:  Yeah, you work as much as you possibly can to try and get it done.

Roy:  …which vastly increases your defect rate.

Clayton:  We’ve seen that, too. Even if you’re a Scrum team, if you decide that you’re just going to throw that out the window, you’d only have the framework in any of the best practices. It seems like you just revert to the slow death march thing, right?

Jade:  Let me ask this question, is it possible if they did that, if they worked every available hour‑‑ in this hypothetical scenario ‑‑ if they worked every hour that they could, could they hit that release date?

Clayton:  That’s a good question. I didn’t really think about that when I was coming up with the hypothetical, but…

Jade:  I’m going to go with the XP thinking along this line and say that, “Overtime is not necessarily bad. It is when you have too much overtime that it’s bad.”

There are situations where it does make sense that we do have to put in some extra time to get where we need to go, but if it’s totally unrealistic and unsustainable. If we have to do this for six weeks just to get caught up or get to deliver, that’s insane.

If we had to put in an extra day, maybe that’s reasonable and the team could come to that. It sounds like, in your scenario though, they are too far off.

Clayton:  I would say, that more underlying thing or the root of that is that, I don’t think, anyone really knows the answer to that question. If you, at least, had that information, you could make that determination. If you don’t know the answers, then, you’re going to just throw your hands up in the air, right?

Jade:  Right. It sounds like there might be even more issues besides just the team getting work done.

Clayton:  Let’s take that in another direction. Let’s say, the Scrum Master got wind of this plan to throw away Scrum and they stepped in and they said, “We’re not going to do that.”

But if the Scrum Master came to you and said, “We don’t know what to do. We’re thinking about switching Kanban or we’re thinking about enforcing some rule about who can work on what story.”

Can you give them any advice in that regard?

Roy:  Ultimately, the team has got to be a self‑organizing unit. If the team honestly thinks that something like switching to Kanban or something a little bit less severe like deciding who works on what story, if they think something like that is going to drastically help, then it’s the Scrum Master’s responsibility to support them in that change, provided it won’t destroy the entire team.

As long as it’s not going to kill them, let them try it for a week. Then, force them to analyze the