In the context of the topic, business is often interested in the fact that even if not in a short time, then how soon it is possible to turn into a team, because it is known that it is “teamwork” that allows you to achieve the most effective results. They rely on leaders - project managers, Scrum Masters, team leads. Someone will talk about the importance of “going to a bar together” at the initial stage, someone - about choosing a name or logo as a way to define and emphasize the identity of the team.
What I like most is the view of the team as a group of people who have had their first successful joint experience. In coaching on a similar topic, I have come across the metaphor of "getting over the fence." In it, the fence is our ability to develop solutions to common problems, and in order to “get over it,” we need warmth, a sense of humor and a desire to work together.
This summer, I started working on a project that is currently one of the highest priorities in the company. Its main goal is to replace ancient legacy backends with modern micro-service architecture and thus make the Telecom world a better place. The expectations are high enough and the pace is fast, which entails strong growth and the need to recruit and launch new teams. One of these new teams was to be assembled and launched by me.
Well, you get the idea.
I plunged into a period of thoughtful selection of candidates that lasted for some time. I got to know people and in an informal conversation tried to find out their point of view on various issues, but with complete retirement and different dates of launching the project, we all did not have a good opportunity to really get to know each other. Nevertheless, the composition of “highly motivated and cross-functional professionals” (we work in Scrum) was gradually recruited.
And, as often happens, at some point the flywheel began to spin faster and faster, and now there is no time to explain, or for a neat kick-off. You need to grab the people recruited into the team and start quickly. At the same time, the pandemic regime has imposed a severe restriction on the possibility of the notorious team building events. Although it must be pointless to regret it: with all the preparations, we still did not have time for a normal acquaintance.
So for the first time we all "saw" each other only in the first planning. And since this was not just planning, but PIP (Product Increment Planning - an event in SAFe dedicated to high-level planning of the work of teams for the next few sprints), then we had to figure out many things in a limited period of time.
Imagine this moment. This is your first experience of such an event. You find yourself in a conference call with nine strangers, and although you have just been declared a “team”, you have no idea who these people are, what skills they really have, and you have three hours to create a “team” together. work plan for the next three months.
You are also somewhat afraid of the difficult task, which is proposed to be decomposed into several points of the plan, since the description is not unambiguous.
By the way, our Product Increment Planning, if it were offline, could look like this.
At first, we literally stood, metaphorically crowded around the existing backlog, and discussed what can be done. In response, the development team often responded only to silence, the process did not go easy.
And yet I, like that fireman, tirelessly beating stone on stone over and over again, continued to cheer the development team in a friendly manner. How an unexpectedly carved spark turned into a small flame.
In response, one of the developers paused and ... just voiced everything that worried each of those present. Uncertainty, awkwardness, a high level of uncertainty ... Yes, all this is there, and we all feel it. But will this prevent us from fulfilling what we have gathered for now? Tell me that!
Suddenly, another engineer confessed his own doubts. And then others. Someone considered their level of expertise insufficient, someone hesitated to ask “stupid” clarifying questions. Someone just felt uncomfortable, because they had just met us, and did not want to make the “wrong” impression.
When we said all the sources of our anxiety out loud, it seemed like it became easier to breathe. Each of us made his own confession, and no one condemned us. The atmosphere was getting warmer. There were jokes.
A timid bonfire flared into a confident bright flame.
Our group of people who barely knew each other felt very differently. Gradually, we developed a strategy for analyzing the backlog. The developers evaluated the requirements and worked together: they discussed what needs to be done and what levels of decomposition are needed for a particular task. All this was immediately recorded in JIRA. Then they distributed the work. Everyone took part in the discussion.
It was amazing to see how they discovered in a matter of minutes that they were all part of the team.
I came across a TED talk on this topic much later.
Meanwhile, Product Owner was also working hard, despite the fact that he had done a good deal of the work before this meeting: after all, he had prepared all the requirements. He explained the high-level goals that the team needed to target, updated the backlog, answered questions, clarified anything that could be clarified.
I, as a Scrum Master, guided the movement of the discussion when it was necessary, preventing the emergence of the feeling that the discussion itself is reaching a dead end.
After three hours of hard work, the team finished building a roadmap against their goals for the next three months, and thus completed the planning.
The next day, Product Owner presented this plan to stakeholders, and, taking into account some small comments on the wording, it was agreed and adopted.
We all managed to do this by acting together. Helping each other, we got our first successful joint experience even before starting work on tasks. On this planning, our team found a common achievement (of course, the first of many). We became the “conquerors of PI planning,” and this gave us the feeling that we were certainly capable of successfully implementing all other parts of our complex project.
And if I was asked: “How do teams become teams? Is this a long process? ”, I would answer that they acquire true team identity when they“ climb over the fence ”, that is, overcome the first difficulty, acting in a coordinated and united manner. And it is the responsibility of the leader to make it happen as soon as possible.
And what exactly he can do for this sounds like a topic for the next article :)