Last weekend at the Simple Design and Testing Conference, I learned so much technical stuff I thought my brain would explode. But there was also good conversation about coaching, and it’s got me thinking.
One coach asked in a session how long we should give people to “get it”. How long do we keep coaching testing methods, pairing, standards, etc. before we give up on someone? As I recall, Doc said it can take around six months for the light to come on. If someone’s not getting it, we can look for the reasons behind that rather than deciding there’s something wrong with the person.
But I’m not wondering about technical practices, at the moment. I’m wondering about the other things that people need to work well on an agile team.
Say you go into a shop where coders have been told they’re “behind” for the past, oh, two years. They’re working over-time, so their energy and focus are limited. They avoid taking responsibility for their code, because they put a priority on not being blamed for bugs. They’ve forgotten what they loved about programming, and they oscillate between blaming themselves and playing hero, blaming the people around them for the team’s troubles. They live on what Kent Beck calls the “genius-shithead rollercoaster”.
Lots of people live in quiet fear that they’re not good enough, with all sorts of defenses to protect them from that fear.
What I’m wondering is how much of your coaching attention goes to helping people learn to be open, curious, relaxed, honest, courageous…? How much attention do you put to creating an environment of emotional safety? How long might it take for a newly agile developer to be able to collaborate effectively and comfortably?
How important is all this to a successful agile transition?
It is vitally important. In fact, work in this area has to precede all but a light dusting of the technical practices. Learning when you’ve no hope is extremely difficult.
Digging out from under the weight is something you can’t do for a team. But what you can do is serve as a ray of hope. In situations like these, I start same as I always do: I make it explicit and I put it on the table so we can all think and talk about it. I work the upstairs with brutal frankness: “I can get this team back in the game for far less than it will cost you to replace them, but still not for free: you are going to have to give me some room to work, and give us some permission to change directions.”
I aim myself towards three targets, all rhythmic.
First, I press the team and the checkbook to make tiny promises to each other, and to deliver on them. People often get trapped in thinking that trust will only come when we succeed at meeting some huge commitment. It’s not true. Trust derives from many small successes, not one big one. If I can get the team back into the habit of delivering, even when it’s far short of what they wish we would agree to, then we have a chance to regenerate.
Second, I aim myself at developing the pulse of the team on the inside. This involves the standup, the signoffs, the pair-making, all the daily interactions a team makes with itself. It’s important here to enjoy the give and take. We make mistakes, all of us, but the team in despair feels each one as a lash. Mistakes are just part of the rhythm of things. The key is not to avoid mistakes, it’s to absorb them as a normal part of working.
Third, I aim towards building a minute-to-minute feeling into the work itself. TDD has a rhythm that is neither subtle nor implicit. Red. Green. Refactor. Integrate. Developers in pain have no such beat to their work lives. They work on tasks whose durations is hours, days, even weeks. It hurts a whole lot more to screw up a 3-week task than it does to screw up a 20-minute one. Red, Green, Refactor, Integrate. (Ask any TDD’er about the joy built into this scheme.)
So? Rhythm is fundamental to our hearts. Restore rhythm and we can do amazing things.
And two side notes: Nothing I said above should be interpreted as saying despairing teams are easy. Most of my work with such teams does not succeed. Despair is bad, bad stuff. Second, you sure bring out the blah-blah-blah in me. You should ask me the occasional question that demands just a one-liner.