ScrumBut: Failure to Deliver

I'm frequently disturbed by the ease with which ScrumBut teams allow unfinished features to slide from one sprint into the next, creating a pattern of failure in meeting their sprint commitments—a pattern that the team considers acceptable. In these environments, it is normal to overhear quotes such as "Don't worry about it. We'll just finish it up in the next sprint," and "It's no big deal. We always have two or three stories that we don't finish." As Temple Grandin would say, "Bad is the new normal."

The failure to meet commitments should not be considered acceptable. If your Scrum team is doing this, please reconsider.

When I teach Scrum, I tell the new teams two things: 

  

1. It is OK not to meet your sprint commitment.
2. It is NOT OK not to meet your sprint commitment.

They are both true statements. The following F. Scott Fitzgerald quote explains the importance of the dichotomy: "The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function. One should, for example, be able to see that things are hopeless and yet be determined to make them otherwise."

It is OK to fail to meet your commitment when the team is new, or if unforeseen problems prevent getting to done, or if external issues like layoffs or natural disasters cause a slowdown. Every team—even a seasoned one—will miss meeting its sprint commitment on occasion.

But if the team has been working together for a while and knows how much it can complete on average in a sprint, then it is NOT OK to establish a pattern of not keeping your promise. A commitment is a promise. In Scrum, committing to a sprint is a promise to do the best you can to deliver what the team collectively said it would deliver in that sprint. If the Scrum team takes a lackadaisical attitude toward its sprint commitment, it means either that team members don't understand the meaning of the commitment or that the meaning has been altered to mean something else entirely. If it means something else, the team has moved away from the Scrum framework and values and into ScrumBut territory.

This ScrumBut practice is often indicative of the corporate culture. For some organizations, letting things slide and not keeping promises is simply in keeping with company values. Does that make the slippage OK? Absolutely not. It does speak to an organizational issue that should be addressed, which is one of the things that Scrum does so well: It makes problems highly visible very quickly, so that they can be resolved. If the corporate culture is accepting of this lackadaisical "We suck less" paradigm that tends to breed ScrumBut teams, then its leadership and vision should be questioned.

Regardless of the company's culture, teams should think of their sense of personal integrity and pride in delivery to overcome this ScrumBut practice. The sprint retrospective is a good place for the team to address this.

Remember that the ultimate determination of whether or not failure to meet sprint commitments is acceptable behavior is up to the team. The ScrumMaster can force neither a team nor individuals to adopt a set of values that drive their behaviors. The team must want to make this change on its own. It takes a confident ScrumMaster to hold up a mirror to the team and be willing to ask the questions that will make the team consider its actions and the ramifications. Asking the team, "Is it OK for us to make a promise and then break it?" undoubtedly will make the team feel uncomfortable, but it is a fair question.

The ScrumMaster also may want to make sure that the team is aware of the five values of Scrum: Commitment, Openness, Focus, Respect, and Courage. You can try an exercise with the team using the template "We believe in (value), therefore we will (do something)." Ask the team members to brainstorm on what they believe in and what they plan to do about it. An example outcome from one team might be "We believe in Respect, therefore we will not raise our voices in anger but instead will discuss our differing viewpoints calmly and with open minds." Or, for this particular ScrumBut issue, a team may come up with "We believe in Commitment, therefore we will do whatever it takes to deliver on our promises to the business and to our customers." Using the five Scrum values as a starting point, the ScrumMaster can lead the team in the creation of a set of team working agreements, or value statements, that will drive its behaviors. The team creates these, and the ScrumMaster facilitates the discussion.

Later, if the team reverts to old habits and once again takes a laid-back approach to Commitment, the ScrumMaster can simply ask the team, "Is this in keeping with our working agreement on Commitment?" Part of the ScrumMaster's job is to remind the team of the decisions it made.

Don't accept persistent failures to meet sprint commitments. Question why and how the team came to accept this behavior as normal, and together make a real commitment to change for the better.