I’ve been working in Scrum several years and am a certified Scrum Master. That sounds great, but it only goes so far in preparing for the challenges I have faced as a Scrum Master. This post focuses on my observations about Scrum and some of the challenges that teams face.
1. Growing Pains
Recently at work we have had a big influx of in the members of the dev team. As we practice Scrum, and the team are kept relatively small (2 devs 1 tester), and the number of project running in parallel using the same code base, the amount of sprints/branches/builds/releases has also increased. Last year, we would release every sprint, and a sprint would last 1 month (including regression). This has changed now to 2 fortnight sprints per release, with regression always a sprint behind: so the work is all completed and merged to Main, we take our RC branch and test that in our Staging/QA Environment over a longer period of time with a dedicated QA team, making changes and merging back to Main.
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.
If there’s one thing worse than no release, it’s a release that breaks everything.
Pushing out a sprint before it is ready is pushing out a release before it is ready, just to a different audience. And this causes friction between the QA team whose job it is is to regression test, and the dev team. It’s seen as throwing trash over the wall and expecting other people to clean it up.
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 let a deadline slip, whether it’s checking in to the Dev branch, or merging to Main, you are increasing the risk of the sprint failing.
Everyone has to buy into this idea. It needs to be implicit in every decision after the dev team has committed to delivering work by a certain time. I’m not saying that if a dev has underestimated 1 PBI and delivers it a few hours late the sprint has failed and needs to be started again: cancelling the sprint should be the last place to go to. What I am saying is that when deadlines have slipped to the point that the testers know that there’s just no way they can get the level of testing done, or that there are too many bugs in the sprint backlog, then the time to pull the trigger on the sprint is at that moment, not 2-3 days into regression.
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.”
3. The Quality Triangle
One of the useful things I remember from my days at university was reading about the Quality Triangle. The concept was that to determine the overall quality of a product, projects need to be performed and delivered under certain limitations. These limitations are
These are also referred to as the Quality Triangle, where each side represents a limitation. One side of the triangle cannot be changed without affecting the others, either positively or negatively. A further refinement of the limitations separates “quality” or “performance” from scope, and turns quality into a fourth constraint.
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:
- Design something quickly and to a high standard, but then it will not be cheap.
- Design something quickly and cheaply, but it will not be of high quality.
- Design something with high quality and cheaply, but it will take a long time.
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.
The title of this blog is taken from a quote in the Simpsons where Lisa buys Al Gore’s autobiography titled “Sane Planning, Sensible Tomorrow.” I took it tongue in cheek when I started writing this post, but really it illustrates my point:
- If you use Scrum as your methodology, accept that failure is always an option,
- Failing a Sprint should be the last good option you have option before bad decisions are made
- Missed deadlines has a cascading affect in Scrum
- Let the Scrum Team commit to their work
- All project have constraints: scope, cost, and time (The Quality Triangle)
- One side of the Quality Triangle cannot be changed without affecting the others
You can read any book about any development methodology, it’s only when you experience can you appreciate it’s strengths, weaknesses, and how to manage those. I’ve worked in several companies who manage their development methodology via Scrum, and they all do it differently. The one thing they all do exactly the same is abandon the process rather than abandon a sprint in the hope that they can salvage it. Whatever the motivation for this, it usually causes the quality of the sprint to suffer.
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.”