PI planning in SAFe
Scaled Agile Framework, SAFe is an Agile development framework developed by Scaled Agile Inc., essentially a knowledge base for implementing lean Agile development on a corporate scale. Below is a free retelling of the original article "PI Planning - Scaled Agile Framework" .
PI planning session for 190 participants
One of the principles of the Agile Manifesto says that “direct communication is the most practical and effective way to exchange information both with the team and within the team.” This is easy to implement if you have one small team. And what about the scale of a huge company, when there are many teams and their synchronous work is necessary? To do this, the Scaled Agile Framework (SAFe) uses the PI planning tool (PI Planning) - this is the practice of direct communication of all teams, business representatives and other interested parties, who, as it were, are combined into one big team - the Agile Release Train (ART).
')
Communication takes place at regular meetings with a standard agenda: at the beginning of the presentation of business representatives with a story about the current situation, strategy and tasks, then a planning session, when teams create a plan for the implementation of the product increment created as part of the program - Program Increment (PI). Immediately make a reservation: in the terminology of SAFe, to refer to a large number of interrelated commands, the term “program” is used, in the future we will stick to it. All ART members are participating in this session as far as possible. For the facilitation of such meetings, a special role has been allocated - the Release Train Engineer (RTE). He is also responsible for the escalation of blockers, helps in risk management, value delivery and continuous improvement.
For such planning, research, and training activities, a special IP iteration (Innovation and Planning iteration) is provided so as not to take teams in other iterations within the PI. Session lasts from 1.5 to 2 days. The result is a consistent set of program objectives for the next PI.
Geographically distributed ART hold this meeting at the same time in different places, but maintain constant communication with each other.
PI-planning is important to carry out regularly, because it sets the rhythm of the entire ART. This is an integral part of SAFe: if you do not conduct PI planning, you do not use SAFe.
Session PI planning for 250 participants
PI planning provides businesses with many benefits:
The following materials are being prepared for the session: a roadmap, a concept, top 10 priority features from the backlog of the program, and other artifacts for transferring the business context.
The main results of PI planning are:
PI planning is an important event that requires preparation, coordination and communication. Participants of the event: product managers, Agile-teams, architects and engineers, system teams, interested persons - all of them should be notified in advance and come to the event well-trained.
Successful event is prepared in the following areas:
Below is a description of the training in each direction.
It is important to make sure that the program has a strategy that will be clear to the participants of the event, including stakeholders and business representatives, that the teams work is in line with this strategy, that there are people in ART in all key roles.
Below are examples of questions that help determine this readiness.
It is equally important to properly convey the concept and business context, so all the necessary stakeholders should be present at the session. For this, PI planning includes the following activities:
Preparing the venue and the technical infrastructure of the event with a large number of participants is not so easy, especially if there are remote participants.
Below are points to consider.
In general, the event corresponds to the standard agenda, which is shown below. Next we look at each block of the event in more detail.
Standard agenda for a 2-day PI planning session
A top manager or business owner describes the current state of the business and how well current solutions will meet customer needs in the future.
Product managers present the current concept of the program, usually talking about the most important 10 upcoming features, changes from previous PI planning, as well as any future milestones.
The system architect represents the architectural concept. In addition, the senior development manager can tell about the changes in the practices of Agile development, for example, test automation and continuous integration, which need to be considered during the next PI.
The moderator - RTE - explains the planning process and the expected results from the event.
The moderator explains the objectives and plan of the PI planning session for 100 people.
Teams for each iteration estimate the amount of work that they can perform (capacity) and determine the backlog elements that are most likely needed to implement features. Each team creates draft plans that are visible to all other participants, iteration after iteration. At this time, they identify risks and dependencies, determine the draft goals of the team on PI. The team also adds features to the program board.
Teams identify interdependencies in a PI planning session per 100 people
Reviewing plans occurs with strict time limits for each team's performance. At this time, teams present the main results of planning: draft objectives, potential risks and dependencies. Business representatives, product managers, other teams and stakeholders ask questions and give feedback.
The product owner presents a plan collected by her team at a PI planning session for 100 people.
It is likely that plans will need to be refined to reflect the expected scope of work, limited resources and identified dependencies. During this meeting, the management agrees on the scope of work and eliminates shortcomings in the plans. RTE conducts a meeting with all key stakeholders until they can reach attainable goals.
The next day, the event begins with the guide describing all the changes in the planned scope of work and resources.
Teams continue planning based on the results of the previous day, making the necessary changes. They finalize their goals on PI, and business representatives evaluate the business value of these goals.
The results of the planning of one of the teams at the PI planning session per 100 people
All teams will briefly present their plans. At the end of each team's performance, risks and blockers are voiced, however, teams are not allowed to discuss and search for solutions in this short period of time. If the plan is accepted by customers, the team will post flipcharts with their PI goals and risks to the most visible place so that everyone can see the formation of the overall program goals in real time.
During planning, teams discover critical risks and blockers at the entire program level that may affect the ability of teams to solve their tasks. These questions are considered by all participants. All risks, one after the other, are clearly, honestly and openly classified into the following groups:
Program risks at a PI planning session per 100 people
After the risks of the program were considered, teams vote for realism and readiness to take responsibility for achieving these goals of the program at PI. All team members raise their hand, showing from one to five fingers.
Voting rules for PI planning session per 100 people
If on all teams, on average, three or four fingers are raised, then management may assume such obligations. If on average there are less than three fingers, then the necessary changes are made to the plan and all plans are processed. Anyone who holds up two or fewer fingers should express their concerns. This allows you to either identify a new risk that requires re-planning, or simply convey important information to all.
Voting at the rehearsal with participation of Scrummasters and owners of product teams before the PI-planning session for 100 people
If necessary, teams rework their plans until the level of trust in them is sufficient. This is the first moment in the entire PI planning session, when the time constraints go into the background - more important is the coherence of plans and the willingness of teams to take responsibility for their execution.
In conclusion, RTE holds a short retrospective session to determine what went well, what did not, and what could be done better at the next PI planning session.
After that, you can discuss the next steps, add goals and user stories to the IT tools for managing Agile projects, plan upcoming key activities and events ... and even tidy up the room!
Successful PI planning allows you to get three main artifacts.
In this video, our practice is PI planning:
Ps . If you are interested in materials on the transformation of processes in large companies, we recommend the Enterprise Agile Russia group on Facebook. We will discuss approaches to scaling, such as SAFe and LeSS.
PI planning session for 190 participants
Tasks for product development can not be foreseen in advance. Transfer planning and tracking to those who can evaluate the final result and influence how it will be.
- Michael Kennedy, "Product Development for the Lean Enterprise"
There is no magic in SAFe ... except PI planning.
- Authors SAFe
One of the principles of the Agile Manifesto says that “direct communication is the most practical and effective way to exchange information both with the team and within the team.” This is easy to implement if you have one small team. And what about the scale of a huge company, when there are many teams and their synchronous work is necessary? To do this, the Scaled Agile Framework (SAFe) uses the PI planning tool (PI Planning) - this is the practice of direct communication of all teams, business representatives and other interested parties, who, as it were, are combined into one big team - the Agile Release Train (ART).
')
Communication takes place at regular meetings with a standard agenda: at the beginning of the presentation of business representatives with a story about the current situation, strategy and tasks, then a planning session, when teams create a plan for the implementation of the product increment created as part of the program - Program Increment (PI). Immediately make a reservation: in the terminology of SAFe, to refer to a large number of interrelated commands, the term “program” is used, in the future we will stick to it. All ART members are participating in this session as far as possible. For the facilitation of such meetings, a special role has been allocated - the Release Train Engineer (RTE). He is also responsible for the escalation of blockers, helps in risk management, value delivery and continuous improvement.
For such planning, research, and training activities, a special IP iteration (Innovation and Planning iteration) is provided so as not to take teams in other iterations within the PI. Session lasts from 1.5 to 2 days. The result is a consistent set of program objectives for the next PI.
Geographically distributed ART hold this meeting at the same time in different places, but maintain constant communication with each other.
Overview
PI-planning is important to carry out regularly, because it sets the rhythm of the entire ART. This is an integral part of SAFe: if you do not conduct PI planning, you do not use SAFe.
Session PI planning for 250 participants
PI planning provides businesses with many benefits:
- Inside ART, business communication is improving, for many of those who need to do joint projects get to know each other for the first time.
- High efficiency of communication between all team members and stakeholders is ensured. Simply put, if you gather a lot of people together and give them a goal, then this leads to an extraordinary energy of communication. Tested on our experience! (approx. translator)
- Business customers and developers finally hear each other and begin to act cohesively in accordance with the goals of the business.
- The teams start to see the “picture as a whole”, the dependencies are revealed, which pushes the teams to coordinate between themselves and other ART.
- Commands select only the required minimum requirements for the architecture and user interface. This will allow you to meet the planned deadlines and "do not wind up" redundant functionality.
- The scope of work is planned taking into account the capacity of teams, due to which excess work in progress is eliminated.
- Forcing decisions.
The following materials are being prepared for the session: a roadmap, a concept, top 10 priority features from the backlog of the program, and other artifacts for transferring the business context.
The main results of PI planning are:
- A set of SMART targets for PI commands that each team determines independently. Each goal is evaluated in terms of relevance to the business. The goals of all teams are combined into a set of goals for the entire PI program.
- Board of the program, which shows the new features, the expected timing of their implementation and any other milestones with which the goals of the teams are related.
- General agreement with realism and readiness to take responsibility for achieving these goals.
Training
PI planning is an important event that requires preparation, coordination and communication. Participants of the event: product managers, Agile-teams, architects and engineers, system teams, interested persons - all of them should be notified in advance and come to the event well-trained.
Successful event is prepared in the following areas:
- Organization: business consistency and strategy development, readiness of teams and the whole ART.
- Content: management and developer preparedness.
- Infrastructure: location and event logistics.
Below is a description of the training in each direction.
Organization
It is important to make sure that the program has a strategy that will be clear to the participants of the event, including stakeholders and business representatives, that the teams work is in line with this strategy, that there are people in ART in all key roles.
Below are examples of questions that help determine this readiness.
- Scope of work and planning context: “Is the planning framework clear: product, system, technology area? Do we know which teams are needed for joint planning? ”
- Business consistency: “Are priorities agreed between business representatives?”
- Agile teams: “Do we have Agile teams? Are all teams staffed by developers and testers? Are Scrum Master and Product Owner defined everywhere? ”
Content
It is equally important to properly convey the concept and business context, so all the necessary stakeholders should be present at the session. For this, PI planning includes the following activities:
- Overview of the current business context from top management.
- Overview of the product concept, which is prepared by product managers on the basis of the top 10 priority features from the backlog of the program.
- An overview of the architectural concept is usually presented by a technical director or architect to talk about technological innovations to support the implementation of features, as well as non-functional requirements.
Infrastructure
Preparing the venue and the technical infrastructure of the event with a large number of participants is not so easy, especially if there are remote participants.
Below are points to consider.
- Space: the room should be spacious enough for all participants, including places for breaks if necessary.
- Technical support: determine in advance the people who will help you with setting up, testing and solving problems with the technical infrastructure at the event.
- Communication channels: distributed scheduling sessions require main and backup audio, video and presentation channels.
Agenda
In general, the event corresponds to the standard agenda, which is shown below. Next we look at each block of the event in more detail.
Standard agenda for a 2-day PI planning session
Day 1
Business context
A top manager or business owner describes the current state of the business and how well current solutions will meet customer needs in the future.
Product concept
Product managers present the current concept of the program, usually talking about the most important 10 upcoming features, changes from previous PI planning, as well as any future milestones.
Architecture and development practices
The system architect represents the architectural concept. In addition, the senior development manager can tell about the changes in the practices of Agile development, for example, test automation and continuous integration, which need to be considered during the next PI.
Planning context
The moderator - RTE - explains the planning process and the expected results from the event.
The moderator explains the objectives and plan of the PI planning session for 100 people.
Team work - 1
Teams for each iteration estimate the amount of work that they can perform (capacity) and determine the backlog elements that are most likely needed to implement features. Each team creates draft plans that are visible to all other participants, iteration after iteration. At this time, they identify risks and dependencies, determine the draft goals of the team on PI. The team also adds features to the program board.
Teams identify interdependencies in a PI planning session per 100 people
Review draft plans
Reviewing plans occurs with strict time limits for each team's performance. At this time, teams present the main results of planning: draft objectives, potential risks and dependencies. Business representatives, product managers, other teams and stakeholders ask questions and give feedback.
The product owner presents a plan collected by her team at a PI planning session for 100 people.
Management review and problem solving
It is likely that plans will need to be refined to reflect the expected scope of work, limited resources and identified dependencies. During this meeting, the management agrees on the scope of work and eliminates shortcomings in the plans. RTE conducts a meeting with all key stakeholders until they can reach attainable goals.
Day 2
Change of plans
The next day, the event begins with the guide describing all the changes in the planned scope of work and resources.
Team work - 2
Teams continue planning based on the results of the previous day, making the necessary changes. They finalize their goals on PI, and business representatives evaluate the business value of these goals.
The results of the planning of one of the teams at the PI planning session per 100 people
Presentation of the final plans
All teams will briefly present their plans. At the end of each team's performance, risks and blockers are voiced, however, teams are not allowed to discuss and search for solutions in this short period of time. If the plan is accepted by customers, the team will post flipcharts with their PI goals and risks to the most visible place so that everyone can see the formation of the overall program goals in real time.
Program risks
During planning, teams discover critical risks and blockers at the entire program level that may affect the ability of teams to solve their tasks. These questions are considered by all participants. All risks, one after the other, are clearly, honestly and openly classified into the following groups:
- Resolved - the team agreed that the problem is no longer relevant;
- Owned - the issue cannot be resolved at the event, but someone agreed to push the resolution of this issue further;
- Accepted - some risks are facts or potential events that just have to be fully understood and taken into account in future work;
- Mitigated - the team can determine a plan to eliminate the consequences of a given risk or blocker.
Program risks at a PI planning session per 100 people
Voting
After the risks of the program were considered, teams vote for realism and readiness to take responsibility for achieving these goals of the program at PI. All team members raise their hand, showing from one to five fingers.
Voting rules for PI planning session per 100 people
If on all teams, on average, three or four fingers are raised, then management may assume such obligations. If on average there are less than three fingers, then the necessary changes are made to the plan and all plans are processed. Anyone who holds up two or fewer fingers should express their concerns. This allows you to either identify a new risk that requires re-planning, or simply convey important information to all.
Voting at the rehearsal with participation of Scrummasters and owners of product teams before the PI-planning session for 100 people
Redesigning plans as needed
If necessary, teams rework their plans until the level of trust in them is sufficient. This is the first moment in the entire PI planning session, when the time constraints go into the background - more important is the coherence of plans and the willingness of teams to take responsibility for their execution.
Retrospective
In conclusion, RTE holds a short retrospective session to determine what went well, what did not, and what could be done better at the next PI planning session.
After that, you can discuss the next steps, add goals and user stories to the IT tools for managing Agile projects, plan upcoming key activities and events ... and even tidy up the room!
results
Successful PI planning allows you to get three main artifacts.
- A set of SMART targets for PI commands that each team determines independently. For each goal, business representatives determined an assessment of its business value.
- Board of the program, which shows the delivery time of new features, dependencies between teams and dependencies on other ART, as well as important milestones.
One ART program board - Harmonization of all ART teams with realistic PI goals and their willingness to take responsibility for achieving these goals.
Practice
In this video, our practice is PI planning:
Ps . If you are interested in materials on the transformation of processes in large companies, we recommend the Enterprise Agile Russia group on Facebook. We will discuss approaches to scaling, such as SAFe and LeSS.
Source: https://habr.com/ru/post/319460/
All Articles