The phases and the underlying needs, ds I have already explained in my previous articleserve as the basis for this article, which is about how you can help your team in the forming phase. In this context, you will learn:
- What are the needs behind this team phase?
- As a Scrum Master, what topics can you bring into "forming"?
- How do you recognize that "your" team is moving on to the next phase?
To understand how you can support your team in the "Forming" phase, it is important to know the characteristics of this phase. The "Forming" phase occurs when a new team is formed or the team members in an existing team change. In the latter case, this phase can also be very short, for example during a meeting. In the first case, the team usually goes through this phase more clearly, but can also quickly move on to the next phase, "storming". In this blog, I will discuss both cases and provide a few practical tips.
Before I go into this, it is helpful to remind ourselves of the team's central needs in the "forming" phase. It is important to note that these are not the only needs. During forming, team members are looking for direction and exploration. Team members' knowledge of each other, the team's purpose and the product is limited. As a Scrum Master, it is your job to fill these knowledge gaps and provide answers to the key needs of safety and belonging.
Forming phase: Closing the knowledge gap about the team
To get to know each other and learn more about the new team members, it is helpful in the interpersonal area to organize a joint event outside the workplace. For example, you could arrange a dinner together in a restaurant after work or a relaxed barbecue. In this way, you create space for orientation within the social structure. Team members can also get to know each other better in private conversations and fulfill their need for belonging.
You can also create specific opportunities in the office so that team members can close the gaps in their knowledge about the team. Schedule an official kick-off workshop or get-to-know-you meeting. In addition to other points, which I will come to in a moment, you should have time and space on the agenda for getting to know each other professionally. As a minimum, the following questions should be answered:
- Name
- Skills
- Position/role in the team
- Professional experience
- Internal or external
I also recommend allowing time for questions so that everyone doesn't just rattle off their ideas. Of course, you can also use introduction games if this is appropriate for your team. By getting to know each other professionally, you not only provide orientation, but also create security by making it clear who is here why and what skills they bring to the table. By asking questions, the members can find out who has what knowledge and what the team dynamic is like.
Closing the knowledge gap about the product in the forming phase
Team members also have little knowledge about the product and the way the team works together in the "forming" phase. As a Scrum Master, it is your job to actively address and close these knowledge gaps at an early stage. You can use a kick-off workshop for this at the beginning. A possible agenda could look like this:
- Scrum - an overview
- Getting to know and assigning Scrum responsibilities
- Understanding and defining Scrum events
- Presentation or definition of the product objective
- Structure of the initial product backlog
Scrum - an overview
It is advisable to provide a brief overview of the Scrum process to ensure a common language. This gives the team security and orientation in the way they work. It also gives you as Scrum Master a precise overview of who has what knowledge about Scrum and where there is a need for action.
Getting to know and assigning Scrum responsibilities
Work out together with your team what exactly the Scrum responsibilities involve. Always use the current Scrum-Guide! This makes it clear who has which tasks: the Product Owner, the Scrum Master and the developers. It is also important to work out where the activities of the individual responsibilities overlap. If necessary, add tasks from your specific product environment.
In this context, I also recommend defining who assumes which responsibilities.
Understanding and defining Scrum events
The team members should then get to know the Scrum events in detail. It is worth focusing on the following points and applying them to your own product and environment at the same time:
- Purpose of the event
- Participants of the event
- Timing and frequency of the event
- Responsibility for the implementation of the event
- Processing steps during the event
- Expected result after the event
In this way, the team members gradually close their knowledge gaps regarding the procedure. The next points primarily serve to close the knowledge gap about the product. Both aspects contribute to security and a sense of belonging to the team and the product.
Presentation or definition of the product objective
Is there already a formulated product goal? In this case, the product owner should present this goal. If there is no goal, it can be developed together. In my experience, even if a product goal has already been formulated, it is worth reviewing and sharpening it together with the team. This allows the team members to test the goal, gain more certainty and develop a stronger sense of belonging.
Structure of the initial product backlog
If there is still enough energy or at another meeting, you can create the initial product backlog together. Collect requirements that arise from the product goal and try to concretize them step by step. At this point, I recommend using story mapping as a tool. If you want to learn more about this, take a look at Jeff Patton's method.
Building up the product backlog also creates security and a sense of belonging to the product and the team.
Conclusion on the forming phase
I find the "forming" phase in the team quite relaxed. However, I have repeatedly found that the two subsequent phases, storming and norming, can be much more difficult if the needs of the team are not sufficiently addressed. So my tip: take enough time to get off to a good start.
How do we deal with later additions to the team?
If the team changes due to the arrival or departure of members, it can fall back into this phase - to varying degrees. It is therefore worth planning a team event for such events, such as a meal together after work. In the case of departures, you can then include this in the sprint retrospective. For new hires, you should divide the above topics among all team members and explain or show them to the new person. If everyone is involved, everyone can quickly get to know each other better.
Do you have any other experiences or tips? Then please leave a comment.
Write a comment