Scrum Myths: Quality Is Traded for Speed in Scrum
Scrum Myths: Quality Is Traded for Speed in Scrum
Remember: Scrum is not a way to deliver a fixed scope faster, but a way to deliver more value, more often, in the most optimal way.
Join the DZone community and get the full member experience.Join For Free
One of the arguments used against Scrum (and a common misconception about the practice) is the idea that quality is traded for speed in Scrum. As a PST with years of experience in Quality Assurance, I have decided to challenge this myth. I believe — and have seen — that proper way of implementing Scrum leads to higher quality products delivered faster than using so-called traditional methods. In this article, I will look into reasons for coming up with ideas of low quality in Scrum. Then, I will explore the idea of quality. Finally, I will explain how Scrum supports high-quality products.
Origins of the Low-Quality Myth
Let's think for a moment where the myth is coming from. Looking into my experience as coach and trainer, I can see two sources: one theoretical and the other practical.
Low Quality in Theory
I can see how someone learning about Scrum and Agile could come up with incorrect conclusions by relating the current context to proposed values, principles, and rules. Besides the Scrum Master and Product Owner in a Scrum Team, we have Development Team, which consists of developers. The wrong conclusion to make out of it would be, “I don’t see a testing team nor testers in the Development Team, so there is no testing in Scrum.”
The truth is that cross-functional Development Team should have also testing skills. Who is a tester, anyhow? A tester is a professional within software development process responsible for conducting testing activities. We have also testing specialists equipped with testing skills. In Scrum, we don’t want to have a role named tester in the Development Team because it would lead to a person with that role being responsible for testing. The whole Development Team is responsible for the quality of the product, and each team member has equal responsibility regardless his or her specialization.
The Development Team composition should be optimized to deliver potentially releasable product increments. Therefore, the developers need to have testing skills. Of course, some of them will be better at testing and some will be less good. Nevertheless, the testing skills will be in the team.
The potentially releasable increment needs to be in a usable state and work well with the previously delivered increments. Therefore, all the work should be tested in regards to business requirements and integration. The increment needs to be done, which means it needs to meet the Definition of Done. This way, we can ensure that what is considered to be "done" is transparent to everyone involved.
With the concept of the Definition of Done comes another misconception. Who is deciding the content of the Definition of Done? The Development Team decides on the appropriate Definition of Done for the product they build. One can come up with the conclusion that in that case, the Development Team will come up with the easiest and most comfortable definition from their point of view. They will leave the tough part out.
However, why would software professionals do that? Let’s leave that question for your own consideration. I have a better question for you. Where does the Definition of Done come from and what is it based on? There should be some existing conventions, industry standards, and company policies in place. These are the cornerstones the Development Team should build the Definition of Done on.
More than that, the standards and work described in the Definition of Done should reflect te potentially releasable state of product increment. We want to have ready to release the product every Sprint. This way the Definition of Done will be stronger than the guideline used before and mandated each Sprint instead of at the end of the project.
Low Quality in Practice
I am perfectly aware that you can meet teams that claim to do Scrum and have low-quality products. I have seen teams start new work with Scrum and quite quickly run into maintenance or bug-fixing issues. I have also seen teams that converted the current project to Scrum way of working and could not deliver a proper product Increment for many Sprints. It is quite easy to draw conclusions that with doing Scrum quality suffers.
However, still, it is a pretty far leap to draw the conclusion that it is the fault of Scrum. Are you sure that the same team would perform better using a different way of working? Would they deliver more not doing Scrum? How do you know that what they are doing is Scrum? Maybe it is Scrum but is actually created by removing events, roles, or artifacts. Doing Scrum is difficult in practice and it takes a lot of effort to go beyond mechanics by living Scrum values. Scrum doesn’t make a promise to solve all the problems in teams or organizations. Scrum shows how effective their current practices are in building the desired results. It is their choice to improve the practices or modify Scrum to show less.
The What and How of Quality
There is no need to open discussion and run into endless disputes when we have already coined definition handy. After IEEE 610, quality is the degree to which a component, system, or process meets specified requirements and/or user and/or customer needs and expectations. Assuring high quality is more than testing and fixing bugs when the requirements are implemented. We should optimize the whole process to create high quality with as little defects as possible.
Quality by Meeting Requirements
Many projects fail because someone did not tell someone else about something important, or the point was misunderstood. One of the areas where issues with communication are most visible is in requirements. The best requirements written single-handedly is always a subject to open interpretation by the one implementing them. Direct communication and short feedback loops are the only effective way to make sure the Development Team will deliver the right thing.
How are requirements specified in Scrum? User Stories! While writing User Stories is popular with Scrum, it is not a required practice. Since the Product Backlog is the only source of work in Scrum, functional and not functional requirements should be placed there in any form comfortable to work with for all the stakeholders. Why is form important? Because in Scrum we want to have all the stakeholders understand what is on the Product Backlog and collaborate on requirements. Product Backlog items are refined in the collaborative effort by the Product Owner and Development Team. This way is Scrum we make sure everyone is on the same page and we collect ideas from multiple points of view.
During the Sprint, the Development Team has a direct access to clarify and negotiate Product Backlog Items being worked on. There is still some room for misunderstanding. When are we going to be sure that what the Development Team built the right thing? In the Sprint review, we actually show the new product increment and give the opportunity to stakeholders and the Scrum Team to collaborate on what was done in this Sprint and what the Development Team is going to do next.
Quality by High-Quality Work
Everybody seen products which did not perform well in the production environment or it is difficult to develop further. Doing the right thing is not enough. We need the product to do the right thing right. Maintenance and performance issues are caused by creating and growing technical debt. The primary way of fighting the debt is having a transparent definition of what standards, norms need to be fulfilled and work to be completed for each Product Backlog Item before we call it done. Of course, this is achieved by a transparent Definition of Done, which is taken very seriously. The Product Backlog Item at the end of the Sprint is done or un-done and goes back to the Product Backlog. Multiple Scrum Teams working on the same product will stick to the same Definition of Done so the level of quality will be consistent through the whole product.
Cutting corners and lowering quality of work for speed happen when teams are pushed against unrealistic deadlines. In Scrum, the Development Team estimates the size of work and collaborates with the Product Owner on a forecast for the Sprint. Therefore, in Scrum, the Development Team estimates what can be done keeping the quality on the same level.
When there is high pressure on delivery, people have a tendency to pay less attention to processes and standards. That is one of the reasons why is Scrum we have a role of Scrum Master responsible for understanding and enacting practices and rules.
The Truth About Speed in Scrum
We went through reasons for coming up with an idea of low quality in Scrum. We explored the idea of quality. Still, where is the speed coming from if not lowering quality and cutting corners? Releases are late due to delays caused by late integration, late testing, and bad communication. Cross-functional teams working in Scrum reduce and even completely eliminate the need for work products handovers. Focusing on delivering potentially releasable product increments each Sprint encourages early and often integration, usually implemented in the form of Continuous Integration practices. Stakeholders, Product Owners, and Development Teams are closely collaborating, which gives short feedback loops and short communication lines. Remember: Scrum is not a way to deliver a fixed scope faster, but to deliver more value more often in the most optimal way.
Published at DZone with permission of Krystian Kaczor . See the original article here.
Opinions expressed by DZone contributors are their own.