Exploration Through ExampleExample-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
|
Sat, 16 Oct 2004I'm in Boulder, Colorado, at a Scrum Masters meeting. Yesterday, I was in a session on how to deal with problems around cross-functional teams (such as teams with programmers, testers, technical writers, and interaction designers). It didn't go so well, largely because of my inept moderation. But I have synthesized some of our ideas about the dynamics of successful cross-functional teams into this abstract diagram: Here's the way it works. You have people from various disciplines who you need to work together toward a common goal. In many ways, disciplines are cultures: they have shared values, goals, languages, self-images, and such. Cultures are resistant to change. So melding these people into a team can be hard. It's first important to provide the team with a shared goal, which is to provide external value. People should always be able to articulate how their current task ties into the delivery of specific value to those paying for the project. I suspect that a properly running team will develop a shared language that they are all comfortable using when talking about their goal. (This would be one of Galison's creoles.) But I don't think the shared goal and shared language are enough. I think they will also develop tools (in the broad sense) that are used across disciplines. I think of these as boundary objects in Star and Griesemer's sense: things that people can use to further a common purpose while not having to agree on their meaning. Test-first customer tests are a good example: a customer might think of them mainly as an explanatory device, a tester might think of them as a tool that covers the whole breadth of a problem and lets no important detail go undiscussed, and a programmer might think of them mainly as a way to break programming down into small chunks. Such "unshared tools" work if they allow the different people who use them to achieve what they value. Until the glorious day when disciplines wither away and everyone knows enough about everything (which I do think would be a glorious day), members of a discipline must feel valued in the terms that their discipline defines. When a tester and a programmer work together, the tester must feel valued as a tester, and the programmer must feel the tester delivers value as a tester. Where this exchange often falls down is in the recipient's feelings. The programmer might not see value coming from the tester: she might see an imposition. A team needs to have a shared ethic that each person acts to serve others - not through "tough love" or while thinking "this is for your own good, and you'll thank me when you're grown up", but in terms the recipient values. It seems to me that this would work best in a gift economy of the sort described by Marcel Mauss, one where a person's status depends on how much she gives to others. A Scrum Master would want to show the team a way to an internal gift economy. But perhaps the most important thing is positive feedback, feedback that reinforces desirable behavior and attitudes. That feedback comes from shared activities: two or three people sitting down to accomplish some task. People from one discipline will help people from others, thus building respect and a common language. As is typical of Agile projects, we want such tasks to be frequent and completed quickly. That maximizes the number of feelings of shared accomplishment and allows lots of room for adjustments and experiments. For help to be valued, the tasks have to be real ones, the kind that are valued outside the team (presumably because they deliver business value). Special thanks to Christian Sepulveda, Jon Spence, Michele Sliger, and Charlie Poole, who (except for Jon) are not to blame for the odder parts of the above. The rest is Chet's fault. |
|