Quality and Scope Reduction
I really like the definition of the software quality provided by Henrik Kniberg:
- External quality
is what is perceived by the users of the system. A slow and non-intuitive user interface is an example of poor external quality.
- Internal quality
refers to issues that usually aren't visible to the user, but which have a profound effect on the maintainability of the system. Things like system design consistency, test coverage, code readability, refactoring, etc.
I'm pretty sure this definition is based on the Lean Software Development by Mary & Tom Poppendieck (shortly LSD - I love this abbreviation ;) which outlines perceived and conceptual integrity:
- Perceived integrity
is affected by the customer's whole experience of a system: how it's advertised, delivered, installed, accessed; how intuitive it is to use; how well it deals with idiosyncrasies; how well it keeps up with changes in the domain; how much it cost; how timely it is; how well it solves the problem. Software with high marks for perceived integrity suits you so well that you think the designer must have been inside your head.
- Conceptual integrity
means that a system's central concepts work together as a smooth, cohesive whole. The components match and work well together; the architecture achieves an effective balance between flexibility, maintainability, efficiency, and responsiveness.
Scope reduction comes in my opinion in two flavors:
- Official scope reduction
done together with the product owner. It is a positive effect of an agile. You simply take out, together with your team, the functionalities with the lowest prio.
- Stealth scope reduction
or unofficial scope reduction causes by introduction of shortcuts, quick fixes, workarounds, and temporary solutions and so on done by the team (or even single developers) internally. This is clearly a negative one.
As I written before, both of them are parts of quality and therefore not negotiable. Try to reduce functional scope, review your estimates or priorities if you have to.
But don't touch the quality.
And by the way: It is simply a great motto for us, architects & developers:
I have some thoughts about this sentence and the role of empathy in software development. I'll touch this very interesting topic again soon.