Over 20,000 enterprises worldwide in nearly every industry trust the Scaled Agile Framework (SAFe®). Since 2011, companies have been embracing this methodology to achieve business agility for their organizations and to continually provide value to their customers. SAFe was developed to help organizations successfully operate in today’s increasingly complex and global world.
One particular ceremony credited with being the “secret sauce” that holds the Scaled Agile Framework together is the PI Event, or the Program Increment (PI) Planning Event. Closely aligned with SAFe’s key practices, activities, ceremonies and rigor, the PI Event is a cadence-based activity that serves as the glue to synchronize and align the business and development teams for ongoing delivery of maximum customer value.
The PI Planning Event is an integral practice for organizations running SAFe. This event effectively aligns everyone in the program, answering the questions “what are we going to do, why are we doing this, and how are we going to get it done.” It’s an intense two-day effort that has proven successful for companies with complex programs that span multiple teams, time zones, vendors, and/or touchpoints.
Below are 8 key questions that frequently come up in our conversations about PI Events and the benefits of this process.
The PI Planning Event occurs on a regularly set cadence, typically about every 13 weeks (quarterly). The event identifies the delivery path for all of the teams and external parties, from now until the next PI Event. The process is intended to create alignment across teams and produce a working plan, including dependency mapping and risks.
There are many benefits to running a PI Event, and here are the top ones shared by our clients:
The PI Event bridges business and technology within the organization, and it is important that all key leaders and stakeholders participate in the two-day session. Exhibiting lean-agile leadership from the top helps ensure maximum success. Additional key participants include business owners, product managers, system architects, UX architects, quality assurance professionals, product owners, scrum masters, developers, testers, and designers… essentially, all members of the program participate in the event. Other non-program participants, such as sales and marketing, external development teams, etc. may participate as needed to help set the vision and larger business context, support transparency on the roadmap, provide visibility into tradeoffs that might occur during the process, and own dependencies for program team work.
Prior to COVID, PI Events were primarily run in-person. The face-to-face communication and real time problem solving are extremely helpful and crucial to the program’s success. However, since the pandemic, Scaled Agile has adapted and iterated, and now provides tools, templates and resources to run an efficient and effective remote PI Event.
The most challenging PI Events are those that are hybrid, with some resources in person and some remote. This approach unfortunately has been proven to decrease engagement, minimize voices, and it makes the already difficult task of facilitation even tougher. Fully remote or fully in person events tend to be the most successful.
There is considerable preparation required prior to the PI Event, and there are several key inputs to help make the event successful. The first part of the event is spent level-setting, ensuring all participants have a common understanding of what the organization is doing and why they are doing it. This includes a business overview of the company’s upcoming vision and goals, as well as a technical vision for the architecture and development practices.
Another required input for the event is an understanding of the top features to be tackled over the next 13 weeks. These features are clearly defined, and sequenced in delivery order, prior to the event. The feature definitions serve as a ‘north star’ for the work the teams need to identify and plan.
Each team will also determine their velocity, either using historical data or a best practices baseline. Their velocity indicates how much work they can plan per sprint, or how ‘fast’ they can go. This is used to not only plan the sprints, but also to help determine an accurate estimate of how many features can be delivered in the 13-week timebox.
At the end of the PI Event, the organization will have a visual plan of all of the work required to deliver the prioritized features. The plan is represented on a Program Board, that clearly shows all of the teams (internal and external), dependencies, milestones, releases, risks, and more. It is a holistic snapshot of how teams need to work together to deliver maximum value throughout the 13 weeks. The plan is not a prescription, but rather a visual understanding of the systemic impacts when things shift and pivot during execution (ex: if X slips by a sprint, here is what will change at all parts of the system).
The goal is to complete the planned work within the 13-week timebox. Unfortunately, sometimes things happen and carryover of work is required. This is especially true for newly formed teams; the more mature the team, the better data and experience they have to build more accurate and confidence-producing plans. If carryover occurs, communication between the Scaled Agile ‘layers’ is important.
In a Scaled Agile environment, there are concurrent timelines at various levels of the organization to help prepare for PI Events and align ongoing delivery. The Team (pod) resources are actively sprinting and executing the plan from the previous PI Event. At the same time, the Program resources are working to validate the next set of epics to break down into features. The goal is for Program features to be identified, defined and sequenced just prior to the next PI Event. When/if the team resources become aware of carryover, they will communicate back to the Program resources for that work to be included in the next set of features for consideration. The carryover work is communicated from the team-level Product Owner back to the Program level Product Manager for planning. Carryover work is added into the list of features to be sequenced and planned for the next, upcoming PI Event.
Moreover, the Portfolio layer is responsible for owning the organization’s strategic roadmap, working at least two quarters ahead to identify and define the epics needed to execute the roadmap. Those epics are validated at the Program level, and broken down into features. The features are confirmed by the team, and broken down into executable stories for delivery.
These three timelines run concurrently, and continually repeat. SAFe provides a communication model and development processes to ensure ongoing and open communication between the various SAFe layers at all times.
This is where the magic of the PI Event can help! While Bottle Rocket may lean into SAFe, it is not expected that our clients or vendors also run SAFe. Rather, we can use the 2-day PI Planning Event as a recurring time to align, plan and set expectations. The ways of working that clients and vendors use to deliver matters less than their ability to communicate and meet the timelines and goals in the PI Event plan. SAFe builds in recurring integrations and touchpoints with all parties, to allow for frequent communication, adapting, and delivering. And full disclosure, once our clients see the success of running SAFe, many have started to transform their own organizations to use the framework as well!
Scaled Agile is always iterating and improving the framework. Real world feedback is received and incorporated on a regular basis, and new versions are released. As our world continues to evolve and grow, so will the Scaled Agile Framework (SAFe).