There’s been a thread on the Agile Sweden mailing list this week about the kind of manipulation that consultant-coaches use in the course of their work with a software development team. Several people seem to favour this definition of what manipulation is:
"One view, to paraphrase Kent Beck, is that manipulation is when you wouldn't get
the same effect if you were upfront about the intervention."
(This quote is attributed to Michael Feathers)
Someone pointed out that they recently went on a training course where during one of the exercises, the course leader was not up front about its purpose. Afterwards he felt that this manipulation had led to a new insight that he was thankful for.
This reminded me of an experience I had many years ago on a similar training course, which was long before I or anyone else had ever heard of agile. As software consultants we were supposed to be learning about the social aspects of our profession, and it was about the third day. The instructors had been interleaving lectures with little games and activities designed to illustrate what we had been learning. The exercise that sticks in my mind went like this.
We were instructed to divide into two groups, and each group was given a datasheet of information and a description of a problem to solve. We were put in separate rooms and given a suitable time limit. We were encouraged to examine the problem, the related data, and report back a suitable solution to the problem to the instructor within the time limit.
In our group we carefully read through the problem and datasheet, and using a whiteboard made connections between the various pieces of information. We quickly discovered that there were large gaps in the information we had and that it was rather difficult to solve the problem. We questioned our instructor about this but she said she had no further information for us. We used our initiative, we thought laterally and came up with what we thought was a reasonable solution. Towards the end of the allotted time we reported back to our instructor our best guess at a solution. She told us that it was wrong.
The other team had not managed to solve their problem either, and when we joined together to discuss what had happened, it turned out that both teams had actually been given the same problem to solve, but each had only half of the needed data. So the only way to successfully complete the exercise would have been for the two teams to pool their knowledge and come up with a joint solution.
I have to say that after 3 days of these kind of exercises I was pretty fed up and I wasn’t the only one. There was a general feeling of being cheated and misled and that we had been set up to fail. In most of the other exercises we had done, talking to the other team would have been considered cheating, since in several of them had been set up as competitions.
The instructor explained that what she wished us to learn from this exercise was that in real life, if your team doesn’t have enough information to be able to write the software, go and talk to the customer. This is a good thing to learn. However, it is not the insight I took away from the exercise. For a start, in real life you know who the customer is and if you don’t have enough information, you know it is not against the rules to go and ask.
In general, I think that this kind of teaching technique can work really well and be a good antidote to endless lectures. However I think it can be done badly, as in this case. If your students come away feeling angry, cheated and misled, they are not going to be very receptive to your lesson, however well intentioned.
