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…

We can't get all Commited user stories done in this Sprint, what do we do?

While we always do our best to manage our capacity, estimates there will always be those moments when something will come up where we will not be able to complete the work we signed up for. There will also be times when we find we have under estimated the amount of work we can get done in a sprint and we will want to take on more work items.

The Scrum framework has a way for us to do this, it is called Renegotiation. Below are a few tips on how to best accomplish this;

• The team should contact the Product Owner no later than three days before the end of the sprint to move / drop / add work items.​
• The team needs to communicate out that the Sprint has been renegotiated and why. As the Scrum Master I have usually handled this for the team by editing our Sprint landing page on a SharePoint portal.
• The renegotiated items should be moved out of the sprint in your tracking tool. The tracking tool I am most familiar with is Microsoft’s TFS, but have also used other tools like Jira, etc.

While on this topic I thought I would share what we do when the team is not able to completely finish a user story. When this happens the team will follow the above steps to ensure the PO is in agreement. Then the team will need to ensure that the tasks that can't be done against a user story are handled correctly. Below is how we have handled this in the past;

• ​Clone the Sprint user story that can't be completed
• Edit the user story that is to stay in the Sprint to reflect the work that will be completed
• Edit the cloned story to reflect the work that still needs to be accomplished

Ideally the plan is to take on the cloned user story in the next sprint.

Calculating Sprint Velocity

Boiled down velocity is the measurement of how much work a sprint team gets done in a sprint iteration. It is the measurement of what is actually “completed” in a sprint, not what was committed to in the sprint. I am using story points in my example below, but when calculating your velocity, just replace story points with the unit of measure you are using to estimate the items in your backlog;

Sprint Velocity = Total story points “completed” in an iteration

For example: if the team took on 360 story point in the sprint but only finished 352 story points. Their velocity for that sprint/iteration would be 352 story points

Sprint Average Velocity = Total story points “completed” to date / number of iteration completed

For Example: You Sum up the values for the 10 sprints below to get a value of 3447.
You then divide it by the number of iterations, 10 in our case to get an average velocity of 344.7 story points

Sprint	Story Points
Sprint 1	253
Sprint 2	309
Sprint 3	357
Sprint 4	377
Sprint 5	365
Sprint 6	352
Sprint 7	360
Sprint 8	359
Sprint 9	355
Sprint 10	360
	Total  SP 3447

                         3447 Total Story Points / 10 Sprints = 344.7 is our average Sprint/Iteration velocity

NOTE: Your velocity usually normalizes after 3 to 5 sprints allowing you to use this number to project how much can be done in the next iteration and ideally how much longer a release will take to complete considering the number of estimated stories remaining in the backlog.

Example Velocity Chart

I usually do not worry about the velocity of the first iteration. I like to let a team use the first sprint to take their best shot at determining how many stories they believe they can take on in their time boxed sprint. The team can always take on more stories if they find they are moving faster than they originally estimated or negotiate items out if they are not completing items as quickly as first estimated.