Agile SW Quality – Victim of the Bystander Effect

Introduction

This week I had the pleasure of having dinner with one man, who I reckon to be one of the top experts and long term advocates for agile methodologies. While speaking about the necessities of different artifacts in SW development we also talked about quality. Therehe said, that quality is cared for implicitly in every step. While this is true to the heart of Agile, I instinctively reacted somewhat negatively to that. It might be that it just has to do with my long term work in quality, not wanting to have it “sidelined” and “diminished” as being something “implicitly done”. And while I admit that this has to do with it to some extent, it also occurred to me, why I find that concept disturbing. It basically has to do with my observations and experience.

What we learn and what we observe

When we talk about Agile we talk about Scrumin most of the instances. Not because it is the only one. Not the best. It’s just the most common currently.  And the first thing we learn about Scrum: there are only three roles. The product owner, the Scrum master and the team members. We also learn, that the team is set up in a cross functional way, to ensure that they can deal with everything they might need to do developing a system. We also about T-shaped skill profiles, where different people have different areas where they have in depth knowledge. We all learn that and yet the “team member role” sticks. In itself, this is not a bad thing.

We also learn that the team is self-organizing and, for what it’s worth, responsible for everything they produce. This makes a lot of sense. So, when we ask “Who is responsible for quality?” the answer is “The team!”

In an ideal world that would result in everyone in the team being committed to quality in more or less the same way. In an ideal world the sentence of “quality goals are kept up” would always be valid in any agile team. Yet observation of agile teams in many different settings tell me a different story. Observation tells us that many Scrum teams focus more on finishing implementing stories than dealing with the upcoming bugs. While you might argue that at that point the definitions of done are not fulfilled (and I agree if we talk about bugs found during the implementation of a story), this is still what I and my colleagues observe. And when we talk about bugs coming from outside the team, eg. a system integration group, we often observe that they are not dealt with the priority they should be given in order to reduce technical debt.

Would I agree that this “is not right” and “they are doing it wrong”. Probably. But since I observe that behavior rather often, I tend to believe that this is inherent to the model, the typical setup of agile teams and the expectations of the outside world, where the demand for new features is very vocal, while good quality is just basically expected. So, basically: it is part of human behaviour and the dynamics of their interaction.

Due to this feature pressure slowly but surely the group dynamics will move the team’s foremost goal towards implementing more features. Effort for quality measures is still kept up, but it tends to become a must, a chore, a hold-back. Nothing you devote special attention to. Who’s task is it now to check how the quality is faring? Who’s task is it to shout out loud, when we see our system’s quality is degrading?

The answer is still the same: it is the team’s task! It is everyone’s task! And as with the bystander effect, it becomes no-one’s task. The diffusion of responsibility becomes apparent even in small numbers. Every single team member will conclude that the quality is ok, as nobody else in the group is complaining. And that way, even if someone in the team is the first to be bothered by too much technical debt and too many reported bugs, it takes a strong personality to overcome that effect. And not everyone has that strong personality.

Why there is something good in roles

When thinking about testers in agile teams today, I have come to the conclusion that it is important to give them a mission and role. When assigning them to a team, I will clearly state that his or her role is to focus on the quality of the product. He or she shall always bring the view of quality into all the discussion. And I will very clearly state, that the tester owns the quality. Yes, every team member is responsible to deliver high quality work. But I hold the testers accountable to their role and job to make sure they remind their team mates about all quality related stuff. And for what it’s worth, it worked fine for me up to now.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Time limit is exhausted. Please reload CAPTCHA.