Team Communication

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games.

In StarCraft, as in an organization, a big danger in terms of teamwork is when people draw circles around their field of expertise and stop feeling responsible for the world outside. Statements like “it’s my game, if you are getting overrun by the enemy, that’s your problem” sum up a common attitude among amateur team players. When the teammate is in trouble, instead of using the opportunity to either help to defend against or attack the enemy, new players tend to blame their partner.

In Scrum, this problem is approached by making the core team into a multidisciplinary team which is able to deliver the whole product without having to coordinate every step with other departments. Its members work on all tasks, as opposed to being nothing but specialists in their respective fields of expertise. There might still be outside specialists providing expertise in a support function, but they are not actually working on project tasks. There still is a bubble, but it is set up in a smart way.

In StarCraft, a comparable element to specialization can be found in the early part of the game, when one player decides to follow a single-minded build order to rush the enemy with a certain advanced type of unit instead of also building basic units to help the teammate against an early attack. Yes, you might be faster by focusing on just your own base, but ultimately, you will sacrifice the advantage of joint team operations. These kind of strategies are called “cheezy” for a reason: they have a good chance of working if you are lucky, but in general, if your teammate does not protect your back and can fend for himself, you might lose.

In Kanban, the “bubbles” around the Kanban teams are being removed. When the work in one project phase is piling up, either this can serve as a signal for upper management to fix the bottleneck, or the one team simply helps the other until the number of “work in progress” items is again below the limit. This is nothing different than helping out your teammate in StarCraft by defending against an attack.

Now, how do you interact with your Agile team? The best team knows how it thinks; it knows how every team member acts and reacts without having to check. The basic principles of Agile ring true here as well: personal contact is better than abstract communication. The most effective teams have moved from sharing text messages to voice chat. And they have not done it because text messages would not convey the necessary information. Voice chat simply offers a means of constant communication and synchronization. It reduces the possibility for errors when you describe what you do and also re-focuses the team constantly on the objectives instead of getting lost in details and micromanagement—a common novice mistake.

The downside of voice- as well as text-chat is the immediacy, which can also be distracting. In your Agile teams, make sure to log and reduce external distractions by channeling them in one place (e.g., a central email address for all questions to the team) or focusing them in regular meetings.

Beyond mere information exchange, a critical factor of good teams is trust. If they do not know each other, people on a team will have trouble knowing whether the other team members will come to the rescue. Working with teams, my recommendation is to make sure that they can build a healthy, trusting relationship with each other. One symptom of unhealthy team relationships is when one of the team members plays the “hero,” thinking the team or project needs to be saved. Here, Kanban can help by predicting the workload of individual team members and explaining how a “hero” will eventually become a bottleneck.

As with teams in StarCraft, teams in your business also have to “play” together. It takes a while until a team has formed, and formed teams usually consist of compatible personality types who know each other’s strengths and weaknesses. Be aware when, due to some management decisions, teams are broken off: new teams will have to invest a significant amount of time to form themselves.

Finally, StarCraft and Kanban have the most important thing in common: respect. While you can find mean and self-centered people everywhere, in StarCraft, there is (or was) a certain culture of respect. A common courtesy is to wish your opponent good luck at the start of the game, and tell him that it was a good game at the end—instead of hurling insults against him. Respect is also a pillar of Kanban. Of course you respect your team, but you should also respect all the project stakeholders instead of plotting or scheming against some of them. This does not necessarily mean agreeing with everyone, but at least hearing them out and trying to take their views objectively. And treating them like human beings. When you leave a project, thank the stakeholders for their trust in you and for the work you both managed to do together. Likewise, if someone from your team leaves, thank them for their work rather than complaining about people leaving the team.

Who are the stakeholders in StarCraft? Well, obviously the enemies! Sure, you could build your great base and gather all the resources from the map, but where is the fun in playing alone? Your enemy helps you to become a better player. Your enemy helps you to shape the actual product you are both working on: an exciting game to play and watch. That is the reason you both started the game. Your enemy stands symbolically for the “market demand,” just like (some) stakeholders can represent the market. Show them respect. Build trust between each other in order to enjoy the game together.