The fifth blog, in a blog series about the upcoming book: Creating Agile Organizations - A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.
Blog post How You Can Define Your Product Group described how to create an initial definition of the product by examining organizational functions and components and considering their dependency types. In this blog, we build on that discussion and consider how to launch the product group into its first iteration successfully.
Typical adoption steps
Agile adoption has so many variables, parallel activities, paths, and feedback loops that it is impossible to create a detailed plan upfront. This does not mean that planning is a futile task; instead, it is simply an activity that needs to be repeated. So plan to replan! Figure 1 illustrates a typical sequence of steps we take to launch the adoption.
Figure 1: Typical adoption steps
It can take a few weeks to a few months to get from the first meeting with management until the first product group launch. The reason is that the people involved need to participate in the preparation while doing their usual jobs. If you can halt the people's work, you could probably finish the whole preparation within two weeks.
Why not longer than a few months? From experience, we have learned that overly long preparation drains too much energy, resulting in people losing enthusiasm and their impulse for a change. Also, all the time spent in preparation meetings is time that the group is not learning anything in practice. After the product group launch, the focus turns to supporting the teams and product ownership in the new way of working.
Product Group Launch Activities
Once you have identified the teams that make up your product group, many activities might be required to launch your product group in your specific context. Below you can find a minimal list of actions and workshops that might be helpful (in the book, we provide a more extensive list). Use the ones that fit your particular context.
- 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.
- Identify coordination mechanisms: With the elimination of single-function teams, which coordination mechanisms are required?
From our perspective, the following items make up the Minimum Viable Launch (MVL):
- Create the product DoD
- FTAM workshop
- 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 teams can work across the whole product right from the start.
In the book, we provide examples and facilitation guides for each of these workshops. In this blog, we share an excerpt from the Create the product DoD workshop
Define the Definition of Done
Scrum teams use the DoD to create a shared understanding of which work was completed in each Sprint. As Mr. Ken Schwaber once taught us: Done means that there is nothing left to be done. Elements of the DoD should be measurable and binary (yes/no). You can't be 80% done; Scrum treats such partial completion as 0%. The Scrum Guide explains:
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. (The Scrum Guide. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf.)
The DoD includes measurable properties of the Increment. It is assured through activities, and execution is up to the developers. When your whole organization is just one cross-functional team, then there are no other options but for the team to perform all those activities themselves.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. (The Scrum Guide. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf.)
Problems usually start when teams lack cross-functionality, which happens when organizations create teams around internal business processes, architectural components, and functions to achieve team efficiency. For simplicity, we call such teams "component teams."
Let's have a look at the situation when multiple component teams are working on the same product. Each team performs only a subset—their product-part DoD—of the broader product DoD. Figure 2 shows an example.
Figure 2: Product Definition of Done.
A component team that is organized around an internal business process or an architectural component considers "done" to have been reached when "their" component is tested—but that is not done at the product level! What remains are all the activities in the "undone" subset that still need to be performed.
The smaller the set of DoD activities that a component team performs, the more issues that will appear at the product level—for example, delays, handoffs between teams, and opaque measures of progress. The more component teams that are working on your product, the more partially done work that is created, and the higher the risk of running into unpleasant surprises later on becomes. To avoid this fate, when you develop one product with many teams, there should be a single, integrated increment by the end of each Sprint and a single, shared DoD.
Each component team needs to master all of the activities to produce a usable increment every iteration. This is not a trivial task and can take many years, if it is even at all possible in your specific context.
A Definition of Done Workshop
For this workshop, you need to have your product definition settled. How to define your product is described in Chapter 8, "Preparing the Product Group."
Participants
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. The canvas illustrated in Figure 3 proposes a couple of sections for the teams to explore DoD activities. Adjust the sections as necessary to fit your specific context.
Figure 3: Definition of Done (DoD) canvas.
Structuring the Invitation
The goal is to define the activities that need to be completed so that there is no known work left to be done—the product DoD. We use the following questions:
- What do we need to do so that the product is in the hands of the stakeholders according to company standards, policy, and regulations?
- How shall we measure and make sure that each item in the DoD is done?
The second question focuses the teams on the measures; otherwise, you might end up with a list of aspirations that never come to life.
Example for Running the Workshop
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, or the Shift and Share liberating structure 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 a 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, reduce 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.
In our next two blog posts, we give an overview of:
- Guiding the organization in multi-skill development
- Transitioning to Product Owner at scale