Sprint Failure, How To Use It As A Learning Mechanism

Clayton Lengel-Zigich: Welcome to another episode of the Agile weekly podcast. I am Clayton Lengel-Zigich.

Roy VandeWater: I’m Roy VandeWater.

Failing A Sprint

Clayton: Today we’re going to be talking about a very rare thing that we’ve heard about from certain people. It’s called, “What happens when you fail your sprint.”

Roy: I’ve never experienced this personally.

Clayton: Me either. Of course not.

Roy: Right. Hypothetically, if it did happen, what do you do?

What Constitutes Failing A Sprint

Clayton: I guess we should define it first. Roy and I were talking about this topic earlier today and I was thinking, “I wonder if we think the same thing ‑‑ what it means if we say ‘fail a sprint’”? Is failing a Sprint the same thing as, you committed to do five stories, and you only got four done? Are we calling that a failure?

Roy: Yeah.

What About The Sprint Goal

Clayton: OK, I think so, too. What if you committed to doing five stories and then, you also had a sprint goal and you fulfilled the sprint goal, but you didn’t do one of the stories? Is that a failure?

Roy: That’s interesting. I haven’t really made sprint goals all that often, which is probably a bigger problem, but that’s an interesting point. If the value of the sprint is to achieve your sprint goal and your stories are almost an implementation to try to achieve that goal, then maybe achieving the sprint goal is all you need.

Clayton: For example, I always like to use the travel website. If our sprint goal is to make it easier for people to book a rental car when they book a cruise vacation, and we fulfill our sprint goal, but we didn’t do one of the stories, does it really matter?

Roy: I think that one is a little bit in our sync, because making it easier is like a slighter scale. You can make it a teeny, teeny little bit easier by doing a text change. I think the important part…I think what I really consider a failure is when you promise to deliver something and you fail to keep your promise. When essentially, you lose trust with the people that you have promised to, because you didn’t do what you said you were going to do.

Clayton: Like maybe, the product owner. You say, “Hey product owner, leave me alone for the next week and I promise you that I will get this thing done.” Then, in a week, you don’t get it done. So now the product owner trusts you less.

Roy: Right, exactly.

Not Doing What You Say You Are Going To Do

Clayton: OK. I think that makes sense. If we define failure as making a promise and then not…basically, we’re saying you aren’t doing what you said you were going to do. We talk about that, we use that phrase a lot internally. If you say that sprint failure is not doing what you said you were going to do, a lot of people I know don’t like to talk about sprint failure because they don’t like to talk about failing.

Roy: Well, it’s confrontational, of a sort.

Explaining Away The Failure

Clayton: I see a lot of people, a lot of teams that will try to find all kinds of ways to explain why they didn’t really fail. Whether it’s, “Well we were working on these five things, but then something happened and we didn’t have to this anymore, so we didn’t really technically fail because we still did the important stuff.”

Roy: Or “We worked on all of these things, but then this major interruption happened or this outside dependency caused us to fail our sprint because we were waiting to get something back from them. We thought we’d get it this week and we didn’t.”

Using Failure As A Mechanism To Learn

Clayton: One thing I’ve always noticed or thought, personally, is that if you don’t view failure as that big of a deal, if you view it as a learning moment, or a way that you can improve, then it doesn’t really matter if you failed because who cares, you don’t have to try to explain it away.

Roy: As long as you’re honest about it, you try to fix it for the next time.

Clayton: Let’s describe that then. I think there was a team that you were working with or we were talking about that had failed their sprint, or they weren’t going to get it done on time. So they cancelled their demo.

Roy: They actually postponed their demo about three or four days under the idea of, “We don’t have anything to demo right now because we didn’t do the stories we said we were going to do, but we should have them done in three days so we’re going to go ahead and do the demo then.

Clayton: In the entire sprint review we include the demo and the retrospective. Did they do the retrospective or did they skip that part too?

Roy: No, as far as I know the iteration was essentially extended for an additional three days.

Partially Done, Should We Demo It

Clayton: In that case we would call that a failure because they didn’t get it done when they said they’d get it done. What advice would you give to a team that doesn’t get things done? Maybe they got 80 percent of their stories done. Let’s say that rather than being really bad and getting 80 percent of everything done, they actually got eight out of ten stories done. Would you suggest that they show something in the demo? How would they handle that in the demo? What would the team do?

Roy: I would say that if you actually complete something, then show it off because it’s going to go into production, but if you haven’t finished it don’t show it because when you’re demoing, you’re demoing to not just a product owner who knows what’s going on within the team and was probably made aware way before this that not everything was going to get done, but you’re also demoing to the stakeholders, potentially even users of the system and so I feel it’s important to actually show them what they are now able to have.

Clayton: So those are the things you only demo what you’ve actually shipped.

Roy: Exactly.

Clayton: I have always gone back and forth on showing things that aren’t done‑done or unaccepted, only for the sake of maybe really valuing extra feedback. I guess there are probably more bad behaviors that come from demoing half done things or not done things then you’d get a benefit from the feedback.

Roy: I’m on the fence on that too. On one hand I think you shouldn’t demo anything that isn’t done because you are setting this expectation that features part of the product when you are starting a new moderation and it may not be prioritized anymore because something may have come up. The specific details on how to post a function may completely change. Essentially you are demonstrating something that may never happen so you are setting expectations that you don’t have the power to meet.

However, gaining additional feedback totally makes sense ‑‑ that may be what drives the actual change so it’s really dangerous I feel, but if you were to be extremely explicit about the fact that this is not finished, there is no promise, you are doing it purely to receive feedback, I could see that it might be OK.

Clayton: So probably don’t ever do that because most people are not going to listen to you when you say you are not going to get this.

Roy: I could see tens of people attending the meeting and be, “Wow”! And then selling to all the customers and then it gets put on the back and it’s never going to get done. Then you are taking power away from the product all of a sudden cause now they have to finish it because all the customers are demanding it.

Disclosing Sprint Failure

Clayton: In a crucial demo part of this review, some people from the team might actually get up and showcase their features and show them on a projector screen. How do you think the team should address the sprint itself ‑‑ should they address the fact that they didn’t get it all done or should they skip over that?

Roy: It is important to be as transparent as possible. If a team has failed a sprint, totally own up to it. Explain why but be really careful that you are explaining why and not making excuses. I would recommend verbalizing all reasons things specifically the team did wrong. The example I made earlier where you are depending on an outside source and they weren’t able to get you the stuff you needed on time and you thought they would. I would word that as “We made a promise for things that we did not have direct control over and the way we would mitigate that in future is by only promising things we know we can deliver.”

Clayton: I was watching a video from Dan North speaking in the conference about high performing teams. One of the things I thought was really interesting was he was talking about the team he was working on ‑‑ which was really high performing. They had a component of their showcase, they were doing scrum, but the component of the demo where they talked about things they learned. I thought that was a better way where you can pretty much convey the same information but it’s not presented as, “We would have had that stuff done but excuse excuse excuse.”

We didn’t get things done being very afraid of failure and we learn these things that will help us in the future. I feel like that’s a much easier way to go about it even though its sugar coating the fact that you failed. I’m not necessarily advocating that but for teams that are transitioning, that aren’t as comfortable with conflict or perceived conflict involved with saying, “We failed.” ‑‑ technically what you learn might be easier.

Where Does The Retrospective Happen In Relation to Sprint Failure

Roy: There might be some difficulty with how you structure your retrospective with respect to your demo. You may not have identified a good way, you may not have learned what you are going to learn by your demo time because you might your retrospective afterwards.

Clayton: That’s a good point. What would you suggest is positive or healthy behavior that someone in a Scrum Master role might take to a team that failed a sprint?

Roy: I would absolutely orient a retrospect around it ‑‑ start out a notion like, “Hey we failed, how can we do better about it”? I have seen many retrospectives where it’s completely shoved under the rug or brushed over.

Clayton: There were some colossal failures but…

[cross talk]

Do Not Ignore Failure

Roy: Nobody wants to talk about it, it’s really painful and it’s conflict and probably there is going to be some finger pointing and yelling and pent‑up emotions. I would expect a high performing team, as much as you say it, failure shouldn’t be that big a deal so you can learn from it. On the other hand, neither should failure be a total non‑issue, right?

You shouldn’t ignore a failure and be, “Oh, whatever. We failed. We’ll fail again next week. We don’t really care about hitting our commitment anyway.” You have to find a balance and hopefully, the team cares enough to at least get somewhat passionate about making sure it doesn’t happen again.

Clayton: It gives them a really concrete thing to use for inspect and adapt, I think. I’ve always felt that as a Scrum Master, if there was a sprint failure, depending on what the circumstances are, as a facilitator you’re not going to go and force them down some path.

As the Scrum Master, there may be a responsibility ‑‑ you have to bring things to light, to really call out the 100 pound gorilla in the room and say, “Hey, I think we’re not talking about all the issues,” or maybe format the exercise or facilitate in a certain way, so that some of those things can come to light.

Hitting Commitments Is Possible

Roy: That is interesting, though, because I found that most teams don’t even believe that consistent success is possible. I know I didn’t believe that myself back when we were doing contracting work with Integrum. I always thought that Derek and Jade kept pushing us to try to hit our sprints continually.

I was like, “You know, that’s a nice ideal, but that’s not actually reality.” It wasn’t until I was on a team where we consistently hit our sprint week after week for months at a time and we had one failure and it was a big deal, but then we were right back on track again. It’s truly possible, but I know that until that happened to me, I did not believe it.

Clayton: One of the interesting things about that specific example was the answer to “The sprints are failing,” was not, “Work harder.” It was, “Do less until you start succeeding.”

That’s one thing that a lot of teams…I’ve seen teams that will fail weeks at a time, but then, they consistently commit to big chunks of work. Rather than saying, “Hey, maybe we need to slow down to go fast, so let’s do less and less until we are successful.”

Roy: Well, product owners, especially are really, really touchy about that. “Wow, these guys have $100 of capacity and they are committing to only 50 percent of that. All this wasted money and time. What do I do about that”? Then, the reality is they probably were only going to get 50 percent of the capacity done anyway.

Clayton: Right. If they’re failing they might.

Roy: They commit to a whole bunch, but they only hit a percentage of that. Maybe it makes sense to…Maybe what they’re doing is not committing to less, but committing to exactly what they are capable of.

Consistency Can Be Valuable To A Product Owner

Clayton: If I’m the product owner and I’m working with a Scrum team or on the Scrum team, I would prefer for my purposes to have something that was a little more consistent. So rather than be lied to every week ‑‑ and not maliciously lied to, but rather than have some rosy optimistic outlook of what this sprint’s, “Everything should be great this time around.” ‑‑ I’d rather have the realistic thing. If that means going slower and…

Roy: But, you’re not really going slower, right? You’re just not promising to go as fast.

Clayton: It appears that I’m going slower.

Roy: Sure.

Clayton: If that’s the case, I’d rather have reality that makes my prediction stuff much easier. Then, I think, that’s another place where inspect and adapt comes in, where you can find ways or with the Scrum Master and whatever the team can improve, so that they can go faster hopefully. But whatever their pace is, that’s all I’m going to get. I would much rather know what the reality is.

Roy: I agree ‑‑ it makes it a lot easier to improve over time because if you commit to your full capacity, then you have to go from zero to 100 percent immediately, right?

You either fail your sprint or you hit your sprint. But, if you can slide that capacity down to what you can actually hit, then you can slowly move that up and you have much more opportunity for incremental growth, rather than an all or nothing thing. Then you can slowly work your way up to 100 percent.

Changing Commitment In The Middle Of A Sprint

Clayton: One more bonus question before we go. If a Scrum team has committed to 10 stories and it’s the last day of their sprint and they realize they are not going to get the last two things done, and they say, “Oh, Mr. Product Owner, we’re not going to get these three, two things done, can we take that out of the sprint”? If they took them out, will you count that as a success or failure?

Roy: I would count that as a failure because at the beginning of the iteration, they promised to get those things done. It’s a bit of a gray area, so if they realize on day one of the iteration that those two things weren’t going to get done, that would be totally different than if they realized 10 minutes before the demo.

Clayton: I’ve never seen that street go two ways. I’ve only seen it where the team asks if they can have things removed, but when they finish, I don’t ever think I’ve seen a team that says, “Bring it on. Give me more stuff. We can’t wait to get more things.”

Roy: I’ve seen both, but it definitely never happens at the beginning of the iteration that they say, “OK, give us more stuff.” Sometimes, towards the end, I’ve seen teams finish the iteration in half the time and then, pull in a little bit additional work…

Clayton: OK. That’s good.

Roy: …and demo that as well. Now, if they didn’t manage to accomplish all of the additional work before the demo, I would not consider that a failure.

Clayton: To me, that says topic for another episode. All right. Thanks.