This week I have been thinking about how to set up conditions that increase the quality of software produced by engineering teams. This is a universal challenge but it does not seem to be well documented so I will share some thoughts about a “Quality Framework”. I hope they are useful.
A basic principle is that a Quality Framework must touch all aspects of the SDLC (Software Development Lifecycle). For example, a super rigorous code review process without clear expectations on testing changes during development and in production will not be effective.
Many (but not all) aspects of a Quality Framework are linked to a specific component of the SDLC and so the SDLC is a nice way of illustrating a Quality Framework. I will use Agile because it is so widely known.
There are other components of a Quality Framework which are not tied to the SDLC. Here are some important examples:
- Everything has an owner, and it is written down.
- Teams have a clearly defined domain and they own it for the long-term.
- Blameless post-mortems (and the culture of psychological safety that they engender).
- Hiring the right people, identifying poor performers and letting them go.
That’s it - I hope it makes sense and is useful. Of course it is possible to build highly elaborate frameworks to set the conditions for software development of a high quality — but my instinct is that the 80–20 rule will come into play. Get the basics right, tweak for your particular context and you’re in good shape.
If I have missed anything significant please leave a comment and I’ll look at including it.
Thanks for reading!
