Five Tips for an effective PI Planning Event

Five Tips for an effective PI Planning Event

SAFe (Scaled Agile Framework) is one of a handful of Agile@Scale frameworks used to help multiple Agile teams organise and coordinate to deliver on a vision. No Scaling Framework should be used where it can be avoided, as scale almost inevitably results in a reduction in overall Agility. However, where the vision or outcome necessitates execution across multiple Agile teams and systems you may not have the luxury of operating independent, siloed Agile teams, and this is where frameworks such as SAFe can help.

Agile Release Trains

In SAFe, a group of Agile teams is bundled up into what is referred to as an Agile Release Train (ART). The composition of an Agile Release Train will be based on the delivery of value. The flow of value determines which system assets and skills are required. Similar to the way in which Scrum recommends 5-9 people per Scrum team, SAFe recommends a typical Agile Release Train consists of between 5-12 Agile teams with between 50-125 individuals. In practice, I have run ARTs with up to 15 teams without too many problems. A Program Increment is a time-boxed cadence for the ART which is typically between 8-12 weeks long.

What is PI Planning?

At the beginning of each Program Increment (PI), there is a Planning Event which is responsible for planning the whole of the Program Increment. This is a two-day event where all stakeholders (including teams) on the Agile Release Train participate in an (ideally) collocated event. All teams have their own areas setup for their planning together with a Program Area with a Program Board to map Feature delivery and dependencies across teams.

When you have over 100 people planning together in a single coordinated event, things can get pretty complex, pretty quickly. Here are five tips to organise yourself which I have learned the hard way from having run countless PI Planning events over the last four years. I hope this will save you time and effort when preparing for PI Planning.

When transitioning to SAFe it is important to make sure that the purpose of PI Planning is understood clearly by all participants, especially management and executives. Management of expectations early on is very important, and so is understanding the purpose of PI planning. The purpose of PI Planning is to create an emergent roadmap to deliver a prioritised and agreed set of outcomes as well as identify both known and potential impediments to progress. Essentially, the outputs from the PI Planning event are :

Outcomes for that PI

Emergent roadmap(s)

Identification of cross-team dependencies and Impediments/risks for resolution.

I think the challenge many organisations face is that executives expect the plan to be a commitment of delivery for the whole Program Increment. When done incorrectly it resembles an 8-12 week Waterfall committed phase, where the scope, time, quality and cost are all locked down: very bad indeed, and far from Agile. In fact, you have something worse than Waterfall (which I believe has its place as a delivery approach in an appropriate context), you have something that appears Agile-like without most of the benefits of Agile.

SAFe Criticism

One reason why SAFe encounters criticism is the perception of a long upfront planning horizon, which reduces overall Agility. I think this is fair when detailed upfront planning takes place, however, when done correctly the output from a PI Planning is simply a high-level emergent roadmap for the upcoming PI: not a commitment to delivery. Sure, over time as you get to understand the capacity of the ART per PI, there should be increasing delivery and release predictability, hopefully reducing the pressure for up front long term delivery commitments, which in my opinion is the antithesis of Agile. So, understanding and clearly explaining what PI Planning can give you, and want it can’t, is important to communicate to all stakeholders to overcome any misconceptions.

Tip #2: Preparation

One of the most important tips I can give is to prepare, prepare and prepare some more. You will have a large number of teams and many people, potentially upwards of 100+. Facilitating and coordinating an event of that size and complexity doesn’t happen by chance, preparation is key. Importantly, you need to make sure that you have your inputs into PI Planning well defined, but also understood by all stakeholders.

Vision

Your vision will need to be very clear. This is your overall business vision and objectives, but also the vision for the upcoming PI. At the beginning of PI Planning, the vision will be presented by Product Management or a senior business sponsor for the Agile Release Train.

Features

Having well-written Features is the Achilles heel of many organisations transitioning to SAFe. Have clear, simple, well-written business oriented and valuable features rather than Features describing a technical solution.

Also please make sure that the Features are familiarised with the teams who will be planning these in advance of PI Planning.

If you have component teams then please make sure that you have identified the teams that go on to deliver that Feature before PI Planning. This will save a lot of trouble during PI Planning and make for a far smoother planning process.

Architectural Runway

Understanding the architectural implications of upcoming Features is important to ensure that the teams have an understanding of the underlying architectural approach and system constraints that they have to work within.

Depending upon the system/architectural complexity of your organisation as well as the Agile maturity, you will need to ensure that a level of architecture is understood or even in place in advance of your Program Increment. Hopefully, it will be just ahead of the ART and not too far ahead so you don’t suffer from too much upfront architecture, reducing your Agility. The Lean Principle of The Last Responsible Moment should be borne in mind when deciding how far ahead you should go.

Tip #3: No Surprises

It’s really important that there are no surprises during PI Planning. This means that we need to be really careful when planning our communications, ensuring stakeholders have adequate knowledge on how to perform their relevant functions.

Please ensure :

All stakeholders are familiar with your Features for the upcoming PI in advance.

Block out stakeholders diaries well in advance. In fact, I recommend blocking out all Program and Team Level ceremonies a couple of PIs in advance, this sets the scene, manages stakeholder expectations and improves attendance rates.

Ensure that all teams have been trained in SAFe and PI Planning and what is expected of them. I provide each team with a printed team pack, explaining step-by-step exactly what is expected of each team and when.

Tip #4: Organisation – Focus on organising each detail of the day.

Organising the day in advance is really important. Here are some quick tips for organising your PI Planning event that you may find useful:

Team Areas. Setup the team areas the afternoon before the event. Have each team get their team sheets ready the day before, and setup their area.

Stationary. Setup a stationary area where the teams can go and get their stationery make sure you’ve colour coded your post-it notes so it’s clear what the colour coding means.

Room logistics. Ensure that you have setup the area in advance, whether it’s a PA system, moving desks around or ensuring that you have a presentation area for the morning vision part of the event.

Posters and Information Areas. Have designated points that provide information on the PI from the agenda to the team cadences, to Who’s Who, to the Feature Backlog you are bringing into the event.

Tip #5: Divide and Conquer

When running the Program Increment Planning event, make sure you have recruited a number of people to help you. Here is a table showing the kind of help I ask for to ensure an effective Program Increment Planning :

Program Increment Planning Support Roles

Area

Description

Who

Program Prioritisation Calls

Single point of contact for teams. Will need to make real-time prioritisation calls. May require the involvement of other people in the background but should be a single point of contact.

Program Risks and Impediments

Responsible for collating all non-architectural risks highlighted by the teams and for triaging these.

Architectural Risks and Impediments and Clarification

Responsible for collating all architectural risks and impediments highlighted by the teams and for triaging these.

Security Risks, Impediments, and Clarification

Responsible for collating any security risks and impediments raised and to advise on security questions.

Stationary and Logistics

Responsible for ensuring teams have stationary they require. Ensuring Stationary Area does not run out of stuff.

Catering and Refreshments

Responsible for ensuring that teams are adequately fed with biscuits and cakes!

Cloud Engineering and DevOps Impediments and Clarification

Responsible for collating all Cloud and deployment issues and risks

Program and Team Planning Coach

Coaching, Assisting and answering planning questions of team

Camera Man

Responsible for Photos, Video and Entertainment.

Resourcing and Capacity Issues

Resolve any resourcing and capacity issues.

Program Board

Ensure all cross-team dependencies and key milestones are logged on the Program board.

Planning Day Outputs

Ensures that all required PI outputs are clearly written and as complete as possible. Program Reviewing of final outputs with teams

Break out Rooms

Where phones are required for off-site contact break out rooms are made available

Epic / Feature Definition Impediments

Manage, Own and resolve issues with the definition of Epics / Features so that team can continue planning in a seamless way.

Feature Definition Clarification

Teams will have questions around Features; EBAs will need to be on hand to answer these.

X-Train Liaison

Facilitates communication with the another ART including resolution, tracking and monitoring of requests.

Having an effective Program Increment Planning event is essential to team morale, setting the PI on the right footing as well as both the morale and perception of the health of the program. Preparing well helps reduce the stress and anxiety of running this event and the five tips above will get you started on the right footing. I hope you’ve found the above tips useful, if you have a PI Planning event coming up just put any questions in the comments section below and I’ll try to answer promptly. Good luck with your next PI Planning!