Identity Symbols for Agile Teams
We have dozens of agile teams in our company and we are in the agile transformation for 2 years now. We had great progress with the agile practices so far, but there was one thing that kept disturbing me — the teams had no name nor identity symbol. Some teams had a name that was either a combination of the product name and their location (like “Contact-Center Pune team”) or had the name of the technical module they are in charge of (like “Audio Team”).
We wanted people to feel part of a team and for that the team will need a name and an image. We have gathered all the Scrum Masters on a Slack channel and started to create a CoP (Community of Practice) world-wide. We have discussed there the importance of team name, but nothing really happened. After some time, we decided to work 1-on-1 with some teams and help them come up with a name. Once we had a few teams in hand, we requested them to publish their cool new names on the CoP Slack channel and explain the meaning of the name for them.
Short after, many other teams joined the party and started to come up with cool names by themselves. A couple of month later and 70% of the teams have name. At some point, one of the Scrum Masters offered his service and using his graphical skills and he started to create images for the teams based on their names. He made an amazing work and today we have images for all the teams. The company I work at is Avaya, so we decided to call those names Avayatars (Avaya + Avatar).
I want to talk a bit on the mindset affect that the team name had on the team members. Let me start by saying that our starting point was that manager brought people to work, as opposed to work being brought to teams. Teams were tightly related to a specific portion of the product (usually a specific software layer). Their old name indicated that (e.g. “Audio Team”). I often heard the statement that a team member was extracted from the team to other work. When I asked what this “other work” is, the team said that one of their team members works on a work-item out of the scope of the team’s product area. I kept saying that we should look on that in a different way — this “other work” was simply brought to the team and it is now part of the team’s backlog, no one was extracted from the team. However, my statement didn’t get through — the next time a work-item from module-X reached the team that was named “module-Y”, the team thought “we are module-X team, so module-Y work items are not part of our scope, which means that one of our team members is now extracted from the team to work on module-Y work item for some other team”. The change in mindset came along when the name of the team was changed. For example, one of the teams changed their name from “module-X” to “Hakuna Matata”. Once that happened, it was easier for the team to consider module-Y work-items as part of their backlog. They took ownership on that as a team. It became easier for Product Owners to distribute work-items across the teams.
A few examples of the names the teams picked up:
- Pancakes: a team based in Argentina. The team explained to me that they had a long debate on the name and they couldn’t decide. In Argentina, a person that can’t decide is also called a pancake, so the team decided on the name Pancakes.
2. Comrades: a team based in Russia. No need to explain.
3. Arya: the team based in Pune. The team selected Arya because the Seven Kingdoms of Westeros would not have survived without the efforts of Arya Stark. In a similar way, the success of the team product in the marketplace depends on the efforts of that specific team.
For more information on this topic, please refer to Management 3.0 Identity Symbols.