Quality Commitment At Every Step

The Agile Manifesto states that continuous attention to technical excellence and good design enhances agility. This principle emphasizes the importance of quality as a foundation for achieving business results. Organizations prioritizing quality can improve productivity by reducing rework, technical debt, and production issues. Quality commitment should never be an afterthought, especially when aiming for long-term success.

In this post, we discuss the best practices of Organization Focus on Quality. Following the foundational techniques at different stages of your learning journey, you can ensure to learn about the best strategies to bring back to the team. However, Organization Focus on Quality is just one part of the big picture, if you want a holistic view of your organization's current process status, take advantage of our free agile assessment for Organization Business Agility.

Organization Focus on Quality and The Learning Journey

The ability to assess the organization’s holistic commitment to quality and the ability to include it in each step of the process. At Lean Agile Intelligence, we refer to this process as the Organization Focus on Quality. Our learning journey consists of four stages - Developing, Emerging, Adapting, and Optimizing - and in this post, we will delve into each of these stages, offering practical insights and strategies to help you improve your skills in this area.

Source - Who Owns Quality in Agile?

Developing

An Organization "developing" an understanding of the value of the Focus on Quality practice and adopting the foundational techniques should focus on the following improvements:

• The What: All organization members have a holistic view of quality and feel accountable for it

  • The How: An XP practice that can help to achieve these criteria is called "collective ownership" which encourages everyone to contribute new ideas to all segments of the product. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottleneck for changes. See XP.com for more details

• The What: Organization agile teams have dedicated QA skilled people (i.e., testers)

  • The How: A definition of done should define what it means for work to be "potentially shippable." This certainly needs to include testing, and it should be done by people with the skillset. In most organizations, passing acceptance testing is required before being considered potentially shippable. We have a blog post that covers the definition of done in-depth, which can be found here.

Emerging

An Organization “emerging” beyond the foundational techniques of the Focus on Quality practice and embracing it as they become more proficient should focus on the following improvements:

• The What: The organization has shared quality standards beyond the Definition of Done, such as checklists, templates, and test case repositories

  • The How: It's a good idea to create production readiness checklists and a single source of truth for test cases and testing information. This can help simplify where to find information, enhance traceability, and include application standards, designs, UX requirements, functional and non-functional tests, and more.

• The What: The organization considers non-functional requirements from the very beginning of products/ initiatives

  • The How: It's a good practice to consider NFRs or "Non-functional requirements" when writing Features and PBIs. NFRs define system attributes such as reliability, scalability, security, performance, and more. They act as constraints to the system and should be discussed before a Feature is broken down into story form.

*   *   *   *   *   *

"Teams need to be aligned and in sync when it comes to an understanding of what "done" means."

*   *   *   *   *   *

Adapting

An Organization “adapting” the Focus on Quality practice to extract the full benefit should focus on the following improvements:

• The What: Refactoring technical debt is required for widely-used/high-volume products when making changes to an outdated piece of code
  
  
  • The How: Refactoring helps improve the design of an existing codebase. When working with code that is outdated or doesn't have a high amount of automated test coverage, it's a good idea to refactor and write unit tests and other tests needed to become up to date with current code standards. In our recommended book "Refactoring" Martin Fowler describes the process of refactoring and spends most of its time explaining how to do the various refactorings - the behavior preserving transformations. The book opens with a simple example that describes the whole process. Then, some introductory chapters discuss broader issues around refactoring; the "code smells" suggest refactoring and the role of testing. You can find that here.
    
    
• The What: The organization has a pyramid-based test strategy that is baked into their Definition of Done; it includes unit tests, integration tests, acceptance tests, and UI tests.

  • The How: The "Agile Testing Pyramid" best described in this article is a metaphor that tells us how to group software tests into different granularities. Start with where you are using this metaphor and add where you want to be to your definition of done. For example, if you currently have a low percentage of unit test coverage, create criteria in your DOD about future code coverage that the new code should adhere to.

Source - Agile Test Pyramid

Optimizing

An Organization “optimizing” the knowledge sharing of the Focus on Quality practice learnings across the enterprise should focus on the following improvements:

• The What: The organization is actively practicing with Acceptance Test Driven Development (ATDD) and Behavioral Driven Development (BDD)

  • The How: ATDD and BDD are no longer an experiment but part of the Multi-Team Effort's culture and part of the Multi-Team Effort working agreements and DOD.

    • ATDD is a form of TDD that focuses on writing higher-level tests and using TDD to make them pass. A modern and common practice among agile teams that is an extension of ATDD is called Behavior Driven Development or BDD. While often thought of as a way to write automated tests, BDD is much more than that and includes a process in which testers are involved in writing product backlog items.

    • "BDD is a way for software teams to work that closes the gap between business people and technical people by:

      • • Encouraging collaboration across roles to build a shared understanding of the problem to be solved

        • Working in rapid, small iterations to increase feedback and the flow of value

        • Producing system documentation that is automatically checked against the system's behavior

    • We do this by focusing collaborative work around concrete, real-world examples that illustrate how we want the system to behave. We use those examples to guide us from concept through to implementation, in the process of continuous collaboration." - Source Cucumber.io

*   *   *   *   *   *

"When working with code that is outdated or doesn't have a high amount of automated test coverage, it's a good idea to refactor and write unit tests and other tests needed to become up to date with current code standards."

*   *   *   *   *   *

Conclusion

In conclusion, quality should never be an afterthought when it comes to achieving business results. By focusing on quality from the start, productivity can improve with less rework, technical debt, and production issues. The Agile Manifesto emphasizes the importance of continuous attention to technical excellence and good design to enhance agility. The recommended tips and techniques provided for developing, emerging, and adapting organizations can help strengthen their skills in this area. Take a free assessment for Organization Business Agility at Lean Agile Intelligence to discover your organization current process status in order to select the right strategies to drive outcomes.