Trust: Your Agile Sub-Flooring

by Rebecca Stevenson

And now for something unrelated only tangentially related to the ongoing crisis. This has been loitering in draft for a while, and I’d like to get it out there for feedback.

We spend a lot of time talking about tools and techniques related to specific Agile methods — how to do a good retrospective, or prioritize a backlog. Today I want to talk about something that is a necessary ingredient in any Agile implementation, no matter what set of practices you’re putting into place. That ingredient is trust. 

How many of us have heard and seen one or more of these: 

• We’re not allowed to talk to the customers directly. 
• We would like to let the teams self-organize, but we just don’t think they’re “there” yet. 
• We need to get sign-off from upper management before we experiment. 
• I just keep my head down and do my work. 
• We need to make sure everyone on the team has an assignment. 

I could go on, but I think we’re all familiar with these or similar symptoms. To me, these are indicators that most people in an organization think that trust is a “nice to have.” If they see a problem arise, for them it lies in the system, in the overt actions that people are performing — people aren’t being held accountable, people aren’t following through, we’re not keeping on top of them. They’re not thinking about the invisible substrate, like the old idea of phlogiston, that enables and hinders communication.

Let’s think about this through the lens of Scrum, since even those of us who don’t practice it or don’t like it are familiar with it.  

Trust has to begin with oneself; personal integrity is another piece of the subflooring. You need a certain degree of trust in your own perceptions, self-awareness, and honesty in order to communicate trustingly with other people. If you’re not able to be honest with yourself, nothing in the Agile stack is going to work for you.  

Backlog refinement? “Eh, I can knock that out in a day. Two at most.” Standup? “I don’t need any help with what I’m working on.” Retrospective? “That thing that happened was my fault; I should just keep my mouth shut.” 

Move it up a level; what happens when the team members don’t trust one another? Collaboration suffers. Standups are a chorus of “I” with never a “we” to be seen. “Will they follow through? Better just do it myself.” “If I say I don’t know something, am I going to get made fun of? Or worse?” “If I ask for help, will they take all the credit?” “The last time I proposed we try something everybody just ignored it. I won’t do that again.”  

Instead of a group all pulling together toward an agreed-upon goal, you have people who may or may not be moving in the same direction, and whose priority is self-defense. That is, first, a waste of energy. People only have so much of it, and self-defense eats a lot. Second, it means that the entire point of having people work in teams has been missed. Learning, creative gestalt, emotional support, the possibility for innovation–these things are emergent properties of people working in a group, and they emerge only when communication occurs freely. 

Finally, when happens without trust between the team and the organization as a whole? When teams aren’t trusted to make their own decisions, to plan their own work, to know their own minds–when the organization isn’t trusted to communicate truthfully, to set priorities clearly, to act respectfully toward the people who comprise it–you have left the realm of Agile practice entirely. Processes have triumphed over people, planning over adaptability, fear over delivery. 

In the future we’ll talk about building blocks of trust — what are its components, and how you can build them up. 

In the meantime, what do you think? 

Rebecca is a technical writer and Agile enthusiast working in the Boston area.