I love the Agile Manifesto for its simplicity. In essence, it is four simple items (with more details if you want) that give you a framework for how to deliver almost foolproof results. The great thing about it also is that if you remove "working software" and put in "working products," you can use it in almost any situation!
What exactly is a "manifesto," though? The dictionary defines it as "a written statement that describes the policies, goals, and opinions of a person or group." OK, that makes sense to me, but when I look over all of the items associated with the Agile Manifesto, there is one belief, one central tenet, that really makes it work. This element is trust.
What is trust?
Trust is a tricky thing. We throw the word around a lot. If you asked someone, "Do you trust me?" and they said, "No," how would you feel? Probably pretty bad, because most of us associate the word "trust" with "I don't think you will do anything bad." The real question is, should
you feel this way? Do you really understand -- and, more to the point, do teams understand -- what trust is truly based on, so you can have it? This is so key that I think that you cannot have a true Agile, sustainable change unless team members develop a more nuanced definition of trust.
I am a coach who helps run the coaching practice at a local university's executive master's program, where we use a model to understand what trust means. It is based on research by Dr. Michelle L. Reina and Dr. Dennis S. Reina
, and I think it highlights the key competencies that you or a team needs to constantly reenforce in order to have a true Agile experience. The bottom line is you have to show that you communicate well (do you communicate well?), are contractual (do you live up to your contracts?), and you are competent (can you actually do the work?). By defining trust in this way, you can start to view it as something that can be built and developed just like other competencies.
Trust is the glue
Now, here is the tricky thing about trust. Let's say you are using Scrum in all the "right" ways. You are doing your stand-ups (three questions, 15 minutes, etc.), you have visual boards, you are doing all the other Agile things that people say you should do. You are golden, right? No problems? Guess what -- maybe you are, but, more importantly, maybe you are not.
The reason I feel that trust is the glue to Agile is because the Scrum ceremonies and approaches mentioned above are a packaged way to develop trust, but it is not enough to just do them
. You have to truly understand what they are trying to accomplish and really understand that the other person's perception of trust is, because that will determine whether you build trust with them. If you do not understand how they want to be communicated with, how they define living up to contracts, how they view competency, then no matter what you do, building the needed trust is a gamble.
Let me give an example. I had a client who was very unhappy with the customer. From my client's perspective, they had worked on what the customer wanted, delivered it in a demo and within the sprint, and yet the customer was reacting as if the team had not done well. This client wanted to let the customer know (in somewhat strong terms) that he was unhappy. I said he could do that if he wanted to make sure he severed the relationship, but then I asked him some quick questions about how he and his team had communicated and groomed the stories. I then asked him if he had talked to the customer about his approach and whether it met the customer's needs. He said no but that he would.
As it turned out, the customer did not feel that the way my client was communicating with him was for him.
He felt my client was going through the motions of getting a story and acceptance criteria but was not having a real discussion. In the words that the Reinas use, there was not the desire to "encourage mutually serving intentions," so the customer somewhat disengaged. The customer acknowledged that he should not have done this, but he reacted based on his perceptions. My client and the customer went on to have a great discussion about how to communicate with each other in the most beneficial way going forward, and since then, both parties have been extremely happy.
So the next time you are working with a teammate, customer, or anyone, talk to them about all of these trust factors (communication, competence, and contracts) and how they define them. It is all about the conversation and building that bond of trust, not about simply following Scrum ceremonies. The Scrum ceremonies are there to help build trust, but they are not a substitute for it.