Last night I attended Influencing Quality & tackling the problems that come with it..., a panel webinar hosted by Burns Sheehan and chaired by Nicola Martin. The panellists were:
- Marc Abraham, Head of Product Engagement at Asos
- Antonello Caboni, Engineering Coach at Treatwell
- Marie Drake, Principal Test Automation Engineer at NewsUK
- Pedro Vilela, Engineering Manager at Curve
As you might guess from that line-up the material covered was broader than simply testing, taking in subjects such as quality, value, hiring, and the delivery process across the engineering organisation. The signal to noise ratio was high, so my sketchnotes capture only a few of the points made on each topic.
The idea that quality is a whole team responsibility came up several times. Quality is a notoriously slippery and subjective concept, so in the Q&A I asked whether any of the speakers had ever tried to create a Definition of Quality for their team, something like a traditional Definition of Done.
The answers were all about guiding practice:
- Not tried to get a definition of quality because that's hard. Instead, tried to define principles that drove desirable behaviour.
- Got agreement on the question "what does good look like?" for the project.
- Defined quality at the story level as having an end-to-end test for the functionality described.
I found this interesting not least because my test team at Linguamatics put time and effort into coming up with a set of values that we could use to help us work in ways that we felt were beneficial to us as individuals, our team, and the wider company.
I've thought about quality a great deal over the years and found that I always return to Jerry Weinberg's formulation in which quality is value to someone. Crucially in that, quality is a relative concept.
To see why this matters, take the iron triangle model of quality which was mentioned more than once during the webinar. On a common rendering the sides of this triangle are scope, cost, and time and even if you've never seen the triangle itself you'll have probably heard people say that those factors can be traded, or that it's possible for a project to have any two of them but not all three.
The model is a simplification, as they all are, but one of the things this particular model leaves out is the who. A project team might meet their scope target cheaply and deliver a feature to production in the time required. Quality bar met! But that feature might cost users dearly in time and effort because, say, it's extremely difficult to navigate. Quality bar met?
Anne Marie Charrett gave a fascinating talk on quality a few years ago in which she tried to find a way to balance business value, product quality, and production quality (see Quality != Quality). These essentially give three potential whos to consider the triangle against and, in my view, any non-shallow conversation about quality (and also risk) must think carefully about the perspective from which it is viewed.
The experiences that the panel described in answer to my question, I think, must either implicitly or expicitly have decided who matters in order to promote certain kinds of behaviour and discredit others. My preference would be to make that information explicit and include with it the why so that there's a basis on which to challenge the principles or what good looks like or the need for an end to end test, should the context change.
Comments
Post a Comment