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.
  

Both types are for me part of the scope of every software development project but it is important to keep in mind, that the quality is not negotiable (I fully agree with Henrik on that). In agile world the change is a normal and positive element of the process. So, for example, after some sprints you may discover that the velocity of your team is not enough to finish the project on time. If you are not able to raise your velocity using additional resources you have to think about scope reduction.

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.
  

Where the official scope reduction often causes reduction of external quality (touching for example user experience), the stealth scope reduction aims internal quality (and in many cases the basement of the application), which could be very dangerous for the further development process of the application (it's like shooting in your own leg).

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:

"Software with high marks for perceived integrity suits you so well that you think the designer must have been inside your head."

I have some thoughts about this sentence and the role of empathy in software development. I'll touch this very interesting topic again soon.

---