How to begin with testers and programmers working together

On the peer conference PotsLightning directly before the Agile Testing Days 2012, we had a lot of interesting topics. One was about how to involve testers and programmers both on working together more closely. For a short time it was a rather general discussion of how to "apply" change to teams. Surely what I will write now is nothing new. But sometimes it helps to hear (or read) something again to remember what we already know.

As a consultant of Scrum and Kanban with a strong interest in programmers and testers working closely together located in Germany, I often encounter some kind of ... reluctance. In Germany, testers often have but a hard stand and are more seen as cheap click-monkeys. Programmers seem to seldom like them very much as they find one's bugs and as they sometimes seem to delay a release (I don't agree!). Testers seem to seldom like the programmers as they throw bad software over a fence and there are times, where the programm doesn't even start (uh, I had that before, but seldom).

Agile methodologies have the strong need of cross-functional teams to cope with the constant changes and the necessity to program and test in short iterations. This implies that programmers and testers need to work very closely together. Even pair up to work on some task together. Most of the programmers and testers are not used to this. At PotsLightning we remembered how to help the team to introduce habits as tester and programmer pairing up:

Normally you won't get very far if you just told the team to do so and force them to. As soon as you lower the whip, people will return to their old behaviour. I even think you cannot convince most of the people by just telling them that some technique is helping them.

Everett Rogers describes in Diffusion of innovations five groups of people. Innovators, Early Adopers, Early Majority, Late Majority and Laggards. In every team I was in, I learned to see who is likely to be in one of these groups. You can often see clearly how they interact: 

If an innovator has a new idea, he will encounter some reluctance first. Some people will try out very fast, whatever idea they encounter. These are the early adopters who are needed badly by the other three groups. Early adopters need not be convinced to try something out. Normally it is sufficient to describe positive effects.

The early majority needs at least some proof that the effects happen. They cannot be convinced easily by just telling them about the effects but you can show them that something works. The late majority not only needs proof, that something actually works, but that it works on their context before they will apply something to their context. Last come the laggards who only change if they don't find a way to intercept.

I don't think that there is always s.o. of every kind in every group. And I don't think that a person is always in the same group or that it is always clear in which group someone is on any given moment. But when I saw a team change, the change was easier the more it was like described above.

If you speak to a late adopter you won't convince him by telling him, that pairing up a tester and a programmer has useful effects on both. You will need at least two early adopter (one tester and one programmer), who try that out first. If the effects are positive, the early majority can observe and be convinced step by step, to try it out themselves. And when they succeed in a context, which is obviously the same as for a late adopter, he might be convinced as well by observing positive effects in his own comfort-zone.

I still don't really know how the laggards will get attuned to new ideas. But I still encountered very few of them.

So, search for early adpoters first instead of wasting time and effort on the others in the beginning (and drive them mad). They will follow-up as soon as they see you succeeding. Then it's time to help them within their comfort-zones.