Are you getting ready to launch your product group’s first iteration? It’s an exciting time, but it can also be nerve-wracking. That’s why we’ve put together a list of activities and workshops that we find useful for a successful launch. Think of it as a menu of available choices to pick and choose from, not a one-size-fits-all solution. We encourage you to use the ones that fit your specific context and make your launch as unique and memorable as your product itself. Ready to dive in? Let’s get started!

• Initial Product Backlog Refinement: The initial set of features to start the first Sprints.
• Define the Definition of Done (DoD): Everything a team has to do to a feature so that the product is ready for delivery to end users with the new feature added to it.
• Feature Team Adoption Map (FTAM): Align on the feature team adoption first step and potential next steps toward the perfect cross-functional team.
• Self-Designing Team workshop: Facilitate a Self-Designing Team workshop where people volunteer to be part of a team.
• Team lift-off: Facilitate lift-off workshops to lay a solid foundation for team identity and success.

• Facilitate decision making: Create decision rules that will guide the product group and teams in their work.
• Identify and launch communities: Launch communities to address cross-cutting concerns within the product group.
• Identify coordination mechanisms: With the elimination of single-function teams, which coordination mechanisms are required?
• Create useful checklists: Reduce uncertainty by creating checklists that address typical problems in a large-scale environment.

From our perspective, the following items make up the Minimum Viable Launch (MVL):

• Create the product DoD
• Feature Team Adoption Map (FTAM)
• Self-Designing Team workshop
• Team lift-off

You might consider running other activities after the launch—for instance, during regular Sprint Retrospectives or at the first Sprint Planning; This is perfectly okay. For a small product group with three to five teams, you can even exclude the FTAM step if you understand that teams can work across the whole product right from the start.

The critical point is that teams are the crucial stakeholders for the launch. Therefore, you should co-create a high-level plan with them beforehand. Failing to do so can result in disengagement and provoke challenging behavior.

The launch duration varies from a single day to five consecutive days. Shorter launches feel more energetic, but some activities are inevitably postponed. Longer launches drain energy and might seem daunting for the teams, especially if they had gone through a long preparation period.

Create the Product DoD

Scrum teams use the DoD to create a shared understanding of which work was completed in each Sprint. As Ken Schwaber (co-creator of Scrum) once taught us: Done means that there is no known work left to be done. Elements of DoD should be measurable and binary (yes/no). You can’t be 80% done; Scrum treats such partial completion as 0%.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product (Scrum Guide).

A Definition of Done Workshop

Invite the teams, people in coordination roles, product management, and other specialists that your product definition says are required. Consider adding sales, marketing, and general management participants as needed.

• Step 1. Each team/table group plots their current DoD on their canvas using sticky notes. Generate the DoD list of activities and corresponding measures. First work in pairs for 5–10 minutes; then consolidate the results onto the group canvas.
• Step 2. Compare across the groups, using a diverge–merge technique, UX Fishbowl,9 or the Shift and Share10 liberating structure4 to enrich each group’s canvas. Ask the teams to update their canvas based on what was learned.
• Step 3. Assign each section of the canvas (e.g., the Design & Development section) to a separate group and ask them to consolidate the results of all groups for that section onto the central canvas. Remove duplicates and combine similar items.
• Step 4. Ask all the groups to take a few minutes to review the result, determine if it still acts as their DoD, and recommend how to improve or clarify it.
• Step 5. Capture the result as the initial product DoD that everybody can live with.
• Step 6. Close with a short retrospective and answer any open questions.

Once you have agreed on the product DoD, the next step is to determine how much of the DoD each team can pick up, and how they could broaden their component scope.

Feature Team Adoption Map (FTAM)

The book Large-Scale Scrum: More with LeSS introduces Feature Team Adoption Maps (FTAM). An FTAM nicely expresses feature team adoption status and potential next steps for improvement. An FTAM has two axes. The x-axis represents activities that teams need to undertake to conform to the DoD, while the y-axis represents the architectural decomposition of the product.

At the bottom of the y-axis, you can find several components—for example, “DB” and “Web.” Most teams work on one of these components. On the x-axis, you can see the activities obtained from the product DoD. The x-axis reflects the level of cross-functionality. Note that the component teams cover only the DoD subset—code, design, testing, and deployment; that’s the “Start” situation. Several other single-function teams perform the remaining DoD activities—for example, one team does only “Analysis and content,” another team does “Analyze results,” and so on. The “First Step” area in the FTAM shows how the teams broadened their architecture scope and DoD scope. They decided to combine several single-component teams into teams that cover broader subsystems:

• Customer Information teams, each mastering Siebel, ESB, and Database skills
• Product Sales teams, each mastering Portal, Web, and App skills
• Product Marketing teams, each mastering Web and Sales Force skills

This broadening of components was combined with a broadening of the DoD to include:

• Analysis and content
• Target group selection

The green area in the FTAM shows potential future steps. Its presence means that the teams will have an imperfect DoD.

Self-Designing Team Workshop

With the FTAM in place, the teams understand which activities and components each team should master. In the unlikely case that your starting teams already cover everything that is required, you are done. The teams can remain as they are. However, it is more likely that your starting teams are too narrowly specialized and need to be redesigned to match the required skills and capabilities. To do so, the teams need to answer the following questions:

• What is the best possible team composition?
• How can we create the best set of teams for the product group as a whole?
• Which factors should we consider when composing teams?

To answer these questions, we employ an approach consistent with the self-organizing principle of Agile organizations, moving from a command-control management culture to self-management. We prefer bottom-up knowledge and facilitate the team members to use their self-managing capability to design the teams themselves. The role of management is to set boundaries that optimize the product group—that is, to facilitate and to not constrain the outcomes to their own knowledge and references. The paradox of structure comes into play here. We might think at first that having no structure maximizes creative ability, but in fact the opposite is true! Some structure is needed. Of course, the amount and kind of structure is highly dependent on the teams’ maturity. Managers may become too overoptimistic, delegating authority too early for a team, when it is not ready to take responsibility and showed no successes before.

Below you can find the feature team passport – an example of a barely sufficient structure that can trigger self-organization and help form cross-functional teams. ​​

You could also use some other constraints and even co-create those with teams beforehand. For example:

• Between three and nine members.
• Able to cover the “First Step” area of the FTAM.
• Team members have the ability to learn their desired skills from each other.

Before the Self-Designing Team workshop, we often run a Market of Skills exercise to help people get to know each other better. That activity becomes even more important in large groups where there are many strangers.

Running Self-Designing Workshop

• Step 1. Discuss the constraints, FTAM, passport, checklist, and room setup. Then facilitate the creation of one ideal prototype team that meets all the criteria on the checklist. Capture the prototype team on a wall for future reference. Communicate that the goal is to create N such teams as best we can. During this step, it’s normal to change the initial constraints and expand or reduce them.
• Step 2. Ask the people to walk around the room, find a seat in a circle and introduce themselves, discuss their passports, and create a team in line with the prototype team. People are free to move around between circles as much as they like. Leave the room and return after the 20-minute timebox.
• Step 3. Upon returning to the room, ask the teams to complete their checklists and compare them to the prototype team. Each team identifies where they should improve (add or remove skills or people), communicates it to the complete group, and makes it visible on their flipchart.
• Step 4. Another round: Invite the people to improve the teams. Ask them to move around between circles as they please, and to join other circles that are in need of their expertise. Introduce themselves, discuss their passports, and see if the team comes closer to the ideal prototype team. Leave the room and return after the 20-minute timebox.
• Step 5. Upon returning to the room, ask the teams to complete their checklists and compare them to the prototype team. Each team identifies what they are missing and would like to add, shares it with the group, and makes it visible on their flipchart. Repeat the exercise beginning with Step 4 until the group is satisfied with the team designs.
• Step 6. Have each team create a name and present themselves to the group.
• Step 7. Debrief with a short review and open questions.

Team Lift-Off

The starting phase of a new team is the golden opportunity to lay the foundation for team success. People come together for the first time, and there is usually a good atmosphere. We call this the “honeymoon” phase, where things are amicable, conflict is low, and everything seems possible. People are curious to learn about others and want to be accepted in the group. Roles and responsibilities are unclear and all seem to get along well. After introductions, the group seeks structure and direction and requires clarification on the following issues:

• Deep introductions to each other
• Why they are here and what is expected from them
• How they will work together
• Team roles, tasks, and responsibilities

People also likely have concerns about safety and inclusion, so significant discussions are still avoided as much as possible.

This phase passes quickly into a phase characterized by much more conflict. Why? Because as the teams start to work, pressure to perform increases and the differences in perspectives and preferences create tension within the team. To maximize the chances of navigating this turbulent phase successfully, we recommend laying a solid foundation during the “honeymoon” phase that the team can refer back to in times of need.

During the starting phase, a team is very dependent and reliant on its leaders. As a coach/Scrum Master, you will often assume the lead role initially, which is okay for a short time. The team looks to you for guidance and direction, and that’s what you can give them. Remember that you lead only temporarily, and your first intention is to lay a team foundation for success. You might want that to suggest teams to:

• Create a shared purpose
• Align on shared values and behavior
• Agree on a decision-making process
• Clarify the team goals

Create a Shared Purpose

The first step is to discover a purpose, a sense of belonging, and the beginnings of predictable behavior to achieve that overall goal. Teams function better when they have a sense of purpose, and when they feel that group goals and tasks are meaningful, are interesting, and challenge them to think and work to their full capacity. When people have a sense of purpose, their commitment and performance increase.

Agile teams can find their purpose by answering the following questions:

• What is the reason to do this work? The product vision and our personal aspirations.
• How do we contribute to achieving the product vision? The team’s actions and expected outputs.
• How do we know that we are successful? The team’s measures for success.

Align On Shared Values and Behavior

Values themselves are rather abstract by nature. Thus, people tend to understand them differently. Besides, we cannot know for sure the real intentions and motivations of people, as those are hidden; however, we can observe and measure their actual behavior. The following approach we found useful in our practice:

1. Find shared values.
2. Clarify values.
3. Agree on specific behaviors.
4. Create a 360-degree feedback loop.

Facilitating Decision-Making

Teamwork requires making many decisions along the way. If decisions are to be implemented successfully, one needs to have “buy-in” from the people affected by them. It’s hard to get this buyin if people haven’t been involved in the decision-making process. Servant leaders aim to build consensus in teams so that everyone supports decisions while avoiding groupthink. During the launch, it’s useful to define what exactly real consensus is, consider the necessity of the decision-making rules in teams, learn why people disagree, and employ simple techniques for building a consensus.

Five-Finger Consensus

Five-finger consensus encourages the group to listen carefully when there is disagreement and encourages attentive listening to different points of view. It also helps to avoid a groupthink effect. But it doesn’t permit a proposal to be watered down due to the fact some disagree.

Decision Rules

Agile values assume that decisions should be made collaboratively. For example, at the Sprint Retrospective the entire Scrum Team participates. Teams often use only one “default” rule, the majority rule, when solving any issues that arise in their work, without even considering that this rule can do more harm than good on some issues where the support of the majority of the team is needed. The possible decision rules with the corresponding pros and cons are as follows:

• Majority rule
• Delegation
• Super-majority rule
• Multi-voting
• Consensus
• Unanimous

Teams do, indeed, benefit from having clear rules by which decisions will be made. Why? Because such rules decrease complexity and the level of ambiguity and are wheels for faster decision making. We recommend conducting a special alignment workshop with the team to create initial decision-making rules that they will use afterward.

Summary

Launching starts by defining a common Definition of Done (DoD) for the product group. This step becomes possible after you’ve defined your product and appointed the Product Owner. Instead of focusing on component team velocity when defining metrics, each team should measure feature velocity, which reveals the whole system’s capability to ship items to the customer. Next, you can conduct a Feature Team Adoption Map (FTAM) workshop. During this workshop, the composition of the future teams is revealed, as well as the next steps to expand cross-functionality. Team design can start with a Market of Skills exercise and a Self-Designing Team workshop. It’s important to create teams’ identities and an atmosphere of trust at the beginning. That’s covered in the team’s lift-off: creating a shared purpose, identifying measures of success, and performing actions and experiments. Agreeing on a concrete set of values and patterns of behavior is important, too.