from global goals to specific tasks

Scrum masters of an IT company RDP.RU told how PI planning is carried out in Kaiten

A few words about the company

Company RDP.RU is part of the Rostelecom group of companies and specializes in the development of innovative software and hardware and software systems for high-performance processing of network traffic. The company's products are widely in demand in carrier-class networks, large enterprises and the public sector.

What problems can Kaiten and PI planning help solve?

In our work with one of the key customers from the Public Sector, we encountered difficulties in communications and opacity of processes; standard communication tools and methods were ineffective and we started thinking about improving interaction.

Some of the main problems we tried to solve:

Problem #1: the customer wanted to communicate directly with engineers and developers, have a minimum number of intermediaries, thereby reducing communication time and communicating his vision directly to the performers.

Problem #2: different teams work on different products, these products together form a comprehensive solution that brings core value to the customer, but sometimes there were difficulties in synchronization between teams, misunderstanding of the impact of dependencies between products, which led to delays in the final delivery of the solution and customer dissatisfaction.

The current interaction model did not meet the customer’s needs for efficiency and efficiency. It was necessary to come up with a new format.

Then we had the idea to try the Kaiten visual process management system, which was supported by the development director. The goal was to create a cross-functional business process between all stakeholders. So that managers, customers and performers in all areas can see what is happening without intermediaries and receive analytics when they need it.

Due to the scaling of the company and the growing number of inter-team dependencies, we decided to turn to SAFe 6.0 – this is a framework designed for the implementation of flexible development methods in large companies of 100 people or more. It is used when a company has moved from a startup to a matrix structure; business processes are becoming more complex, but the company wants to remain quite agile.

What is PI planning

One of the events within SAFe is PI planning (software increment planning) is an event where business owners (Business Owners) and all teams (Agile Release Train) define high-level goals and plan their work for the quarter according to these goals.

An Agile Release Train (ART, or train) is multiple Agile teams that continually participate in a single value stream that benefits the customer. They jointly plan, commit, develop and release this value.

A software increment is a period of time, up to 12 weeks, during which teams complete planned work on a project.

PI planning usually lasts 2 days. All project participants come together to set goals for the new period, critically evaluate how feasible they are, and hear feedback from customers.

During PI planning, task visualization is necessarily used and relationships between levels are built. In our company, this is Epic – Feature/Enabler – Tasks. This helps teams see how a specific point task relates to the company's overall goal, and also highlights dependencies on each other – until one team does its part, the other cannot complete the next one.

The result of PI planning is a detailed 3-month plan that includes agreed upon team goals, tasks to be completed, and a risk assessment.

This gives a feeling of stability and helps bring the customer and teams closer together.

• Teams, who work on the product every day, can hear directly from the customer the requirements and expectations. The customer broadcasts the goals of a specific quarter, and all participants understand where to go.

• Customer sees what tasks the team takes into the plan and how it decomposes them. He can ask his questions directly to the performers.

• All participants take on obligations and know exactly where they will be in a quarter. This eliminates situations where the customer may say “that’s not what I meant at all” or when the team will say “we didn’t take into account the risks, so we didn’t have time.” Because during planning all these issues are discussed openly.

PI planning creates an environment in which the brain works faster. All participants are ready to discuss sensitive issues here and now, and not postpone issues until some meeting.

How PI planning works in practice

In our case, planning is carried out once a quarter in the format of a live meeting. It involves 16 teams working on different sub-products, business owners and customers. To date, we have held 5 such events.

3 levels of work item hierarchy

We decided that we would have 3 levels of work item hierarchy:

• the highest level is epics — global goals at the level of business representatives;

• the second level is features and enablers. A feature is a piece of functionality that provides value to the client. And the enabler is the technical support task that ensures the creation of this value;

• then the features and enablers are decomposed into tasks are work tasks that teams of performers interact with every day.

Each of these levels has its own type of cards in Kaiten, as well as a special place for visualization – separate boards and spaces.

During PI planning, we need to synchronize the work of all participants in the process in such a way that the resulting tasks of each team lead to the fulfillment of global goals and do not contradict each other.

Preparing for PI planning

Preparation is an important step, without which PI planning will not be effective. Before the general meeting, work elements are determined and decomposed at each level:

• business representatives set key goals;

• the product manager, system architect and Release Train Engineer break down these goals into their components and carry out top-level development of ideas;

• Agile teams, together with the product owner, break down developed ideas into tasks and form their backlog.

Thus, all planning participants select ideas and tasks in advance, which they will then need to synchronize with each other – find dependent tasks and agree on at what stage which team will complete their part of the delivered value.

We visualized this process in Kaiten:

At the epic level, we have a top-level end-to-end process for the entire Agile Release Train, which ensures the delivery of value. To do this, in Kaiten we have a top-level space where we display epics. It shows all the stages from the origin of ideas to their development, implementation and release.

When a business comes up with an idea, it is worked on first at the top level, and then goes into the “Team Preliminary Evaluation” column and is sent to the team space for technical evaluation:

The team responsible for a certain sub-product breaks down the idea into features and enablers in their space. Working through the task includes a description, determination of readiness criteria and evaluation in story points. After this, the cards go into the “to plan” column. This means they are ready for PI planning and the preparation phase is complete.

Immersing teams in a business context

PI planning itself takes place in 2 days. All interested parties gather in a conference room and communicate with each other personally.

It all starts with immersing teams in the business context. The customer describes what problems need to be solved, and the company’s top management focuses on top-level goals.

This allows teams to understand the big picture and move beyond point-to-point thinking. As a result, development teams not only receive a task, but understand the business goal – what exactly needs to be done and why. They have room for maneuver and the ability to independently propose a solution to a specific goal.

Iteration planning

Then people disperse to their teams. Their task is to agree and distribute features and enablers into two-week iterations for the quarter ahead. From the “to plan” column, they distribute the cards into columns on the team-level planning board:

Next, they also need to sort out the tasks, which are the constituent elements of features or enablers, into iterations.

Here, for each iteration, it is important to take into account the capacity of the team: how many tasks it can handle. Kaiten's average team speed report helps with this. We know exactly how many story points the team can complete and, accordingly, how much work it can take on per iteration.

Also, when planning iterations, we leave buffers for teams for unplanned tasks so that they have room to maneuver.

Defining dependencies

In the process of distributing tasks across iterations, teams need to identify dependencies and synchronize with each other, because some tasks are at the intersection of different products.

We visualize dependencies on a special board in Miro. It marks iterations and global goals. And at the intersection there are tasks for which there are inconsistencies. The dependencies themselves are indicated by red arrows.

Once dependencies are identified, teams need to agree on who will do their part of the work and in what iteration.

Risk identification

Another step that is performed as part of PI planning is to identify the risks that we may face while executing the plan.

First, the team records the risk backlog on a special board. And then they are divided into 4 columns by category (according to the ROAM model):

• Accepted – risks that we accept and assume responsibility for;

• Owned – risks for which a specific person is appointed responsible. He will monitor the development of the situation and take measures to reduce or eliminate them;

• Mitigated – risks for which we formulate a plan in advance for how we will act if they occur;

• Resolved – risks resolved during the planning process itself.

The cards contain detailed information on all risks, assign responsible persons if necessary, and use tags to indicate which teams and products this risk may affect.

Protecting team plans and voting

Once the iteration plan is complete, dependencies are defined, and risks are addressed, teams move on to defending their plans. Typically, protection takes place in two stages:

1. Pre-defense at the end of the first day of PI planning, when teams bring in drafts and management gives feedback.

2. The teams then refine and submit adjusted plans at the end of the second day of PI planning.

All participants discuss the teams' plans, analyze dependencies and can leave their comments.

For convenience, we have a separate space in Kaiten, which shows what features each team will work on, broken down by iteration:

An important ritual in protecting plans is a five-point assessment of the level of trust in your plan. Each team member shows with his hand how much he believes that this plan is feasible. If someone gives a low rating, this is a reason to talk about what risks they see and find a solution.

Completion of PI planning, implementation and control

After the teams have secured all plans and identified risks, all that remains is to record the final plan, congratulate all participants and begin the new quarter.

In a space with top-level goals (epics), cards are distributed in two columns:

• mandatory (Committed) – those that we undertake to fulfill;

• optional (Uncommitted) – those that we plan to do, but we take into account that there are risks that may hinder us.

It is important that business owners and customers determine the business value for each goal and write it down on the card as a coefficient from 1 to 10. Then we can evaluate how much this value was achieved.

Then the actual implementation of the plans begins. The teams already have a detailed backlog for each iteration. They take ready-made tasks and drag them onto the working Kanban board in accordance with their replenishment algorithms.

During 2-week iterations, Agile Release Train teams meet with each other to discuss whether each team is moving in the right direction, how effectively dependencies are being resolved, and whether there are any problems.

At the end of iterations, teams provide finished elements of the system functionality and demonstrate them to the customer. He, in turn, can give feedback.

Also, at the end of iterations, we return to the top level of goals and evaluate how successful we were in achieving them. On each goal card we indicate the actual rate of its completion. That is, if the goal was rated 10 and completed 100%, then the Actual BV (business value) field will be 10.

This helps us control how the execution of specific team tasks affects the final value for the customer.

Were you able to achieve your goals?

Having gone through several cycles of PI planning and visualized the work of teams in Kaiten, we can confidently talk about the results achieved at the level of the entire company.

• Productivity has increased significantly. Each team knows exactly what tasks it needs and does not need to do to achieve top-level goals. Accordingly, the amount of “work for the sake of work” has decreased. Teams do only what will bring results.

• Transparency and trust have emerged between performers and customers. Kaiten allows you to generate analytics that show the number of tasks, effort, progress on tasks and other metrics. This becomes a good argument for a constructive dialogue with customers. They see that our words are substantiated and supported by analytical data.

• The company's management now has a tool for quickly tracking progress with minimal costs. It is enough to track top-level tasks, which automatically reflect all progress on subordinate tasks. This allows us to quickly obtain up-to-date information for making management decisions.

Conclusions and work on mistakes

In conclusion, we would like to talk about the mistakes that companies often make when conducting PI planning, as a result of which the result does not coincide with expectations, and the tool itself is considered ineffective.

Mistake #1: Thinking that perfect planning can be done the first time. It takes time and experience to understand the basics, learn how to thoroughly prepare for planning and organize team communication. The first time is usually a trial run and serves as training for future events.

Mistake #2: Not communicating to all levels of employees “why we are doing this.” A fairly common situation is when management decides to hold a planning meeting, and employees perceive it as “another unnecessary meeting” because they do not understand what its point is.

Mistake #3: Insufficient immersion of teams in the business context. At the beginning of planning, the product owner and customers need to communicate in detail to the teams about the current situation and the overall goals of the business. Otherwise, it will not be possible to build a connection between specific tasks and common goals.

Mistake #4: Do not take into account the different speeds of teams. For some, two days will be enough to plan their tasks, but for others this will not be enough. This greatly depends on the level of preparation of the teams for planning.

Mistake No. 5: Indiscriminately inviting absolutely all teams to the first planning session (“in case they come in handy”). Until the tool is tested, it is better to invite teams with a large number of dependencies to planning and gradually add participants, rather than inviting everyone. For example, if a team does not influence global goals in any way and does not interact with other teams, then participants may not understand why they need it, and even begin to sabotage the event. In such a situation, you can invite at least one team representative who, if necessary, can answer questions or contact colleagues for clarification.

My colleagues and I will be interested to hear your opinions. How do you plan when there are multiple teams? Have you tried PI planning? What auxiliary tool did you use? What advantages and disadvantages of this format do you see? Let's discuss.