Navigating team efficiency and release planning in Scrum teams

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

Roy vandeWater: I’m Roy vandeWater.

Jade Meskill: And I’m Jade Meskill.

Team Unable To Hit Deadlines

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]

Process Is Creating Waste

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.

We Just Need More Time To Code

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?

Process Highlights Problems To Be Solved

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?

Death Marches Don’t Work

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 eXtreme Programming 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 effectiveness of that decision and if it made a negative impact, strongly encourage them to roll back.

At What Point Does A Team Lose The Right To Be Self-Organizing

Clayton: That gets into another issue of, “At what point do you let the team self‑organize themselves to failure”?

Roy: Yeah, that’s really tough. I don’t think I have an answer for that at all.

Jade: I’d say, some of it depends on what’s the cost of failure. If it’s going to get everybody fired, then maybe it’s not a very nice thing to do to let them fail utterly.

If it was me in this situation…if I’m pretty sure they’re going to fail at this, I can’t tell them that. I can’t tell them what to do, if I’m a good Scrum Master.

But what is some way I could encourage them to fail the smallest? To say, “OK, that’s great. We want to throw this all out the window. Let’s do that, but let’s check in, in some short amount of time.”

Like what Roy said, “For two weeks, do whatever you want and we’ll talk about what that really means.” That’s the direction that I would go, if the team was really insistent on that. If we want to blame Scrum or we want to blame some framework for the challenges that we’re having, “Fine, let’s try without it. I’m pretty sure that those challenges aren’t going to go away.”

Self-Organizing Vs Self-Direction vs Self-Governing

Clayton: The things in this scenario I’m trying to highlight the fact that Scrum or whichever framework you pick is not the silver bullet. You can still have all kinds of problems in the framework. It’s not the framework’s fault. It’s like you’ve mentioned, Jade, you disagree with the facts or you’re afraid of the facts or whatever.

In addition to that, there’s a real question if you’re someone that’s may be in like a management role, it’s pretty powerful to let the team fully self‑organize themselves into failure, but at the same time, you really just have to weigh the risk of what does it actually mean to fail and what point do I step in.

You want them to be self‑organizing, you don’t want to necessarily shelter them, but at the same time you have to have that, maybe it’s a really long leash or something. I don’t know the right way to think about it.

Jade: Let’s remember that self‑organization is not self‑direction.

Clayton: That’s a good distinction.

Jade: Or self‑governing. There is some container placed around the team that they’re self‑organizing within.

You Can’t Ignore The Facts

Clayton: I’m trying to think if there’s any other modifications we can make to the scenario. Let’s say that the release is say six weeks away and this team is doing one week iteration. If you’ve got six iterations left, let’s say that three weeks go by and their velocity has picked up a little bit, but it’s still not enough of what they need.

Let’s say they’re stuck with Scrum, we convinced them that they should stick with that. Is there anything that you would suggest at the three‑week mark maybe, when you’re half way there, that they may be changed or do differently?

Jade: Again, you can’t ignore the facts. If the historical velocity of the team is consistent or maybe it’s five percent better or some small improvement, that’s awesome. If you need a 100 percent improvement to get where you’re going, it’s not going to happen. This is the time to get everybody in the room and have a very, very, tough conversation.

If we look at some of the core values of Scrum and extreme courage is in there, this is that time to have extreme courage and basically stop the line and say, “This is not going to happen, something has to give, either the release date has to change, the scope has to change.”

One of those two has to give. We’re too close. We can’t just ramp up a new team, fix all these problems, and do all the stuff. We’ve got to change our expectations, if we’ve got to match them to reality.

Roy: There is one thing, we had talked about the extreme risk of failure in this case. Let’s say that not hitting all of the features by that date is going to be a huge downside, if that causes the firing of all the teams or whatever it is.

There is a Scrum game that all of us have played, and it’s one that you like to bring to your coaching engagements, Jade, which is the ball point game.

The essence of the game is that you pass a bunch of balls around in a circle and there’s some very specific rules on how it all functions and [inaudible 13:55] try to get as many balls around the circle and back into the bucket. That’s one of my favorite games because I remember when we played it with Integrum, back when we were doing application development, I remember what we got from it is we got to 70 or 80 balls around the ring in the two‑minute time period.

We started at 70, we optimized a little bit and got 73, we optimized a little bit more and got 75, and we hit around 80. We were like, “We’re awesome. This is as fast as it can get. We have optimized the crap out of this, and we’re kicking ass at this.”

Then, Derek steps in and says, “I’ve seen a team hit 160,” and suggest a completely different way to do it and all of a sudden with very little practice, our first time around, we hit a 100, and we’re not even going that fast.

The second time through, we were hitting 126. We now have almost doubled what our initial velocity was. I’m not saying that there’s a magic bullet like that for this team’s problem, but if the risk is so great that everybody’s going to lose their jobs and you’ve got nothing left to lose, it might be a good time to start taking some extreme risks to try something radically different and see if that makes a difference.

Clayton: The risk thing is a two‑sided coin, that’s a good point. I guess, we can, in the future, check back on my hypothetical team and see what’s going on.

Jade: [laughs]

Clayton: I appreciate the conversation. Thanks, guys.

Jade: Thank you.