The only purpose of doing Scrum is to create a DONE Increment. To get to a DONE Increment, quality is key. In Scrum Teams, the Definition of Done enables transparency around quality and releasability of the Increment. However, more often than not the Definition of Done stops at meeting acceptance criteria and completing a few levels of testing. But is that enough to make the product increment releasable; of highest possible quality? Maybe or maybe not.
What is Integrity?
When trying to create an awesome product, often software teams focus a lot on the quality of the product. This quality however mostly revolves around one aspect and that is - Testing. How much testing is completed and what all kinds of testing is performed. In Scrum Teams, the “Definition of Done” determines the quality and releasability of a product increment. I can bet that most of you might have seen a DoD which looks something like the following:
- All acceptance criteria is met
- Code is peer reviewed
- Code coverage >85%
- Coding standards followed (in my case when I was developer we followed PSR standards)
- Naming conventions followed
- Unit tests completed
- Integration testing Done
- OWASP tests performed
- All data sent is encrypted.
- SQL injection tests performed.
But is this really enough to make your product market ready? Not always. This may ensure that your developers are taking enough measures to create a good quality code but that might not necessarily mean that it is also a great quality product.
This is where Integrity kicks in. Integrity of a product goes beyond the usual testing. Integrity of the product not only encompasses the quality of product but also covers the reliability, consistency and trustworthiness of the product.At times it might also go in the realm of ethics. In the book “Lean Software Development”, Mary and Tom Poppendieck classify this further as Conceptual Integrity and Perceived Integrity.
Conceptual Integrity
Conceptual Integrity refers to the consistency and cohesiveness of the product. It is like having a really clear, consistent, and well-thought-out blueprint. It means all the parts of the system fit together logically and serve a purpose. There is a clear unifying vision for the product.
Ex: Zoom, each component simply works. All its features are connected through a common idea. There is a predictable behaviour of each component, nothing seems out of context and mostly it is easy to use.
For Scrum Teams to create Conceptual Integrity the following factors may help:
- Having clarity of Product Vision and Goals
- A stringent Definition of Done
- Technical Excellence
- Continuous Feedback
- Collaboration and Communication
- Systems Thinking
Perceived Integrity
Perceived Integrity has more to do with how the user perceives the product. It is the experience of the user with the product. This has to do with the user’s perception of the product’s quality, reliability and trustworthiness. Does the product deliver on what it promised? A few things that typically fall under this category include ease of use, reliability, UI/UX, accessibility, intuitiveness, cost effectiveness and timeliness.
If we go back to the Zoom example, for me, the user friendliness is just great; plus the responsiveness of the product. For ex: if I compare the experience of sending people into a breakout session of Zoom and Microsoft Teams, then the breakout sessions in Zoom simply work seamlessly while on Microsoft teams it takes a few seconds before the people actually move to the breakout.
For Scrum Teams to create Perceived Integrity the following factors may help:
- Focus on User Experience
- Customer Centric Design
- Attention to Details
- Performance and Reliability
- Professional Approach
Build Integrity In
If Scrum Teams have to create valuable and useful product increments every Sprint then they are required to focus on building the integrity of the product from day 1. It cannot be left for afterwards or as an afterthought; as was common in traditional development where coding followed analysis, testing followed coding, compliance followed testing and so on.
As mentioned above, for Scrum Teams Definition of Done is the holy grail of transparency of the increment. In order to create a valuable product increment, this Definition of Done needs to evolve in a way that it ensures perceived as well as conceptual integrity of the product along with the focus on quality.
Here are a few factors that might help in making the DoD stringent.
- Code Quality:
- Code adheres to established coding standards (e.g., PSR for PHP).
- Code has been reviewed by at least one other team member.
- All unit tests pass with 100% coverage for critical paths and at least 80% overall.
- No code smells or technical debt introduced (or existing technical debt addressed as planned).
- Architecture and Design:
- All architectural decisions are documented and reviewed.
- Design principles adhered to (e.g., SOLID principles, DRY principle).
- API documentation updated.
- Testing:
- Integration tests pass.
- Performance tests meet defined benchmarks.
- Security vulnerabilities addressed.
- User Acceptance Testing (UAT) completed and signed off by the Product Owner (or representative users).
- Usability:
- Key user flows tested for usability and approved by the Product Owner (or UX specialist).
- User interface adheres to established UI/UX guidelines.
- Performance:
- Page load times meet defined performance targets.
- Application responsiveness tested and acceptable.
- Visual Design:
- Visual design elements consistent with brand guidelines.
- UI reviewed for visual consistency and polish.
- Documentation:
- User documentation updated to reflect changes in the increment.
- Release notes prepared.
- Other:
- Increment deployed to pre-prod or prod environments for final verification before going live.
- Database schema migrations reviewed and applied (if applicable).
- All dependencies updated and compatible.
Conclusion:
A product succeeds in the market if and only if it solves the real business problem and does it with integrity. Having a keen focus on building integrity in the system from day one is important to create valuable and useful products. Also, it is important to understand that Integrity goes beyond the usual testing.
PS: Some of the things I mentioned as guidelines for DoD if not paid attention to might become vanity metrics; specially things like passing % of unit tests or tech debt.