There a moment on a good project team where everything clicks. All the egos are in harmony, no-one’s being polite anymore, and you can just feel the team purr. As a team lead, there are few ways of achieving vicarious satisfaction than helping a team sustain a productive pace.
This happened a month or so go on my previous project – and it kept on getting better. Something special happened, and I’m not quite sure what.
When things go wrong, there are minor symptoms of malaise, for sure, that you can recognise: Monogamous pairing, the same people going out together in the evening. More serious symptoms include frequent broken builds, multiple approaches to the same problem, talented individuals given tasks that don’t interact with the main team.
When things go right, well, it’s more difficult to “bottle it”.
Let’s assume that this was a thoroughly agile project. We weren’t doing as many retrospectives as we should have done, and the build time was creeping up, but all in all we had plenty of “premptive forgiveness” stocked up to try things out.
Still, there was concern that we were moving slowly.
The catalyst for high performance was the bell. We introduced the bell to facilitate the inter-team pairing – e.g. when the bell rang, well, there was another pair ready to swap – “Finish your stories, gentlemen”. Alistair Jones got it right in his blog. But I suspect that just adding a bell won’t do it for you (prove me wrong…).
Just prior to the bell being introduced, there was a lot of frustration building up. To resolve this, we had a freeform retrospective, and covered two 6×3 ft whiteboards in marker pen. Looking back, this seemed to be a turning point: Simon and I suddenly had fewer meetings to go to, we had a team fishbowl to discuss two controversial code patterns (FYI: internal iterators, and the never-before-seen “query” specifiers), we agreed on a state-machine model for the workflow areas of the application, and we “unveiled” a new [then prototype] query api. Brownbags became engaging and informative. We were cooking.
As far as I can tell, the thing that changed for me on that retrospective (and I want you to read this without sounding like Tony Blair), was trust. Trust in the development team, asking people to drive through the changes they wanted. Trust between multiple consultancies. It was astonishing.
This was my first experience of being responsible for such a large single project team. I have a lot to learn about giving up control, setting boundaries, and removing obstacles and blockers. But next time Pat Kua reels off the phrase “Self organising team” to me, I’ll have an example to cite back at him.