Castle Syndrome Solution through Scrum of Scrums and Socializing

I have used the Scrum framework for many years now and one of the biggest challenges for me as the Scrum Master has been geographically dispersed teams. I love a challenge and worked to make this one of my specialties and wanted to share a past experience. I was working for a company in Europe that had teams and team members in 4 time zones. When I was tasked with improving the sprint team’s interactions I did some analysis on the problem at hand. While in Europe I loved the castles over there and after my analysis it came to me that the sprint teams in question were experiencing what I called “The Castle Syndrome”. Boiled down the teams were all working in their own castle / team and did not take into account that they were in fact part of a bigger castle, the Kingdome or company. Each team did a very good job and handling their user stories and did their best to ensure their solution was the best they could do to resolve their user stories. The problem was that the teams did not go outside what they perceived was their castle walls.

The first change I did was to use the Scrum framework’s Scrum of Scrums. I needed to get the teams to understand they were in fact part of something bigger. Each team elected a sprint captain and I had this sprint captain attend the Scrum of Scrums meeting to share what they were doing and more importantly learn what the other teams were doing. This change alone helped the teams work better together but did not solve another problem that was evident in my analysis of the teams. As the teams were also of different cultures I noticed that some of the teams put themselves in competition with the other teams.

Competition is usually good, but not in this case as one of the teams was working to prove they were creating the best solutions which lead to duplication of work which is bad. The biggest problems is that the team that put themselves in competition with the others stayed inside of their own castle walls and did not allow themselves to be part of the bigger Kingdome. I have been able to solve most problems with geographically dispersed teams via online methods, but in this case I needed to go onsite. The team needed a meet and greet so to speak.

Once onsite I explained what I was seeing and let them know that were all part of one Kingdome. I then started working through their issues, whether perceived or real. One of the team’s key concerns was that they were afraid that other teams would not take them seriously or not think them worthy from a coding perspective. Because of this the team in question started to rush to get the solutions to problems first or to prove their solution was better or even worse in my mind they would work to prove that any solution from other teams was not as good as their solution.

The way I helped them to get past this was through socializing. I selected the technology leads in the team and matched them with the technology leads from a team in another region(s). I then proceeded to get both parties on the phone and introduced them to each other. Next step was to select a problem that needed to be solved and asked them to work together on it. Sometime this was on Sprint and other times it was off Sprint. In either case I always worked to time box the effort. Once the engineers started communicating one on one you could see the mutual respect start to grow. I knew I was on the right track when I noticed that the technology leads on a team would start to be a spokes person for their technology lead counterpart from the other team allowing the teams to feel and work together as if from one Kingdome. The team also started using each other as resources when one or the other was stuck.

More details on handling cross time zone teams in another post…