Sharing the duty

As a basketball coach I would face teams from time to time that had a premium scorer. Given the rules today, even a premium defender would not be able to check that scorer in a 1:1 situation. Even if he could, chances are high that he needs a break from time to time. The key was to be prepared and have a defensive team concept in place. Have helpside ready, know your defensive rotations or be prepared to trap from time to time. The key was to get away from 1:1 situations towards 2:1, 3:1 and ultimately towards 5:5. Defending is a shared responsibility that involves the whole team. This is a foundation that I strongly believe in, not just in coaching, but in testing as well. As logical as it sounds for sports, the whole team approach is not always in place in software development. From time to time people will say testing (writing user stories, fixing bugs) is not my responsibility, I am better at writing code (stories, tests) and if I do diverge it is not very efficient.

Patrick Prill got a nice discussion going with the following tweet:

Let’s assume now that the gut feeling is justified. The underlying question for me is then: how do you get people into buying that testing is an activity and not a phase best performed by a single person?

The easy answer is to promote and foster a whole team approach. The not so easy answer is that you have to convince them again and again that it is about the team and delivering software for the customer together.

Here are a few ideas and methods that I have used and think that they might help in that regard:

If you are doing Scrum, the Definition of Done is starting point. It (hopefully) states that things are only done if they are tested. It doesn’t (even more hopefully) state that a certain person has to do the testing. It can be done by others and the others can certainly support the specialist (Mike Cohn has a great blog post on this). If the efficiency debate surfaces, it usually helps to point out that the team is measured together against the sprint goal they committed to. I am not much of a Kanban guy, but I like the work in progress limit. Especially if you apply a little twist: Coders set the limit for requirement engineers and testers for coders. This way people are more willing to support in other areas if it blocks their items from moving through.

Some teams have learnt this the hard way. Tester being sick for a longer period of time or being pulled from the project. Things did not get to done or were not released. The only way was to pick up the slack. It might be slower, but there was no other solution. Going on holiday might be a nice test. If you come back and there is a pile of work because no testing has been done, that’s a surefire indicator that phase thinking is prevalent. In my experience this kind of thinking is more likely if there is some kind of safety net, e.g. an extra testing phase prior to scheduled releases even if you are working in sprints. It might help to get rid of that phase (not the testing!) and move that testing into the sprints as it creates more urgency to deliver something good at the end of the sprint.

And then there is the Jenga Game. Getting testing involved early goes without saying. Well, at least for me, but not for everyone. This is a nice game and eye-opener for some people as for why testing early and why it might be a good idea to work together instead of doing hand-offs. I got this game from the great growing agile book on agile testing.

I am a big fan of liberating structures. One that I have used before in other contexts, but which I think fits nicely in this context is 15% solutions: What can you immediately do to help me testing with 15% of your time? 15% is not set in stone, but stating it gets people thinking what they can easily do to support a goal.

The recurrent theme in everything mentioned above is communication and creating a shared understanding of roles and goals in your team. And mind you that a role performs an activity and is not tied to a person. The key is not to take away from the specialist’s work and role, but to support him and by that getting the best possible result for the team. As a basketball player I knew I was a decent shooter, but if someone else had a mismatch to exploit, I would make sure that this guy got the ball even if my passing skills were not up to my shooting skills.

What do you do to get everyone involved?