How to transform Content teams to Product teams

A successful team starts with a group of individuals who have different skill sets. As the team develops and adopts new practices, they demonstrate a culture shift, i.e., understanding values, focus, and ways of working.

According to the Agile Fluency Model, teams need to demonstrate fluency in Focusing, Delivering and Optimizing. Team fluency directly corresponds to organization fluency. It’s crucial for teams to continuously improve and make progress that benefits themselves and the organization.

There is no specific way to attain fluency. So, how can you determine where to invest? Start with analysis.
There are a lot of models and frameworks on how to do analysis. But it’s important to understand that what works for others might not work for your team.
I’ll share my approach to understanding a team’s level and possible ways of further development. I’ll also go over:

• Agile Fluency Model and Squad Health Check model
• Team assessment based on the principles of these two models (at the company level and the team level)
• Some thoughts on how to build a vision for future transformation
• Systemic obstacles for transforming the system
• And finally, I will share the first steps and results.

A team exists in an environment, and the environment influences the team. So, to get a complete picture of all factors that can affect the team, let’s evaluate the team’s place at the organization and then evaluate the team’s maturity.

At the organization level, the Agile Fluency Model was used for the assessment. And the team’s maturity was assessed using the Squad Health Check model.

Here is a brief description of models that were used:

The Agile Fluency Model is used to understand the current overall system’s stage. The model has five levels where your team/stream/organization can be:

• Pre-agile: A system is a group of people working together with a vague understanding of which teams they belong to and their common goal. The main signs of this stage include a vague notion about agile principles and practices and a lack of goal orientation and focus.
• Focusing: The teams are beginning to emerge from the system and adopt agile practices, and a cultural shift is underway. Instead of simply planning specific tasks, like writing a script, the team is beginning to consider the overall goals of its business and users.
• Delivering: The teams in the system are starting to think about how to create product increments with maximum efficiency.
• Optimizing: The teams in the system understand the market demands and are working to address them.
• Strengthening: The teams have achieved fluency in responding to and coping with external and internal challenges.

The Squad Health Check model is used to understand how “healthy” a team is and suggests the following criteria as benchmarks to assess team health.

• Support & teamwork: This benchmark assesses the degree to which teams and their members can rely on one another’s support and the degree to which it is safe to seek help outside the team. This benchmark is also an indirect measure of the horizontal links between the teams within the system.
• Vision & mission: This benchmark assesses the team’s understanding of the company’s long-term vision and the Objectives and Key Results (OKRs) for a specific quarter.
• Health of the content base: This benchmark assesses the content produced by the team.
• Delivery process: This benchmark assesses the rate and ease of an increment delivery.
• Delivering value: This benchmark examines how satisfied the teams are with their product.
• Learning: This benchmark looks at how well the teams learn new information and analyze their own mistakes.
• Speed: This benchmark assesses production speed.
• Fun: This is a personal benchmark that looks at the team’s “health level.” This benchmark can indirectly identify the people who are on the verge of burnout.

Based on everything mentioned above, let’s assess the team.

We will look into the team’s structure, delivery speed, learning ability, and team maturity on the company level.

Team Structure (number of people per team, their roles, and responsibilities):

• Each team has 5–7 members, which allows for effective operations to be organized within a team and the effective adoption and use of agile practices.
• The teams lack a servant leader/scrum master/keeper who would take it upon themselves to track their development dynamics.
• The responsibilities within the teams are blurred.

Delivery speed of the completed increment to production (whether the teams have production practices, necessary tools, speed, quality, focus, the value of the end product, and team autonomy):

• The teams operate primarily using scrum practices (two-week sprints, planning, regular backlog reviews, reflection, and synchronization on both daily and sprint-by-sprint bases).
• The teams understand and keep track of their backlogs using the same rules in the JIRA tracking system. Each team has a playbook that is supplemented by the results of the practices employed.
• Excluding a few rare cases, the teams all produce an increment every sprint, completing 3–4 releases per week.
• The number of times users contact the help desk allows the teams to track quality, and on average, they handle 2–3 cases per sprint.
• The teams have external dependencies on the other teams.

Ability to learn (the ability to adapt and learn from their own mistakes and transfer of knowledge):

• The teams can transfer knowledge — they understand how to do it and why it’s crucial.
• However, they are not particularly good at analyzing their own mistakes or at practice-based iterations.

Team maturity (interaction, correct communication, proactivity, and engagement)

• There are no glaring signs of immaturity, but different teams are at slightly different maturity levels, which impedes practical cooperation. A more in-depth analysis for one of the test teams is included below.

Results:

• The team in the organization (i.e., in the system) is at the Delivering Value level and characterized by high productivity, a small number of defects, a high level of engagement and motivation, and a high degree of focus and delivery.
• The characteristic weaknesses are handling dependencies, risk management, and somewhat loosely defined team roles and responsibilities.

At the team level, we will check trust & safety, dependability, purpose, delivering value, team autonomy, teamwork, continuous improvement, decision-making, sustainable pace, feedback, and integrity.

The team’s strengths are primarily in Support & Teamwork and in Delivering Value.

Meanwhile, its weaknesses are primarily in Vision & Mission, Learning, and Delivery Process.

Now we understand the current state of the team in the system, so what’s next? Let’s continue building the vision and describing the main areas to speed up the team’s growth.

1. A product organization should be set up as a decision-making center for evolving the product and synchronizing and broadcasting the vision from the CPO to the teams.
2. Each team must have a product manager interacting at the stream level with the product directors, who interact with the CPO (a shared product backlog is necessary).
3. Each team must become self-sufficient in its ability to deliver product value. This means that each team must possess enough content writers, QA specialists, etc., in addition to a producer and a team lead. Functional responsibilities, in this case, will be distributed as follows: QA must be in charge of delivery and quality; the team leads and the content writers must handle content quality, and each team producer will be in charge of supporting the existing team in terms of visuals.
4. Remember that formal division of responsibilities within a team is not permitted and that the entire team must be responsible for the quality, delivery, value, etc. The functions described above are intended only to stress that the team must cover the entire scope of work to minimize its dependence on the other teams (to avoid having purely component-based teams).
5. However, the caveat is that everyone in this group is a member of the team. Ideally, we want to organize and coach the team to be in charge of delivery and continuous improvement, along with the teams, processes, and products for maintaining continuous improvement and delivery processes.
6. The overall conclusion: The creation of cross-functional teams needs to be completed to take active ownership of the continuous improvement and delivery processes. Since the tested system is currently at the delivering stage, it needs to transition to the sustained optimizing stage.

Of course, we have blockages on our way to a better team; let’s analyze the systemic obstacles for transforming the system’s current state.

1. The teams are not autonomous: Many dependencies are not accounted for during planning or product release, often triggering unplanned risks.
2. The teams lose focus: Priorities change; the teams have to act under conditions of uncertainty, and the organization of the current production process doesn’t allow them to tap the team’s full potential.
3. There is a lack of synchronization in product planning and release, often producing overlapping tasks in the backlogs.
4. The teams do not have the necessary continuous improvement processes (retrospection doesn’t always work; retrospection sessions themselves are not regular, and stand-ups turn into status meetings).
5. The teams haven’t been assessed for the presence or absence of all the necessary skills for successful product delivery.

A cause-and-effect diagram (see the figure below) clearly shows that the constraints described above can be grouped into four categories:

1. Lack (or lack of understanding) of requisite skills in the teams: A skill matrix should be compiled for the staff with the required competencies. The most recent problems with product releases should be examined during retrospective meetings to understand what competencies were lacking on a specific team (not just specific team members) to pull off a successful release. This should result in a clear understanding of each team’s competencies to increase its autonomy to complete the bulk of the work within the group without asking for external help.
2. There is poor communication between product managers and, as a result, a lack of a shared vision and a common backlog. In addition, there is poor vertical dissemination of information through the teams (from the product to production) and overlapping tasks in the backlog.
3. There are weak horizontal links between engineering and content production caused by a lack of a value delivery plan (this lack can be indirectly affected by the previous point). The simultaneous launch of a large number of experiments, in addition to the lack of transparent backlogs in engineering and product analytics, results in a situation where some dependencies are only discovered very late in a release.
4. The teams need to invest more in their development. They shouldn’t be afraid to raise issues during retrospection meetings, take responsibility, look for the causes of their failures, and find time for continuous improvement.

The analysis has been completed. Now we need to focus on the implementation of systemic changes. We took the first steps of this long journey and decided to do the following: build a work alliance to implement systemic changes.

Building the work alliance began on two fronts:

1. The formation of an agile community. The goal is to set up a group of like-minded people to spread agile culture (cross-pollination), share experiences, and serve as a center of collective intelligence. A place is needed where people can discuss complex issues about how they approach their work, discuss and adopt new practices, create an Agile Playbook, develop standard methods for tackling work tasks, validate their actions and behavior, reflect on their work and the work of their team, and prepare a set of tools to use each day. The function of the agile community will be to support a shift in organizational structure. This is a more strategic area with the overall goal of effecting change on teams or departments and across the entire organization. An agile community canvas was developed, and the community’s goals, values, rituals, and rules were presented.
2. The more tactical front involves working in teams. The goal is to refine the continuous improvement process, develop general rules of operation, and disseminate team practices. At the top level, we need to host quarterly meetings about OKRs. The entire team drafts a list of initiatives and ranks them via an ICE scoring model, with a quarterly backlog of prioritized objectives. The quarterly backlog is then broken down into the key results we want to achieve this quarter, and beyond that, further broken down into specific initiatives. A retrospective meeting is then planned to look at the results of each quarter. Each team has weekly tactical and strategic meetings. The former is aimed at discussing the current work at hand, while the latter is for strategizing. Each team lead will be focusing on: preparing the tools to assess the necessary skills in the team; launching the goal-setting process and personal OKRs for each team member; establishing the 1:1 process with employees; defining readiness and completion, with teams learning how to conduct scoring using ICE methods.