Scrum Rules: As a Team Member I am Truthful About the Quality of my Product

Scrum relies on the truthfulness of Team Members to allow for transparency about the internal quality of the product. Internal quality is primarily related to the technical aspects of the product: its design, its architecture, lack of duplication in the code, and the level of coverage of the product with automated tests.

Scrum relies on the professionalism of the Team Members for the proper implementation of this rule. Being upfront, transparent, and truthful about the internal quality of the product allows for the Product Owner to understand how much time and effort the Team will allocate to improving the internal quality of the product and how much will be allocated for new features. This also gives the Scrum Master an opportunity to connect with stakeholders who may be able to help remove technical debt and waste that is continuing to exist. If Team Members are not truthful about the internal quality of the product, over time the system will become more cumbersome, more complex, and more painful to improve. This will also lead to a culture of hiding problems, which is diametrically opposite to the intended use of Scrum: to uncover problems and allow us to solve them. Another downside is that morale will begin to decrease as Team Members care less about the quality of their work. This, of course, will ultimately lead to external quality problems that result in customers being unhappy and looking for someone else to work with.

Creating openness about quality requires at least three core conditions be met: safety to discuss quality problems, objective standards for quality, permission to fix and prevent quality problems in the future.

1. Safety to Discuss Quality Problems can be created in large part with simple structural and behavioural changes within the Scrum Team. The Scrum Master must create effective Sprint Retrospectives, the Product Owner must stay out of solving technical problems, the rest of the team members (the Development Team) must collaborate openly as they work throughout the Sprint, and people outside the Scrum Team must respect the boundaries of the team and not meddle during the Sprint. Additional safety can be created by ensuring high levels of privacy and anonymity in the Sprint Retrospective where quality problems should be discussed. Privacy is ensured by disallowing non-team members from participating, observing or asking about the Retrospective including a publication ban on the results or minutes from Retrospectives. Anonymity is ensured by using techniques in which written feedback about the Sprint is collected and reflected back to the team by a neutral and trusted 3rd party (such as an external coach).
2. Objective Standards for Quality are established by using automated tools to evaluate quality. These tools include unit and behavioural test automation, test coverage analysis, static code analysis tools, code standards and style checkers, security testing, performance testing, build automation etc. It is critical that all of these aspects of quality be measured with automated tools that can provide simple reporting that quickly helps to isolate quality problems. The reports from these tools must be pushed to every member of the Scrum Team on a regular basis… ideally using a Continuous Integration system. As well, the generation of the reports must be quick – at a maximum 10 minutes for a full analysis and delivery of the report.
3. Permission to Fix and Prevent Quality Problems in the Future comes from the highest levels of both the business and technical sides of an organization, and must be reiterated frequently both through formal and information communication. Permission also requires that those giving it do not ever rescind that permission even for a short time (e.g. for “exceptions”). This permission is the fundamental level of empowerment for technical people to take ownership of quality problems, be truthful about them, and, of course, start to fix them.

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment. — The Scrum Guide

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…