When we talk about agile transformation and digital transformation, companies often form new teams or redefine existing ones. Not long after this change, questions such as “Are we actually a team?” often arise among one or more of the teams. In this article, we take a look at some of the reasons a group of people may be faced with such doubts, as well as practices that can help improve matters.
Why don’t we know whether we’re a team?
It’s strange, right? If you’ve been called a team, how come you’re not sure whether you really are a team?
First, what is a team? I really like the definition by Rafael Sabbagh:
“A team or crew is a group of people who work together and collaborate in seeking a common objective.”
Simple and straightforward, right? Yes, if you’re together and know what your purpose is, your objective. Otherwise, things can get complicated. Let’s talk a little about what the purpose is, the objective.
- Is not simply taking part in the same meetings.
- Isn’t just being physically in the same place.
- Means collaborating in creating a product or service.
- Means empathy for other people’s work and to help whenever possible.
- Is “more us, less me and them”.
- Is to build an environment of trust and freedom which allows people to interact, exchange ideas, and constantly receive feedback.
A team objective:
- Isn’t just a nice expression the boss said.
- Isn’t delivering features X, Y, and Z.
- Isn’t achieving the goals of the whole company.
- Should be something everyone recognizes, understands, values and is motivated by.
- Should be clear, simple, direct and shared.
- May come as a directive or inspiration from management or the organization. However, it is necessary that the team identifies with it.
- Should be something that everyone is trying to achieve, at least in the medium term, from which it is possible to derive smaller objectives that can be achieved at each interaction, so-called Sprints if you’re using Scrum.
By analyzing the state of the first two points above, you’ll be able to answer the question “Are we a team?”. If the answer is no, don’t despair, at least now you know the answer. That’s the first step, and now we can take a look at what to do so that a group of people really does become a team.
How to become a team?
Working with Scrum, in order for the group to become a team, the Scrum Master plays an important role because it is (s)he who will facilitate the meetings and the daily work. He or she will also remove any obstacles causing the team to remain distant, and will foment communication, feedback and interaction with the development team and the P.O.
For working together and also to define the objective, facilitation and team building practices are essential. Here are a few tips to help:
One practice I like a lot is “Is/Isn’t, Does/Doesn’t”, created by Rafael Sabbagh, because it’s simple and easy and can be applied in various ways. For example, we’ve used it to define a team’s attributes and actions and also individually for each team member. We used the latter recently with one of our clients so that people got to know each other better. They’d been working on the same “team” for almost a month and weren’t even aware what the others did. So we asked each of them to do their own “Is/Isn’t, Does/Doesn’t”, and then had them present what the other had written down, giving priority to those who knew each other the least. One adaption we found interesting was to include a “Tools used/Tools not used” when talking about individuals. In this particular case, it was very useful for each to be aware of the technology and tools used by the others.
As an Agile Coach, one practice I’ve tried and found very useful for getting to know the team and promote empathy is “One Word”, which I came across on Paulo Caroli’s website. I’ve used it in Sprint Retrospectives and Sprint Planning with various teams, asking each team member to describe in one word how they feel about the last or next Sprint. The interesting thing about this practice is that it reveals the temperature of the team to whoever is facilitating, and at the same time foments empathy among team members. For instance, it enables those in conflict to start to see the other side. I usually ask them not to use compound words, which makes them think more about what they going to write and generates richer discussions when they come to sharing their feelings.
In order to understand and align a team’s objective, it might also be worth doing the Decantation Tank proposed by Danilo here at K21, which allows us to understand everything from the purpose to the next feature or story to be developed.
Are you going through a similar moment of questioning? Try these tips and tell us how you got on, we love feedback!
Want to know more about this topic? Check out these links: