I believe a team needs trust to be high-performing. This isn’t new news nor is it a unique opinion. What does trust on a team look like?
- Team members are open and respectful with one another.
- There are no “bad” conversations. The lens a trusting team applies is one of “this will help us be better than we already are”.
- The environment is happy, safe and focused.
- Team members look out for one another.
- Team members are allowed to have “bad” days.
- Team members, no matter how difficult or challenging the work is, like being on the team. In fact, the more challenging the better!
There’s more that what I have posted above but, it’s a start. As a Scrum Master, when there is a lack of trust on the team, it’s vital to help the team establish it. It’s not an easy thing to do. I’m curious what others have done to help a team build trust.
Recently, I conducted a retrospective with the team which was interesting and more revealing than expected. I gave each team member a piece of paper. The top half was divided into two sections:
1. What my team mates can expect of me
2. What I expect of my team mates.
The lower half was left blank. Each person filled out their own top half. Once everyone was completed, I had them pass their paper to the left. Once passed the timer (2 mins) started. The person with the paper could review what was at the top but, they had to write what they, personally, expected of that person and attribute their name. Once all the papers made it around the room everyone took some time to review what had been written and share some observations.
What they found was they all had more in the “what team mates can expect of me” than what they expected of their team mates. Across the board, everyone expected honesty and trust. The expectations others had written were revealing in that some were compliments such as “Continue to bring your energy to the team every day.” Some were clearly not compliments like “Let other people complete a sentence.”.
It was a very open, honest and constructive conversation. No one was hurt or insulted. What was really cool was it didn’t stop in the retro. Some people had their own, one on one, conversations and relationships were built.
I’m hoping this was a good first step in establishing trust on this team. We’ll see….
When a new team comes together, it’s interesting to watch the dynamics. In my world, there are a lot of strong personalities. Really smart people with great ideas and a desire to go beyond what’s expected. It makes for some interesting forming. The last team I set up had some great conversations about stories and, initially, I don’t think anyone heard them except for me. I found myself saying things like “A – What did you think of what B just said?” a LOT. Prior to going into their first sprint, we had a retro. Happily the team identified communication as their focus in their first sprint together. They identified and agreed to actions:
- Don’t wait to ask questions because everyone on the team will benefit from the answers.
- If you don’t understand or agree, say so.
- Listen to each other.
Listening to understand can be so difficult. I know it can be for me. It used to be impossible for me. I was certain I knew exactly what someone’s point was and would have my brilliant response ready before they had even finished talking. Generally, I would interrupt and impart my wisdom only to find out I missed the point entirely. I conveyed something similar to the team once they had agreed on their actions and they modified that third bullet to what is now in the title.
I try to always remember this myself. I’ve gotten better, but it will always be something I have to work on. All this Agile transformation going on has my brain in overdrive, but I’m of no use to a team or anyone else if I’m not listening to understand.
I firmly believe trust is the secret sauce to a highly performing team. I also believe that without it, a team will never be great and is likely, in fact, to fail. When teams have trust they speak plainly and openly to each other because it is safe to do so. They will be open to trying new approaches and listening to ideas because they trust their team-mate. They will joke around with and support each other. When there’s no trust, managers are copied in e-mails. Play by plays of the retro leave the room. The team room is quiet. Factions form. It’s ugly.
Many years back I was coaching a team that was doing pretty well. A manager came over and told me they were going to combine two teams together and I would be the coach. Um…..oooooooooooook. To say that neither team was thrilled would be an under-statement. Even the introductions were tense. Then came moving day. The new team moved into my “old” teams digs. Moving members didn’t like the room arrangement. Already moved members liked where they were sitting just fine. I’m sure you get the idea and this was just the beginning.
None of the team members wanted to make an effort with those who weren’t part of the original. Planning was a nightmare. There was no collaboration. They planned within their old team lines. They divided the board in half. I didn’t know what to do. Naively, I felt they would work through this and all would somehow be right with the world. Luckily, I had a mentor coach in the organization to whom I turned for advice. His advice? You need a good retro.
He helped me craft the retro and I wish I could remember the activity, but I cannot. What I remember was it got the conversation started and kept the conversation going. And going. And going. And going. They didn’t trust each other at all. Each team felt like the other was judging them. They each felt the other thought they were better. They both thought I cared more about the team I was originally with! They were both worried that all the good they had built up as separate units would vanish if they didn’t take steps to preserve it. Ah HA! Now we’re getting somewhere!
Eight hours later. Yes. E-I-G-H-T hours later the team had created a joint vision, joint norms and proceeded to re-arrange the room. Any artifact previously on the walls was pulled down. A new team was born. And, they were awesome. Truly, powerfully awesome until a short time later when they were split up again. *sigh*
Here’s what I learned from that experience:
- Trust on teams is incredibly important.
- A teams identity is also very important. You have to coach them through establishing one.
- Don’t sit back when you see a team doesn’t have trust. Get to the bottom of it quickly.
- It’s OK to have an agenda as a Scrum Master when you go into a Retro.
- Teams will solve the problem for themselves when they realize what the problem is, that they are a team and that they can.
What experiences have you seen when there’s been a lack of trust on a team?
I used to be a SCUBA instructor and the title was one of the things we taught our students. This was before all divers had a computer and, instead, used tables to tell them how long they could stay underwater safely.
Have you ever been diving or snorkeling? There aren’t many interesting spots, teeming with marine life that are at one depth. Coral heads, shipwrecks and the occasional sting ray or turtle cause you to adjust your depth and, subsequently, your plan. So, even the best dive plan requires adjustment. Today, divers can rely on computers whereas, then, the diver had to rely on their dive buddy and quick thinking. Good divers were able to handle the changes and appreciated them. The changes underwater are what makes the sport awesome.
Teams plan. The stories they accept into the sprint meet the ready criteria. The team knows what they need to do and they commit. Then a few days into the sprint something causes them to have to adjust. Good teams will adjust. Teams on their way to good will have a harder time. If they were divers, they would likely go ahead and surface. You don’t want a team to bail on a sprint.
So, the question is, how do you help the team who is almost ready to bail, stick with it and still feel successful?
This has only happened to me once. I first asked the team if the problem was one they could control. It wasn’t in their immediate control, but it wasn’t in the soup either. So, I asked them to come up with some different ways to solve it (as a team) and to pick one and go after it. They did. The cool thing was they adjusted their plan, removed the impediment and still had a successful sprint. The cooler thing was they realized they were empowered and could, in fact, respond to change and succeed rather than “surface”.
As a former Project Manager I’m used to fixing things. I want to make things easier, better and have a happy team. As a Scrum Master I’ve had to shift my mind-set. I want the team to see things that might need fixing and fix it so they will be an efficient, higher-performing and a happier team. About a year ago, I was asked to come and coach a team that had been up and running for a while. I figured it would be easy-peasy. HA!
The team was not running Agile at all. Their managers wouldn’t let them. I observed them and wondered to myself how on earth I could influence the managers and help the team. I knew it would take time, so I was prepared to be patient. That said, there was one little thing I observed which I thought would make things a teensy bit better. The team used stickers to denote which cards on their board belonged to which role type. Remember, they aren’t Agile. They had a project coordinator who did their daily burn down and the stickers made the cards get stuck together and her life miserable. I had the brilliant idea to use the magnets which were the same colors rather than the stickers. So, I made the change.
The team didn’t understand Agile, but they sure understood empowered. Boy did I hear about it! And, my initial reaction was one of shock. I mean, what’s the big deal switching stickers for magnets?
Fast forward to a month ago, a team was furious with a coach telling them how their board should look and be arranged. One of the team members used to be on one of my teams and was venting to me about it one day. My reaction was horrified. How could a Scrum Master, or a coach for that matter, tell the team how their board should look? The team makes those decisions!
After some reflection, I ended up going back to that other team and apologizing even though it had been months since I had worked with them and even longer since magnetgate. The team decides how. If it’s not broken for them, and even if it is, don’t fix it.
I have worked with many teams using SCRUM despite the rest of the organization not operating in or particularly supportive of the methodology. The teams applied the Agile principles as much as possible within the constraints that existed and they were successful. They may not have had text-book stories, but they were self-organizing and delivering value regularly with far better quality than other delivery teams. So, when the entire organization decided to “go Agile”, I had an unrealistic set of expectations. I knew it would be difficult. It took a long time for the org to get to where they were and it wasn’t agile friendly, but the success I had seen before led me to believe other teams would experience what my teams had.
Bless my heart.
Teams can overcome a lot – much more than anyone would give them credit for. They can’t overcome culture. If the culture is to value an individuals contributions, over and above their role, the team members would be silly to eschew that which they are measured by. Let’s not forget the fact that the managers aren’t quite sure what to do if not overseeing their direct reports work. And, what about those who don’t directly manage but are hired to “strategize” and lead?
If I have an opportunity to be a part of a large transformation again I would do the following:
- Change the objectives of team members to align to, support and reward the team over the individual.
- Change the objectives of managers to deliver value to teams by making it easier for them to apply Agile and be EMPOWERED.
- Change the objectives of the organization to strive towards Agile proper not Company X Agile.
- Train middle management using the exact same training the team members will go through before training team members.
- Recognize that Agile is not for everyone. Some people who have been great before will not be a good fit and that’s OK.
- Empower the team in everything they are doing and celebrate their learning as they succeed, fail and improve.
I’m curious to hear about great and not so great transformations as it relates to culture shifts. What has worked? What am I missing?