In this article I share the case of mitosis – splitting a large team of 19 people into two independent feature teams working from a single Product Backlog. After the division, I helped the teams create a common identity and agree on norms of conduct. This case is just an episode of Agile transformation in a business unit of several hundred people.
Context
We are in the process of Agile business unit transformation, with 15 teams and dedicated functions (marketing, magazine, CRM) creating a product ecosystem for SMBs ( small and medium-sized businesses). In the current structure, each team is assigned a local Product Owner and Product Backlog. In the target picture, the organizational structure consists of multiple clusters or Value Areas with 4 or more feature teams working from a single Product Backlog. Why? Thereby the organization can develop the capabilities that management believes are key to executing the business strategy:
- learning fast
- high adaptability
- work on the highest value items
The pilot Value Area was chosen as the credits, but there was a large team of 19 people in the payment cluster that was going to split into two teams and further specialize, creating local queues and Product Owners for the new teams. We suggested scaling correctly and using Scrum-pattern mitosis instead.
(Figure 1: current and target state of the Value Area)
Mitosis
A typical approach to scaling is to specialize teams. We call this product fragmentation. Over time, this approach reduces adaptivity and causes a number of problems (Figure 2):
- dependencies
- loss of domain and technical knowledge
- increasing complexity of the architecture
- suboptimal technical solutions
- the need for new resources
(Figure 2: product fragmentation and reduced adaptability)
We recommend using Scrum Pattern mitosis, in which the cells (teams) inherit all the properties of the parent cell. This means that the teams do not specialize and continue to focus on the whole product (Figure 3).
(Figure 3: mitosis)
Preparation
Preparatory work at the organization level included:
- Business unit audit (Go See).
- One day training Designing Agile Organizations for executives.
- In-depth three day LeSS training for management, Product Owners and techleaders.
- Defined the boundaries of the product as an ecosystem for SMBs.
Immediate preparation for the workshop included:
- Discussing the facilitation plan with the Scrum Master of the cluster.
- Creating a presentation, preparing the goal/agenda/desired results of the meeting.
Mitosis and Professional Scrum
At the beginning of the workshop, we discussed the goal of splitting into two feature teams, as well as the reason for creating a Product Owner Team. We agreed on the following criterias for success:
- Two feature teams are formed
- Product Owner Team is formed
- Norms of Conduct are created.
Then we discussed business unit Agile transformation and the place of the payment cluster in it, the target organizational structure of the business unit. We answered all developers’ questions related to Scrum events in a scaled context: Sprint Planning, Multi-team PBR and Retrospective. After that, we were ready to move on.
Constraints and self-organization
It is wise to rely on self-organization to create teams because the context is complex and there are no obvious solutions. The people doing the work can find the possible composition themselves. It is also more likely that the developers will take responsibility for the outcome because they own it. Self-organization occurs when there is a clear goal and simple constraints are set. People exhibit complex behavior within simple boundaries (Figure 4).
(Figure 4: constraints and self-organization)
The only initial constraint that we had was Definition of Done (DoD). We proposed future teams to come up with additional constraints. We generated those in small groups and then pinned the final criterias in an open discussion:
- Definition of Done (DoD)
- A web developer must be on one of the teams and not be a traveler
- Mixed gender composition (boys, girls)
- Mixed composition of inhouse and outsource development
- Knowledge of Kazakh, English and Russian languages.
- Remote workers on every team.
Consensus was sought using the Roman vote (Figure 5).
(Figure 5: roman voting)
After that, we were ready to form new teams.
Self-organization workshop
We invited everyone to form teams in 15 minutes with respect to the constraints set. We also created a station for each future team by sticking electrostatic tape on the walls. We asked each developer to write their name on the sticker and place the sticker on the right station. We also split the remote developers into two streams, running two Zoom conferences on laptops and carrying them in our hands. After the first round, the teams could not meet all the constraints. Unfortunately all the remote workers were on the same team.
We needed a second round, in which we asked everyone to find a solution themselves and self-organize. Finally, in half an hour two feature teams were formed and a Product Owner Team as well.
Team Names and Metaphors
In order to create a common identity for the teams, I asked them to come up with a name and visualize a team metaphor. The metaphor should depict the participants and the team should be able to explain everyone's place in the picture. The task is creative and takes half an hour. And what fun it is to watch from the sidelines as the group transforms into a team! We then asked the teams to take turns presenting names, metaphors, encouraging them to ask clarifying questions. In Figure 6 you can see the final teams’ names and metaphors.
(Figure 6: teams’ names and metaphors)
Norms of Conduct
According to Richard Hackman's research, one of the key conditions for developing an effective team is to develop norms of conduct. From the systems thinking perspective, this is also true because:
“The effectiveness of a system is determined by the interaction of its parts, not by how well they function separately.”
Interactions can be established with the help of the Scrum Pattern Norms of Conduct.
To begin with, we decided to inspire the teams with the Scrum values: Commitment, Focus, Openness, Respect, and Courage. After briefly reminding them of their meaning, we gave 15 minutes to generate concrete and measurable patterns of behavior that would support them.
After the timebox was over, teams presented examples of behaviors in open discussion. We discussed and accepted them with a roman vote one by one. Here are some of the norms the teams generated:
- Each meeting should have an agent, a goal, a timebox, and notes that are sent after the meeting is completed.
- If problems arise, such as a bug, the developer is responsible for describing the problem, finding the cause, and coordinating with stakeholders.
- Developers are responsible for coordinating and dealing with external dependencies instead of bringing them to the Product Owner and asking for help.
- At meetings, everyone is actively involved; there are no distractions for extraneous tasks.
Next Steps
The teams have an agreement that after a few Sprints they can shuffle again if the composition is not optimal. Also they are going to use the norms of conduct during Sprint Retrospective as a tool for 360 feedback.