When Communication Problems Are Symptoms Of A Bigger Issue

Problem

"I currently work as the CTO of Badger Maps, with a team of about 12 engineers. We hired our first four engineers really quickly and then hired a few functional people onto our team as well. However, once we had around eight people, we began to run into some negative symptoms. Meetings started to take a little longer and we weren't able to reach a good level of consensus."

Actions taken

"We started out by trying to address some of our communication problems. However, this ignored the root of our issue - the team size was too large. After we had tried to apply communication rules to our meetings, we realized we needed to take the one big team and split it into two much smaller Scrum teams. We did some research and found out about large-scale Scrum as a way to scale Scrum at your organization. Spotify also provided some great examples of how they handle multiple Scrum teams. I decided to draw a line and broke the team up into two different squads, with three engineers and one functional person on each. We had a couple of brief meetings to discuss the things that would change, how we were going to do sprint planning, and how we were going to do refinement. We then set a date at the end of a sprint for the team to split into the two squads. It ended up going really smoothly. Within a month, we were already seeing great results in terms of the speed we were delivering value and the number of stories we were able to complete in each sprint. Our communication became a lot smoother and our meetings were much faster because our squads came to a consensus much faster. We also realized we needed to work out a few more things, such as communication between the squads when they were making decisions that affected all of the engineers. To do this, we adopted the concept of 'Scrum of Scrums', which is a like a daily stand-up that addresses issues that affect everybody. We used representatives in this meeting to avoid having to have everybody involved, as this would have slowed down the process again. In addition, we set up guilds, which cover specific topics, such as coding standards, DevOps, or QA. The guilds cut through each squad, and one or two people from each squad will attend the guilds, which are scheduled meetings that occur every 1-2 months. The guild members will then bring information back to each of their squads."

Lessons learned

"Don't be afraid to experiment with the structure of your entire team. It's generally better to do this sooner rather than later. If you're seeing communication problems or decreased productivity, there's a good chance that they are just symptoms of a larger issue. If I were to do this all over again, I would have tried to address the issue when I first noticed the issue. For a couple of months, it was difficult to get our engine moving again, and this could have been avoided by moving faster to address the issue."