One of the things I’ve always hated about scrum is the way it’s taught. It’s, “here’s the actions you take to practice Scrum”. Nobody ever explains “why”, just “what”. This just leads to dangerous and pointless cargo cult practices. Then there’s that part in there that says you shouldn’t follow it by the book. Well, how are you supposed to know what’s worth changing or keeping if you don’t even know why you’re doing it? In this article, I plan to teach you why scrum has the processes that it does.
Before I begin, I want to make it clear that I’m not a Scrum evangelist. Scrum is a tool that’s supposed to help you get the job done. If it’s helping you achieve that goal, great. If it’s not, feel free throw out the whole thing. I don’t care either way. I guess I’m saying I don’t have a personal agenda to promote Scrum. I’m just trying to solve a problem with the way it’s taught.
I’m going to use The Scrum Guide as a reference to this article. You may want to read it if you haven’t done so already. It’s just like everything else scrum related: It tells you “what” to do but not “why”. But, it was written as a reference, not a tutorial, so I’m not going to hold that against it.
The Definition of “Done”
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.
But, what does “Done” mean? Well, if it’s poorly defined it can mean a number of things. In fact, it can mean a number of things to different people in the same organization. That means that when a developer says a feature is “Done”, someone from QA could disagree. If that developer tells the Product Owner (who has a 3rd definition) he’s “Done”, he may tell the customer to expect to be able to use the feature tomorrow. If that feature isn’t high quality, it will break in the customer’s hand and backtracking will ensue. Scrum has a rule that is meant to prevent this whole thing from happening:
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means
That means everyone is on the same page and miscommunications don’t occur because of assumptions about what “Done” means. It also prevents this lame trick that developers tend to do: They write the code as fast as possible without even checking if it works, throw it over the fence to QA and tell others the feature is “Done”. Developers do this because it buys them time to work on other things and it gives the false appearance that they’re more productive or met some deadline. Also, a lot of developers don’t like checking their work so they make QA do it for them.
Ideally, this Scrum rule prevents developers from using this evil trick. If QA says it’s not done until it passes their tests and that is universally agreed upon, suddenly that same developer can’t be so hasty when he says it’s “Done”. He may attempt to pull this off, but QA will send the feature back because it doesn’t work a few times. It’ll only be considered “Done” when QA finally signs off on it. And now, if anyone is paying attention (they should be), this developer who appeared to be so productive turns out to take 2-3 times longer to be “Done” with everything relative to his peers because the time to QA it is considered.
If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.”
This rule is to keep quality high throughout the company. One team may try to slack and call things “Done” that are fundamentally broken, but the odds are low that every Scrum team will agree. This also raises the average bar of quality of the product. This way you don’t have one team who’s constantly breaking things and preventing your team from being productive. Since everyone agrees on what “Done” means, you can say that the other team is doing it wrong. And if all the teams were to agree on a definition of “Done” that is fundamentally broken, Scrum explicitly forbids that, anyway:
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
Conclusion
I hope this has shed some light on “why” Scrum works the way it does. If you don’t like part or all of Scrum, it’s important to understand the theory behind it if you need make a cogent argument against it. On the other hand, if you do like Scrum, it’s important to understand the theory behind it so you can make a cogent argument for it. The worst thing you can do is follow the process of Scrum without understanding “why” you are doing the things you’re doing.