How long does it take to teach trust?

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?

GeePaw sez…

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.

8 thoughts on “How long does it take to teach trust?

  1. Tobias Mayer

    Good topic…

    > how much of your coaching attention goes to helping people learn to be open, curious, relaxed, honest, courageous…?
    In my case I’d say that is all I do. I don’t teach technical practices at all, but try to create a mindshift in the individual while building an organization that can support that mindshift. But then, I am not an XP coach.

  2. Olaf Lewitz

    thanks for your thoughts.
    I do both – coach people on the personal and team level to increase trust and collective ownership of the product, leading to true team collaboration and commitment, and, if needed, assist or mentor on the improvement of technical practices.
    “Getting it” requires both.

  3. abby, the hacker chick blog

    Awesome post and great comments. This is such an incredibly important point and it kills me that so many companies miss it. Thanks for a thoughtful post on it.

    And love this quote (thanks, GeePaw):
    “Learning when you’ve no hope is extremely difficult.” – indeed!

  4. Ron Jeffries

    Hill says it better than I can. I can help people DO, and often guide management. If the spirit to succeed is gone, it’s hard to get it back. I try to get people going better, keeping small promises, and hope they heal themselves.

    Probably not one of my strengths … whatever they are …


  5. Michael Norton

    There are a number of ways to approach agile transformations, but I think a very clear and important distinction is between those that intentionally address people’s intrinsic motivators and those that don’t.

    The hard work of a coach involves people and their emotions. Fear is at the forefront. Fear of pain.

    People are not lazy. People want to contribute and make a difference. People who appear to no longer wish to put forth the effort or make a contribution are protecting themselves from pain. For each of them, the source and intensity of the pain is unique. But it exists. For most of them, they are not consciously aware, yet deep down they feel it in their gut.

    How many times have you heard a conversation between a new member of the company and a seasoned veteran where the new member is lamenting some injustice or poor practice and the veteran merely says, “I used to be like you.” It hurts my soul every time I hear it. People losing hope and accepting it as one of life’s lessons.

    While it is important as a coach that the team trust you, it is not nearly as important as the team trusting one another and the company for which they work. You will leave. And the mechanics will not be sufficient. The team needs to know they are safe. Safe to make mistakes. Safe to learn. Safe to recover.

    So while we implement a rhythm and while we work with the team to achieve confidence and joy, we must also work with the environment around them. Cultures of separation, process, and avoidance put crushing pressure on a team. All too often, I’ve seen teams flourish under a coach and then wilt when the coach is gone.

    Agile adoptions take at least six months not because the team takes that long to get it. It takes that long before the team trusts that trying will not lead to another life lesson.

  6. Sean McMillan

    Some damaged programmers need to learn to trust themselves. When you’ve “failed” enough times, you begin to think of yourself as a loser. The XP programming practices can be a lifeline that lets you trust yourself to build good software that doesn’t suck. Once you trust yourself, you can begin to trust your teammates.

    Trust comes easily to a team that is all together, with the same goal. Trust is very hard in teams where there’s a “boss-type” who shows up for an hour a day, or a day a week.

    How long does it take to teach trust? As long as it takes to change the culture to put the whole team together, fighting for the same goal.

  7. J. B. Rainsberger

    I try to focus individual people on adopting habits that will help them, rather than worrying about what will help the team or the department or the company. I share with them stories about my own individual development as a programmer and a person (and things in between). I remind them that, ultimately, they need to either enjoy the work or find other work.

    I tell them that my value to my companies and clients relates very strongly to my happiness with the work I’m doing. Happiness and effectiveness go together. This makes happiness a practical goal.

    I don’t know how to feel happy without talking about when and why I feel unhappy. I tell them that, too.

    Of course, I don’t just tell the programmers/testers/analysts/whoever that. I tell the ScrumMasters. I tell the managers. I don’t often tell the executives, but I’m working on that.


Leave a Reply to Olaf Lewitz Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>