The phrase ‘The team is responsible for quality’ seems to get thrown around quite often, especially when something goes wrong. It holds the team accountable rather than an individual and tries to avoid scenarios like this:
Fictional Manager: “Should we blame the person who has the word quality in their role title?”
Other Fictional Manager: “Seems legit, they’re the ones we made quality explicit with.”
In previous roles, I have been responsible for essentially, asking questions and providing information. In no way was I ever responsible for sign off or for stopping anything going into production. Project managers were held accountable for final release but it was my job to ensure that they were making an informed decision and knew the risks, the likelihood and impact. My responsibility was to know as much as I could about how the system worked, how a user would interact with it, how other systems would interact with it. Testing was designed to provide information about how the system didn’t work as expected, how customers couldn’t interact with it as expected and how other systems couldn’t interact with it as expected, in addition to identifying other things we found out along the way because as we know more, we know more.
For the purpose of this blog, I want to focus on two phases, Analysis and Design and Build because they are most relevant to my day to day experience. Post Release is also a topic in itself!
Analysis and Design
During the analysis and design phase my focus would be on reducing ambiguity, “What do you mean by ‘most of the time’? When would there be a time when that didn’t happen?” and thinking about functions and interactions, “What happens if I refresh the page? Are any of the fields mandatory?”
The reason for asking these questions is so I can understand how the software behaves and how it will be used once it is complete. The questions I ask will be centered around what’s important to me based in my own experience and knowledge so it’s highly likely that a different person will ask different questions to me.
This is where the power of the team comes in. By having different perspectives and areas of importance being addressed in a group conversation, others can help to answer questions. Additional questions that you may not of thought of with your own line of thinking may come up and you’d be surprised at what others know or care about. Asking questions to understand is not a role based responsibility but rather an individual responsibility to give ourselves the best possible chance of success.
This part of software creation is often glossed over in favour of something more tangible however time and time again I’ve seen projects derailed and deadlines blown out because a simple question wasn’t asked earlier on. Asking questions is easy. Asking the right questions is hard so it’s important to practice forward thinking and ask ourselves, ‘What’s really going to hurt me later on if I don’t have clarity on it now?’ Sometimes this is a best guess however past experience should be able to help guide us. Reducing ambiguity increases quality in this phase.
‘The team is responsible for quality’ is heard quite often during this phase but what does it mean? Previously, Analysts analysed, Developers developed, Testers tested and Project Managers managed. Everyone had their own area of focus and expertise, they had mastery or were interested in getting better at what they did (hopefully). Did this mean that those individuals didn’t care about quality? No (most of the time).
Quality means different things to different people and it’s not because of their role or title. Beliefs about quality is directly related to the beliefs that you hold and what your values are. Quality can be defined at an individual level as well as a team level. One metric often used by managers is the bug count. But, does a high number of bugs indicate low quality? Without getting too far into this argument I want to say, not necessarily. It really depends on the context of the bugs, the severity, the likelihood of them occurring and the impact they have. I’ve been in meetings where a CEO would decide which bugs we could live with and which needed to be fixed. Decisions I didn’t agree with I had to explain and justify why I thought differently. Sometimes he changed his mind, sometimes he didn’t but at the end of the day he was accountable for the success of that product so the decision was his. In Agile, we push that decision down but we still need someone to be accountable and make those hard decisions when differing opinions are on the table.
Individual responsibility for quality within a team should exist. Regardless of your role, individuals should think about producing something of quality. My own litmus test for this is ‘Am I proud of what I’ve just produced?’ If I am, that’s as good as it gets at that moment for me. If I’m not, then why not, what could I have done better or differently? This is the space in which I learn and grow. Other things I think of are:
- ‘Is what I produced worthy of a high five?’
- ‘Do I feel good having done what I just did?’
- ‘Could I have done more?’
- ‘Have I helped someone else out today?’
- ‘Have I shared information with my team today?’
These are my own metrics for quality which are role or title agnostic. Anyone could ask these same questions and apply them to their own role. Individuals can and should have their own questions they ask themselves to define quality, a way for people to recognise their own contribution to a team. If everyone does their best and tries to get better, team quality can only go up. Mastery is important to individuals as it provides a feeling of achievement and value and many working parts make the engine run smoothly.
All too often, our focus on quality is also on the reduction of bugs but I would argue that a team responsibility for quality is much more than that. This is where I come to team quality and why I think some ways of thinking are diluting quality rather than increasing it.
By measuring team quality with a single metric, this then becomes the team focus. If this becomes the team focus, this becomes what people care about. “We measure what we care about and we care about what we measure” Having a single focus or quality measurement can be dangerous because this becomes the thing that matters and individual quality, individuals doing the best job that they can do can fall to the wayside.
If individuals get better at what they do and are given the time to focus on it, team quality can improve. We need to give people the space and time to understand what they are expected to do and also provide an environment for people to do their work to the best of their ability.