At least, that is the theory.

Typically work is not completed at the end of the sprint, and people see regression as a buffer to “finish off things”. This is always a bad approach because the time spent fixing new code in regression won’t be spent regression testing at all. This ultimately means that the next release will contain bugs in not only the new features, but also breaking otherwise reliable features.

2. Failure is Always an Option

Fact is, people are loathe to admit that the sprint has failed. The pressure to not admit that the sprint has failed comes from a myriad of sources, some good, some not so good. The good places tend to be that the team don’t want to let people down, and know that they can fix things if given just a little more time. The not so good places can come from the business, who maybe have promised the feature to a client before the dev team have committed to delivering it (hey, I don’t have a problem with adding pressure to people, but in Scrum it’s the dev team that commit to delivery dates, and if people don’t buy into this and can’t manage their expectations, then disappointment is something they’re going to have to get used to.) irrespective of whether the pressure is good or bad, ultimately to cave in to that pressure is wrong.

To accept that you are jeopardizing the release, you must accept this simple premise:

If you don’t abandon your sprint then you are doing something much worse: you are abandoning your entire process. When you abandon a sprint, what you need it to say is “despite us trying our best, the resulting product just won’t match up to the standard. So we’re drawing a line under it here before we make some bad choices and next sprint it will be a whole lot better because we know the mistakes we made this sprint and we’re going to learn from them.” When you persist on in spite of the facts what you’re saying is “we have no confidence in our process, so we’re going to get it shipped regardless of what the team really fell about us doing this.”

For example, you are given the options of Fast, Good and Cheap, and told to pick any two. Here Fast refers to the time required to deliver the product, Good is the quality of the final product, and Cheap refers to the total cost of designing and building the product. This triangle reflects the fact that the three properties of a project are interrelated, and it is not possible to optimize all three – one will always suffer. In other words you have three options:

I’m not one for management tools, but this one is particularly true and relevant, irrespective of the industry. But I want to go a step further here, because implying every decision will affect all three does not go far enough: because even the very best decisions will affect 1 of these in a positive way and 2 negatively, and for the very worst decisions, it will affect all three of these in a negative way. Chances are any decision made to salvage a sprint when it should be abandoned will be pretty lousy, and can only affect quality in a negative way.

Having re-read this post, I feel that the overall tone has been cynical; pointing out the problems in working in Scrum. And I guess it is. But as a friend once said to me “there’s nothing negative about pointing out problems, it’s only negative if you do nothing about it”. By accepting the problems inherit in how the team behaves only then can you be pro-active in resolving them. How you resolve them pertains to the team and why they fail: maybe your dev:tester ratio is bad, or maybe you are not giving the team the right tool to estimate properly, or maybe even project managers interfere with estimations.

Whatever it is…to finish on another quote: “If you keep on doing what you’ve always done, you’ll keep on getting what you’ve always got.”