The journey to becoming a team

Building a new team is hard. But when a team works well together, it makes the dream work.

I recently went through this journey with a new team, going from strangers to a jelled team over the course of a year. The challenge was huge, involving a project with complex software components, tight timelines, and a dispersed group of engineers working together for the first time. There were ups and downs, joys and stress, but eventually we succeeded and celebrated one of our dearest and most valuable experiences of working as a team.

I will walk you through the five stages of team development (forming, storming, norming, performing, and adjourning), outlining the practices that helped us to bond, overcome challenges, and perform better as a team, in the hope that you can learn from our experience.

The project

We were assigned to build a mobile SDK for securing online purchases. The SDK was expected to be compliant with the payment security standards, built with the latest technologies, and flexible and lightweight, so it could easily be integrated into any iOS and Android mobile shopping app. It was also a new component on the market and we wanted to be the first ones launching it, which added significant time pressure.

We started as a mixed group of iOS and Android engineers, a product owner, and an engineering manager who also acted as an agile coach, distributed between two countries and four office locations. We had a few veterans in the team but also a freshly promoted tech lead and a few graduates in their first professional engagement.

Stage 1: Forming

The forming stage is all about getting to know each other, understanding the scope of work, and defining the working process. During this stage, a group establishes their team identity and the members create a sense of belonging in a team.

It’s important to aim for clarity at this stage. Everyone should understand each other’s role in the team and their respective responsibilities. Leaders should try to reduce the scope ambiguity and start by introducing a simplified process.

Our approach

We started with a ‘Meet the team’ activity to introduce ourselves, sharing the following insights:

• Core expertise (our areas of certain knowledge or experience)
• Strengths (what we are good at and what we bring to the team)
• Weaknesses (where we might need support)
• Concerns (what worries us or makes us feel uncomfortable about the project)
• Expectations (what we expect from the team and from this endeavor)

Next, we created a roles and responsibilities matrix. We drew up a list of typical tasks performed by a development team and all other expected duties and mapped these to our roles within the team. This was a great way to clarify who would be doing what.

The next step was to work together to map out the product scope, making sure that we all understood what the product would be and do. We visualized this using a chart with four areas:

While the product owner explained the high-level features and functionalities, the team mapped them on the chart, along with any questions, uncertainties, potential extensions, technical opportunities, or technical limitations. Next to the product chart, we kept a list of all the buzzwords and business terms that were mentioned (these later ended up in our glossary).

Lastly, we agreed on the duration of the iterations and the ceremonies we’d be doing. We drafted the Definition of Ready and the Definition of Done. The tech leads introduced the technology stack, the security policy that would be followed, and the basic coding conventions.

We also decided to name the sprints by songs. For each sprint, we had a song that set the rhythm of the sprint and reflected its goal. This helped to make the goals easily memorable and was a great way to encourage bonding.

Stage 2: Storming

During the next stage of storming, a group starts to gain each others’ trust and everyone becomes more confident with the topic. This is when some folks start voicing their opinions and conflicts arise. The important thing here is to aim for alignment; agree on your expectations and streamline all your communication to move together towards the goal. Continuous reflection and inspection are the best ways to steer the ship forward during the storming phase.

Our approach

When we hit the storming phase after a couple of sprints, we responded by coming together for a brief team health inspection in the form of a workshop.

We started the workshop with a simple, but powerful energizer called a ‘Visual phone’. Each team member wrote a statement on a sticky note and passed it to the next person who had to draw a representation of the phrase; they then passed it to the next person who had to write a sentence summarizing the drawing. This was a fun bonding activity that also conveyed an important message about the difficulties of communication and its interpretations. It was a great opportunity for reflection and the team came up with some inspiring quotes and beautiful drawings on teamwork.

For the team health inspection, we used a variant of the Squad Health Check Model. During the exercise, we highlighted many team strengths such as ‘great team spirit’ but also some shortcomings including ‘lack of focus, because of other parallel assignments’; ‘insufficient time for learning the new topics’; and the ‘need for more specific, short-term goals’.

In response, we reshaped the tech lead role to become fully committed to the team; we organized a bootcamp on advanced security topics to accelerate learning; and we introduced simple, specific iteration goals. These efforts helped us to navigate the storming phase as a cohesive team.

Stage 3: Norming

After the two initial turbulent stages, a team enters a phase of stability and comfort. Rather than airing concerns or criticism as they were before, folks share productive suggestions for improvement through technical extensions, product enhancements, or process optimizations. Their enthusiasm increases and everyone takes on greater responsibility for the project.

Our approach

By this time, we had found our way as a team. The product was taking shape and we had the first demo available. However, our backlog of features was too big and the delivery milestone was approaching fast. Some security topics were way too complex and required advanced skills, and mentoring the newbies was also demanding.

There was also pressure to start promoting the product in order to secure the first pilot customers. The situation escalated and that impacted the team’s mood. We had to do something to improve morale and further optimize our process efficiency.

To overcome these challenges, we made good use of Management 3.0 practices and tools. We used ‘Kudo cards’ so that team members could appreciate each other’s achievements and give gratitude for everything they were accomplishing (which was a lot). Although it wasn’t easy asking a demotivated team to give recognition, the cards soon started piling up with kind messages. This was a great mood booster. We even used the cards to create a colorful poster to hang in the team space (we also used a printout of the team goal and the product roadmap as motivational wall decorations).

As a complementary activity, we used the ‘Celebration grid’, a framework that looks into all the experiments the team has done, and regardless of the outcome –  success or failure – focuses on the learnings. We drew up a long list of learnings and agreed to apply many of them as good practices and process improvements.

These efforts paid off as the team soon gained confidence and the destination became clearly visible. We were back on track!

Stage 4: Performing

By the time a team reaches the performing stage, they are closely bound, commitment is high, routines are well established, and progress is notable. At this point, a team is mature enough to deal with conflicts in a constructive way and to take decisions on their own. The focus is fully on reaching the goal.

Our approach

By this stage, we had grown to a healthy, mature, and capable team. We had solved the most complex security and encryption challenges, the components were successfully interconnected, and most of the functionalities could be showcased.

Confident about our capabilities, but also aware of our limited capacity, we acknowledged that it wasn’t going to be feasible to implement the full scope by the release date. Due to compliance requirements and expected certification, descoping wasn’t possible. We needed to make other pragmatic, but bold decisions.

Simply increasing the team capacity wasn’t an option as it would have brought us back to the storming stage (due to Brooks’s law). Instead, we carefully isolated the functionalities with fewer dependencies and delegated them to a team of experts (architects). This significantly offloaded the team.

Putting emotions aside, we also agreed on purchasing some of the components instead of building them ourselves. And we reprioritized and released the first tech guides, along with a professional demo, so that we could promote the product before it was ready. This bought us valuable time while we were undergoing the compliance certification processes.

We also cut down our team ceremonies to quick check-ins about progress updates and obstacle removal. Everyone demonstrated extremely high dedication and a willingness to support wherever would be most needed. It was a great joy seeing the puzzle coming together.

Stage 5: Adjourning

When a team reaches their first big milestone or releases the first major version of a product, it’s important that they acknowledge it as an end of a phase. Taking time for closure and celebration helps a team to wrap up their activities and freshly transition into the next stage of product development or maintenance. And it is an occasion to celebrate!

Our approach

As our project came to an end, we ran a two-day offsite, combining a team retrospective with a fun event. Together, we built the project timeline, working from the date we started up to the release milestone. We looked back proudly on so many events, wins, failures, and significant learnings.

It was a very rewarding experience. Within a year, we had evolved from a group of strangers to a jelled team. There was not a single resignation. A few teammates got promoted to seniors and some decided to change their path from engineering to product and business roles.

Reflections

Every team experience is unique and authentic, and the journey to becoming a cohesive, effective team is often rough and takes time. It’s important to remember that trust and mutual respect are the cornerstones of teamwork. In the words of Linda Rising, ‘Collaboration is not about liking each other. It’s about respect for each others’ abilities & contributions.’

By understanding the stages of team development and the challenges each stage brings, you can be better prepared to guide and support your next team. Accepting and appreciating the process will accelerate your success and make the entire experience more pleasant for everyone.