I’m re-reading a book that I read first a couple of years ago.
The idea of “The Second Circle” by Patsy Rodenburg is very simple. There are three modes of communication:
First circle: talking so that no one will hear, talking to yourself. Muttering, mumbling. Saying nothing, allowing yourself to be talked at.
Third circle: exclaiming, expostulating, lecturing, hectoring, posturing, yelling, shouting.
Second circle: actual dialogue, speaking to be heard, making sure that you’re understood, listening to others.
That’s what it’s all about - communicating in second circle. You tell me something, I listen, I respond to what you’re saying. You listen.
What happens a lot in software development is that the people who want the software - the managers, the stakeholders, those in charge, fall into third circle posturing. They tell the people who will actually do the work when the work will be done. They convince themselves it has to be done by then. They tell themselves that the development team has let them down if it’s late.
When this happens most teams just drop into first circle. Their head’s drop, they don’t mention that the deadline is insane and un-achievable, they keep quiet about the problems that they’re encountering. Without discussion with the stakeholders who are shouting at them they vary the only variable under their control to make a deadline - the quality of the job they do.
For a long time, I think I’ve seen the role of a Scrum Master to be that of adopting a third circle response on behalf of the development team. I’ve quoted approvingly Jerry Springer when he says “I don’t solve people’s problems, I televise them.” In Rodenburg’s terms, I’ve been in third circle. The management have been yelling and I’ve been yelling back.
I think I had some vague plan that this would work as a way of “bringing people to the conference table” - getting them to have a realistic conversation.
Thing is, you can only get software to work if everybody is in second circle. That is, as the result of a close conversation between the people who want the software and the people who write the software.
But for various reasons, that kind of direct discussion is threatening. To everybody.
The people who want the software have probably over-promised. They’ve given their word that something will happen by a certain date. But that doesn’t mean that they can articulate precisely what they want, or even decide what they want.
The people who are writing the software are worried that they can’t do a good job - or any job in the time they’ve been given. They wish the people who wanted the software would be clear about what they want and stop changing their mind.
Second circle conversations in software development settings are raw and dangerous for everybody involved. This is possibly one of the reasons for the Scrum device of wrapping them in fixed ceremonies that happen at set times, of fixed duration.
Saying nothing, muttering at the stand-up or complaining to people who can’t change anything (all first circle) doesn’t help.
Yelling at the team to go faster doesn’t work. Yelling at the people who are yelling at the team to go faster doesn’t work.
If working software’s what you want, the only thing that works, is dialogue and discussion focused on what is actually happening, and what actually needs to happen.
This is what Patsy Rodenburg calls second circle.