I believe in being pragmatic. I don't so much see Scrum as a set of rules but rather as guidelines. I'm not inclined to worry about exactly how things should be done but rather about the reason behind why they are done in that manner. In short, I like to do things because they make sense.
Let me take a simple example -- standing up in stand-ups. Do you really need to stand up during these meetings? Of course not! The intent of standing up is simply to assist in running an efficient meeting. If you can achieve this without standing up, then great. Once you understand the reason why you are doing something, you can then decide whether it is something you can, or should, compromise on. Which brings me to my topic, which is that quality
is not one of these things!
One of the greatest benefits of the Scrum framework is that there is a focus on quality throughout the entire process. It is not something that you retrofit into the product or service as the last step before handing it over to the customer. So, you say, why would anyone ever ask you to compromise on quality when delivering a product or service? Simply, it is a combination of business pressures and a degree of ignorance about Scrum and the quality of benefits derived from it.
I know for some of you the idea that that may happen will seem ludicrous, but often with the need to meet scope and deadline expectations, teams are asked to ignore outstanding defects and move on to the next story posthaste. The thinking being is that ultimately more functionality will be delivered and we can then address outstanding defects in a hardening sprint at the end of the project. In the words of Rocky the Flying Squirrel, "But that trick never works!"
The assumption is that velocity will be higher because we are able to close out stories more quickly. From a simple calculation perspective, this is true. The reality is that the story isn't really "done, done," and therefore the velocity measure is now meaningless. Definitely, product owners and stakeholders will start to see more features and functions more quickly. This can provide a sense of reassurance, but we have now built a significant back-end component to the project and lost much of the agility that Scrum seeks to provide.
So let's explore further why it isn't a good idea, so that when it happens to you, you are prepared to push back in an educated and constructive way.
The defects need to be addressed at some stage, and now is the best time to do it. The team members are in the right headspace. If you leave it till later, they need to reacquaint themselves with the function and code, and they also need to contend with countless other issues that will likely further complicate pinpointing the cause of the problem. It will cost you less to address defects at the time they are encountered, as opposed to later.
The team develops a mind-set that minor issues are insignificant during development. Coders and testers will knowingly not address pieces of function, as they'll worry about that later. "Oh, don't worry that the scroll bar doesn't work properly. We'll fix that later." The team stops striving for potentially shippable code at the end of a sprint.
Continuous integration becomes less productive. You start to integrate flawed functions into the build, then dependent stories are developed on top of those. Particularly, with defects in infrastructure components, it can lead to confusion as to whether an issue in a new story is in fact new or is caused by the existing issue. Much time and effort will be wasted throughout the rest of the project dealing with this scenario.
Automated testing will either continue to highlight issues or bypass tests. The ability to continually run automation against features and functions will be compromised. The longer you can test something, the more likely issues will be identified. The value of developing test automation is that, once developed, there is very little cost in terms of time and effort to run it. The longer you run test automation, the higher the confidence level of producing a quality deliverable.
Finally, I remember being in a meeting with peers where we were discussing producing better-quality code. When someone suggested that they were going to achieve this in a project by having two hardening sprints instead of one, I didn't know whether to laugh or cry.
Ultimately, I chose to speak up and educate. Not everyone is as invested in Scrum as those of us who read these articles. What is obvious to us is not necessarily so to others. As coaches, mentors, and advocates of Scrum, it is our job to understand what we shouldn't -- and can't -- compromise on and to be ready to defend our position with a clear understanding of why. So, while standing up in a stand-up may be negotiable, the adoption of Scrum provides a mandate to ensure that addressing quality concerns immediately is not.