One of the arguments used against Scrum and a common misconception at the same time is the idea that quality is traded for speed in Scrum. As a PST with years of experience in Quality Assurance I decided to challenge this myth. I believe and I have seen many times that proper way of implementing Scrum leads to higher quality products delivered faster than using so called traditional methods. 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.
Lets 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.
I can see how person learning about Scrum and Agile mindset can come up with wrong conclusions by relating her current context to proposed values, principles and rules. Besides of 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? 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 quality of product and each team member has equal responsibility regardless his or her specialization. The Development Team composition should be optimize to deliver potentially releasable product Increment. Therefore the Developers need to have testing skills. Of course some of them will be better at testing, some will be less good. But nevertheless the testing skills will be in the team.
The potentially releasable Increment needs to be in usable state and work well with the previously delivered increments. Therefore all the work should be tested in regards of 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 it is transparent to everyone involved what is actually Done and what does it mean that a Product Backlog Item is Done.
With the concept of definition Done comes another misconception. Who is deciding on 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 conclusion that in that case the Development Team will come up with the most easy and comfortable definition from their point of view. They will leave the tough part out. But, 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 or what is it based on? There should be some existing conventions, industry standards and company policies in place. And 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 potentially releasable state of product Increment. We want to have ready to release 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.
I am perfectly aware that you can meet teams which claim to do Scrum and have low quality products. I have seen teams which started new work with Scrum and quite quickly run into maintenance or bug-fixing issues. I have also seen teams which converted the current project to Scrum way of working and could not deliver a proper product Increment for many Sprints. So it is quite easy to draw conclusions that with doing Scrum quality suffers. Yes, I have seen it as well. But, still it is a pretty far leap to draw conclusion that it is 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 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 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.
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/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.
Many projects failed because someone did not tell about something important or was misunderstood. One of the areas where issues with communication are most visible are 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? One could shout "User Stories!” While writing User Stories is popular with Scrum, it is not 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 the form is 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 collaborative effort by 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. Anyhow, there is still some room for misunderstanding. When are we going to be sure that what the Development Team built the right thing? On the Sprint Review we actually show the new product Increment and give opportunity to stakeholders and the Scrum Team to collaborate on what was done in this Sprint and what is the Development Team going to next.
Everybody seen products which did not perform well in 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. Primary way of fighting with the debt is having 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 transparent definition of Done which is taken very seriously. Product Backlog Item at the end of 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 happens when teams are pushed against unrealistic deadlines. In Scrum the Development Team estimates the size of work and collaborates with the Product Owner on forecast for 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 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.
We went through reasons for coming up with idea of low quality in Scrum. We explored the idea of quality. But 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. Focus on delivering potentially releasable product Increment each Sprint encourages early and often integration usually implemented in form of continuous integration practice. Stakeholders, Product Owner and Development Teams are closely collaborating, which gives short feedback loops and short communication lines. And remember Scrum is not a way to deliver fixed scope faster, but to deliver more value more often in the most optimal way.
Origins of the low quality myth
Lets 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.
Looking for low quality in theory
I can see how person learning about Scrum and Agile mindset can come up with wrong conclusions by relating her current context to proposed values, principles and rules. Besides of 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? 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 quality of product and each team member has equal responsibility regardless his or her specialization. The Development Team composition should be optimize to deliver potentially releasable product Increment. Therefore the Developers need to have testing skills. Of course some of them will be better at testing, some will be less good. But nevertheless the testing skills will be in the team.
The potentially releasable Increment needs to be in usable state and work well with the previously delivered increments. Therefore all the work should be tested in regards of 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 it is transparent to everyone involved what is actually Done and what does it mean that a Product Backlog Item is Done.
With the concept of definition Done comes another misconception. Who is deciding on 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 conclusion that in that case the Development Team will come up with the most easy and comfortable definition from their point of view. They will leave the tough part out. But, 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 or what is it based on? There should be some existing conventions, industry standards and company policies in place. And 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 potentially releasable state of product Increment. We want to have ready to release 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.
Looking for low quality in practice
I am perfectly aware that you can meet teams which claim to do Scrum and have low quality products. I have seen teams which started new work with Scrum and quite quickly run into maintenance or bug-fixing issues. I have also seen teams which converted the current project to Scrum way of working and could not deliver a proper product Increment for many Sprints. So it is quite easy to draw conclusions that with doing Scrum quality suffers. Yes, I have seen it as well. But, still it is a pretty far leap to draw conclusion that it is 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 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 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/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 failed because someone did not tell about something important or was misunderstood. One of the areas where issues with communication are most visible are 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? One could shout "User Stories!” While writing User Stories is popular with Scrum, it is not 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 the form is 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 collaborative effort by 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. Anyhow, there is still some room for misunderstanding. When are we going to be sure that what the Development Team built the right thing? On the Sprint Review we actually show the new product Increment and give opportunity to stakeholders and the Scrum Team to collaborate on what was done in this Sprint and what is the Development Team going to next.
Quality by high quality work
Everybody seen products which did not perform well in 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. Primary way of fighting with the debt is having 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 transparent definition of Done which is taken very seriously. Product Backlog Item at the end of 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 happens when teams are pushed against unrealistic deadlines. In Scrum the Development Team estimates the size of work and collaborates with the Product Owner on forecast for 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 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 idea of low quality in Scrum. We explored the idea of quality. But 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. Focus on delivering potentially releasable product Increment each Sprint encourages early and often integration usually implemented in form of continuous integration practice. Stakeholders, Product Owner and Development Teams are closely collaborating, which gives short feedback loops and short communication lines. And remember Scrum is not a way to deliver fixed scope faster, but to deliver more value more often in the most optimal way.