Trust Is A Must

December 23, 2016

We all know that Agile is as buzzword-ridden as anything else that helps people generate an income. There are a lot of gems among the buzzwords associated with agile ways of working though but a lot of the time we tend to take them at face value and not look at where and how they fit in. I’ve been looking at some agile practices and tried to reason around the relationships between them and one of the things I realized was how essential Trust is in order for most of the other practices to work. You can fake a lot of things but if Trust is not truly there so many of the other things we try to do will not only fail, they might also make things worse.

trust-is-a-must-iiOne practice that has always been at the essence of agile is Transparency; we want everyone involved to have current and correct information. Adding a window to a solid brick wall won’t offer any Transparency though. We can’t buy Transparency in the form of a whiteboard. Worst case scenario, the whiteboard only serves as giving credibility to lies, useless data and wishful thinking. Transparency needs to be combined with, among other things, Trust and Autonomy to provide value. The “Transparency” offered when Trust is lacking will never be true Transparency. It will be a display of what the team believes that people around them want to see. It will be fidgeted numbers such as story point inflation, velocity boosting with “almost-done” stories and smokescreens hiding work performed under the radar. In short, any “Transparency” offered when we don’t have Trust or we suspect that we’re not Trusted will be a pile of lies.

So if we add Trust, will that transform Transparency to a valuable practice? I’d say no. Not unless we also add Autonomy to the equation. A team that is not Autonomous will always have dependencies to people and teams outside the own team in order to deliver any business value. When all a team can deliver are small parts without intrinsic value, the data that come out is mostly worthless. No true progress can be shown, only task completion. In any cases but the truly basic ones, task completion won’t give us much information regarding how close we are to realizing any true value. The complexity of what we do will hide a plethora of new challenges behind every completed task. Challenges that only surface towards what we thought would be the end, when we put everything together. In a similar way if we have an Autonomous team that lack Trust and/or Transparency, they are potentially a true danger to the organization. If they act without Trust, it will be a high stakes lottery ticket where there might be a brilliant idea in the jackpot but more likely the team will be a liability that acts without any information sharing with the rest of the company. Adding Trust could be a way to better the odds of something good coming out but without Transparency it will not be aligned with the rest of the company and its strategies.

Before adopting the next good practice, see where it fits in your context. Look for the untold prerequisites for the practice and consider if you fulfill them. Do you have the necessary mutual trust in your organization? And remember that trust ISN’T earned; it has to be offered in advance because people WILL act according to the expectations that are offered to them.

Have you ever experienced working in- or with “teams” that never seem to get to a state of working together as a team? I put the word teams within quotation marks since these aren’t really teams, they’re just administrative units. This has happened to me a couple of times and no matter how much we struggled with trying to get everyone on the same page through working with visualization, teambuilding, meeting formats, goal setting, work spaces etc, everyone would go back to their desks and continue to work as fractions. I’ve gone through several phases of explanations and rationalizations in my attempts to explain to myself why we had these problems. A while back Esther Derby introduced me to Glenda Eoyang’s work describing the effects of containers on systems and that really put the spotlight on some of the driving forces behind our problems.

containers

Basically a container is something that bounds one part of the system from another and constitutes a difference. Containers can be:

  • something physical such as walls, desks or cubicles that separate people or unite people.
  • of organizational nature; people reporting to different managers, belonging to different departments or being hired consultants as opposed to employees.
  • something conceptual such as purpose or rules.
  • behavioural, e.g culture or family situation.

The effects of these containers will greatly affect how people are going to work together. Some of them will work in favour of collaboration while others will drive a wedge between people. When I began to model the containers that I could identify within the troubled teams it was really easy to see how many things were pulling people apart instead of holding them together.

People may have been assigned to the “team” and in best case even be co-located. We might have a unifying goal of delivering a product or service but that’s where the positive forces ended. Then people would be experts belonging to different organizational units. They would be reporting to different managers. They could get input to their work from different sources. They would be seated together with a few people with the same kind of expertise. They belonged to different budgets. Their personal goals were set with different managers and not aligned. They belonged to different subteams. They would have to work on other projects outside of the dedicated “team”. Etc. Etc. Etc.

Seeing all these forces working against us made it clear that we had a snowball’s chance in hell of building teams that would actually work as teams. For every action we took to align the team members there would be ten other actions around us that pulled us apart. My guess is that if we would have come much further if we would have focused more of our energy on identifying and redesigning the root causes of the forces pulling people away from each other instead of performing a tug of war with these forces.

Tug-o-war

Some time ago I was asked to work with a “team” that “had problems delivering” and “the few things that did come out of the team was of poor quality” and as if that wasn’t enough, “people were generally not happy about working in the team”.

The “team” – it turned out, consisted of a handful of developers. They got their work from a couple of different business analysts in different parts of the organization and when they were done coding, assigned the work to some testers in another part of the organization. Before taking on the assignment I made one request and that was to get to work with all three disciplines as one team; requirements, development and test. We did a lot of different things together in order to overcome the challenges but the one thing that made it at all possible for us to create a high performing team was the tearing down of old containers and building a new one around the team.

I’m sad to say that the reason I’m so certain about the power of the containers in this case was that as it turned out, the company structure wouldn’t allow for this organization in the long run. Soon after I left the team, group managers once again split the team into three parts; requirements, development and test, each group with their own team lead. None of the other practices we had put in place were strong enough to withstand this break-up and pretty soon everything was back to square one again.

My lesson from working with this team was that it’s not enough to learn to see these invisible structures, we also need to see the incentive systems that put them in place. But I’ll save that for a later post.

Scaffold

I’ve noticed that a lot of organizations seem to have problems with Scrum of Scrums. Some coaches refrain from recommending them altogether while others might use them with low expectations. Without making too many generalizations I’d like to describe one of my more positive experiences using Scrum of Scrums – as an indicator of our ability to work together.

My assignment was to coach a Scrum project with ~100 members and seven development teams distributed over three countries. One of the pains that were brought to my attention early on was how dysfunctional the Scrum of Scrums was. All the ScrumMasters and the project manager would have a teleconference three times a week where the ScrumMasters would take turns giving status reports(!) and complaining about the problems they had. I was approached by some of the ScrumMasters asking me if we shouldn’t have the meeting less frequently since “nothing new is being said. The same problems are being brought up in every meeting.”. I asked them if they thought the real problem was the frequency of the meetings or their inability to solve problems between the meetings. They kind of recognized my point and agreed to continue with the three weekly meetings for a while longer.

Meeting

Meeting

We began to move away from giving status reports and I also suggested that they started to write down the issues that were being brought up and make sure that unless someone claimed responsibility for actually working on an issue, they wouldn’t be allowed to keep complaining about it in this forum. My idea of writing down the issue was to create an excel-sheet or something similar in a shared folder but apparently in this organization, there would have to be a JIRA project to store such information. It also turned out that it would take about a month to create said JIRA project.

Since I had a hard time seeing that JIRA would be the way this problem got resolved, I also started working on other things in parallel. The first thing we did was to get all the ScrumMasters together to get to know each other. I managed to get the funding to fly all ScrumMasters to one of our sites and hold a retrospective and some other workshops. It was a great day with people getting to know each other but it still wouldn’t be enough. When, towards the end of that day, I asked if everyone in the room had everyone else on speed dial, the frightening answer was that no-one had anyone else’s phone number in their cells. Getting this problem solved was easy, the problem was to get everyone to use the phone numbers.

After this day together, I began requesting from each ScrumMaster to call all the others’ on a daily basis. Whether they had an issue to talk about or not, they should at least make a social call to see how the others’ were doing. This didn’t happen immediately; most thought that they’d get away without making the calls but I kept asking them about it in our one-on-one’s.

I can’t tell exactly when the transformation happened, but before the new JIRA project had been set up, I noticed that fewer and fewer issues were being brought up during the Scrum of Scrums. Instead people were having social discussions and talking about problems in a past tense. When I started inquiring about this I learned that there were still a great deal of issues but now they were being solved outside of the Scrum of Scrums. The teams (or at least their ScrumMasters) had begun caring about each other. One team even offered to send some of their developers to another country to help one of the teams there before the other team had worked up the courage to ask for external help.

In a little more than a month we went from having a meeting that didn’t help us coordinate any issues or solve any problems at all, to holding a meeting where there were no issues to coordinate and no problems to solve. This made me realize that the daily stand-up and the Scrum of Scrums might not really be any solutions in themselves, but rather indicators of how well we communicate within our teams – outside of the meetings.

High-fiving the office

February 21, 2013

This morning it took me fifteen minutes to walk past my team and get to my desk…

But that was this morning, let’s back up one month. Middle of January my team had a team building activity. Now, I know that teams aren’t built during an activity but there were reasons behind us having this activity. Anyway, as a final exercise we all got to close our eyes, relax and try to visualize what it would be like if everything in the workplace was going as we wanted. We then got to draw our internal images and present them to each other.

My drawing had two parts to it. One part showing a kanban board where work was flowing smoothly, representing how we worked well together as a team. The second part pictured me high-fiving my co-workers on my way to my desk, representing us having a great time together.

High-fiving

What I saw before me was how it would take me fifteen minutes every morning to move from the entrance to my desk because I high-fived everyone along the way, stopping to ask how they were doing and generally enjoy being with awesome people.

Some background might be in place here. My desk is at the opposite end of the building from the entrance, which means that I have to walk by the entire team every morning as I walk to my place. The thing is, that I’m an MBTI introvert. I enjoy people and company like most other people but it’s exhausting for me. Having a good time with other people makes me physically and mentally tired. Because of this I’ve been taking a detour every morning in order to get to my desk without having to pass anyone I know, that way I could save my energy for “more important stuff”.

As I looked at my drawings I realized that the first part was what we’re struggling with together as a team, but that the only thing standing between me and my vision in the second drawing was myself.

The day after the exercise I stopped for a minute after entering our floor. I took three deep breaths and began the walk to my desk. Only a few team members were at their desks so I walked up to the one colleague who I knew would understand the idea. I raised my hand and immediately got a slap. It felt good and we discussed the exercise for a while. The day after I repeated the ceremony but stopped by two of my colleagues on my way to my desk.

Since then I’ve been adding people to my daily routine and this morning I walked around high-fiving everyone at their desks, stopping to chat for a while; both personal stuff as well as job-related. I timed the walk and it took me fifteen minutes to get to my desk.

What I’ve noticed is that most people’s faces light up as I walk by for the daily slap. The guy next to me was a bit upset though, he didn’t want to always be the last one to get a high five.

I believe in the idea that we are our feelings. If I act happy, then I will be happy and I will feel happy. If I start the day with a smile and a high five, I will get a better day. Fake it till you make it so to speak. The bonus is that people around have to start their mornings with a smile and a high five as well.

So as an introvert, does this procedure consume energy? You bet it does, I have to brace myself every morning before I walk into the room.
Is it worth it? You bet it is!

Disclaimer: Not everyone enjoys a high five in the morning, especially if they’re in the middle of something and that’s okay too.

%d bloggers like this: