One of the more obvious areas to look for insights into what makes project teams tick would be the field of social psychology. While Freud wrote about groups in the twenties, and industrial psychologists have been looking at this for a long time, much of the impetus for the modern study of what happens to humans in groups seems to have come from people trying to understand the behaviour of the Nazis in the Second World War. The applications of social psychology are many. For example, educators I know are particularly interested in how social psychology can help them improve teaching and learning. So what can social psychology tell us about working in project teams?
One feature I like about agile teams is that everyone is equal and has a respected opinion. I find this so important that I try hard to ensure all my waterfall projects are like that too. I temper this with always trying to give clear direction and leadership. As Laura Markham has said, people want to know that a ship has a captain and that captain is taking care of the ship. If the ship hits an iceberg, they don’t want the captain to come to their table and ask their opinion in a democratic and caring way. They want the captain to take care of the iceberg situation. So, I try to work in a team of equals, each with a clear and equally valid role. In that team, part of my role is to take overall responsibility.
This sense of equality is crucial to how the team talks to each other. Neil Mercer is a psychologist who studied the different kinds of talk in the classroom. I’d like to repeat his work in project teams. In his paper on the subject Mercer says
In exploratory talk, then, a speaker ‘thinks aloud’, taking the risk that others can hear,
and comment on, partly-formed ideas. Engaging in exploratory talk is therefore rather
a brave thing to do, and tends not to happen unless there is a degree of trust within a
This reminds me of both the ethos of agile teams (everybody is equal) but also the structure of the rituals. In the sprint retrospective or daily stand-ups, everyone has a chance to speak. The rituals make room for everyone to have a say. This encourages trust that one will be listened to seriously and an atmosphere of open sharing. Also, the permission (implicit in agile) to try out ideas and fail means that the groups is more disposed to entertain partially formed ideas and examine possibilities together.
Ron Friedman has been questioning the wisdom of collaboration on partially formed ideas, suggesting that it is better to do most of the creative work solo and come together only to share already formed ideas. I find his article very interesting and I easily related most of his examples to my working life. I do think, however, that his ideas apply less of the time than his article suggests. Friedman is not looking at agile teams in particular. I can think of lots of cases where solo creation might be best in agile. Still, it is worth noting that some of my most fruitful experience of agile teams has involved formulating solutions in groups. I’d say that is one of the strengths of agile.
Mercer defines three kinds of talk. I am interested to know if you recognise these from project teams. Disputational, cumulative and exploratory. Disputational communication is competitive. I find a lot of technical discussion sites highly competitive and intolerant of mistakes. I don’t know why this is so commonly the case. Cumulative communication is something I have come across a lot in conflict averse environments like some parts of the public sector. Ideas are accepted and built upon but without much analysis or apparently deep understanding. There is a lack of engagement. I also find this can happen when there are experts in the mix. People will listen to legal advisers thinking “well, it’s her job to know this stuff so I’m not going to question it”.
I once did a rather annoying drama exercise as part of a rather annoying team building day. It was interesting, The annoying bit was feeling compelled to take part (i.e. “You will have fun”). The exercise involved finding a partner, then listening to them start a story. When they stopped, you would say, “Yes and…” and continue the story. The shared ownership of the story made one pay attention and feel a lot more invested in where the joint story went. I imagine this is what exploratory talk is like but I wont be suggesting that exercise to my team any time soon.
There is much written about the interesting practicalities of communication in agile. I am interested in analysing the nature of that communication and would be glad to hear about your experiences.