Hans Samios' Personal Lean-Agile Knowledge Base

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Why Should We Name Our Team? ======

When we establish Agile Teams we ask that Teams create a name, and that name reflects something meaningful to the Team Members. 

Why do we do this? Often management will object to this process. They ask "Wouldn't it be easier if we just called the Team based on what they do? What's wrong with 'the Database server team'". And then ask "How will I remember all these different teams names and what they are really doing?"

The main reason we establish a Team name is to help establish a Team identity. Naming starts the process of building a real Team; a group of people with a common goal, holding each other mutually accountable. 

Think about it for a moment. My favorite college football team is "Alabama" (don't groan - stay with me here - add in your favorite sports team if it makes you feel better). Do we called it the "Alabama University College Football Club". Well I am sure someone does. But most know it better as the "Crimson Tide". It has a catch call - "roll tide". It has an identity independent of what the people on the Team do day to day.

Teams at work are no different. Team naming helps to establish Team identity. They are a source of pride. They are often fun and so contribute to engagement. They help Team members become accountable to each other and support bonding.

To establish a Team naming approach in your organization, you will probably need to set up some "acceptance criteria" both for the organization and the Team. Here are some that I have used in the past:

  * Cannot be related too closely to the work you are doing
  * Should be able to write the name using English (or whatever the primary language of your organization is) alphabet
  * It needs to pass the "Google test". In other words, if you key the name into a Google search, nothing horrible comes back 
  * Cannot be the same as or too close to another name at the organization (this assumes there is a list somewhere you can check against)
  * Teams should remember the name will be used for both internal and external communication
  * Team must reach consensus on the name. This means team members can say "I agree to this name and can support it (like it was my suggestion)”
  * Reminder: when naming your teams remember [[https://strategic-thinkingnow.com/the-art-of-possibility/|Rule Number 6]]

There is one other advantage to having team names that may not be obvious at first. Agile approaches encourage prioritization of work based on value to be delivered. However traditional planning approaches tends to focus on what we think people do. So, for example, "we have a database server team so we should ensure these people have work to do". By abstracting the team name, it may help us realize that the database server team is full of smart folks that can take on all kinds of work or rapidly learn any new skills required. Perhaps the most important thing this group of people could work on is not "database server work" but "new platform development".

Having said that, we also need to deal with the legitimate concern that some will find it hard to map team name to what the team does. Organizations will often adopt a convention such as "when we send out an invitation to a new event, the subject is prefixed with "team name (focus area)". This is probably most useful in new transformations. Over time, people involved with a particular teams will just remember that and use the team name without the need for translation.  

=== Facilitation ===

  * Lead: Scrum Master
  * Time: 10 mins
  * Materials: Sticky notes / sharpies for brainstorming (optional)
  * Outline: Team discussion

{{tag>FAQ Team Name ScrumMaster}}