- SAFe Training
- Choose a Course
- Public Training Schedule
- SAFe Certifications
- Leading SAFe
- Implementing SAFe
- Advanced SAFe Practice Consultant
- Leading SAFe for Government
- SAFe Lean Portfolio Management
- SAFe Release Train Engineer
- SAFe for Hardware
- SAFe for Architects
- Agile Product Management
- SAFe Scrum Master
- Advanced Scrum Master
- SAFe DevOps
- SAFe Product Owner/Product Manager
- SAFe Agile Software Engineering
- SAFe for Teams
- SAFe Micro-credentials
- Agile HR Training
Can You Be SAFe Without PI Planning?
The concept of a Program Increment (PI), is generally considered the corner stone of cadence in SAFe. In simple terms, SAFe recommends that a PI consists of between 4 and 6 two-week sprints including a IP sprint (Innovation & Planning.) and each PI commences with a two day "all hands" PI planning event during which a high level delivery plan is produced for the PI. As readers of this blog would already be aware, when we launched our first release train, we did not have enough funded development work in the pipeline to justify a full blown release planning event, so we invented Unity Day.
Given we could not use the PI cadence initially we adopted a rolling wave planning approach. Late last year demand started to exceed supply for the first time in the brief history of the EDW Release Train. Our first response was to add an additional team to our Release Train. When a couple of months later we found we were still feeling severely capacity constrained, the concept of implementing PI Planning as per textbook SAFe became a regular topic of conversation at our leadership team lean coffee.
We had shied away from adopting PIs in our first 18 months as a Release Train. In the early days when demand was at its lowest the majority of our projects / epics were simply responding to changes in front of house or billing that had consequential impacts to the Enterprise Data Warehouse (EDW). The priorities of the projects were set at an enterprise level and our ability to make our stakeholders commit to even an eight week plan seemed unrealistic.
With demand spiralling out of control we needed to take action, so we decided to experiment. We would run a one day "all hands" PI Planning event. As we had done a year earlier, my leadership team sat down with copies of Dean Leffingwell's Agile Software Requirements opened up to the section on PI planning and started to adapt it to our needs. We landed on the following one day agenda:
9am Unity Hour
10am Feature Team Planning
12pm Lunch
1pm Technical Alignement Huddle
1:30pm ROAM
2:30pm Dependency Alignment Huddle
3:30pm Re-unification
4:45pm Commitment
As our first PI planning day drew closer, we found ourselves short on time. What should we do? Postpone? "No", I say, channelling Artful Making, "The show must open on opening night!". We had waned to understand priorities at the feature level but had to settle for epic level prioritisation. We struggled to get participation from our business stakeholders and those who had agreed to attend dropped out at the last minute. Despite some things not going according to plan we stuck to our time box and held firm to our committed date. After all, the show must go on!
We were still working out the logistics at 9:10am on the day. Rolling with the punches we quickly brought the room to order and commenced our first PI Planning Day. Unity Hour was brief, we used the time to talk about the day ahead and the prioritised program of work, making sure to include our traditional "shout outs". Given our concerns about capacity constraints, the amount of WIP and the constant context switching it was driving, the theme of the day was "Stop Starting and Start Finishing".
Our six feature teams co-located for the morning planning session in a large meeting room. The energy from the group was nothing short of amazing. Just writing about it brings the memory of that buzz to the forefront of my mind and I find I am smiling to myself. The goal of the morning was to produce a high level plan, lower than feature level but less granular than user story for the next 4-5 iterations. For the most part this was achieved without too much pain.
After lunch we kicked off the technical review of the plan. Given all our feature teams are delivering capability from a single integrated physical data model, we were keen to understand if there would be any overlaps or collisions between the teams during the course of the PI. It was during this session that I realised that the published agenda for the day was not the agenda we had written up on the whiteboard. It was clear that context was missing from the conversation, as we had accidentally left out the the reunification step originally scheduled to occur after lunch.
I gathered my leadership team for a quick discussion. What should we do? Continue with the published agenda? Revert to the original plan? While there wasn't enough time left in the day to revert to the original plan, it was clear the team was struggling. Then I remembered, "A good facilitator knows when to vary from the plan. Follow your nose." So we landed on making reunification our next session, accepting that we would probably have to forgo the reminder of the day's agenda.
I went back to where the teams were gathered and explained the scheduling mistake that had been made and apologised. I shared with the team the proposal that we adjust the agenda to compensate then asked them how they wanted to proceed. They agreed context was missing, so we broke for 15-20 minutes, while the feature teams were informed that that we would be bringing forward the all hands reunification session.
With the full release train present, each of the feature teams and the system team shared their goals, plans, risks and most importantly dependencies. Feedback from most parties indicated that this was the most valuable part of the day. It certainly stuck a chord with me, given the importance I place on the value of shared understanding in building teams. And as promised, this ended up being the last session of our first PI Planning.
My leadership team used the last hour of the day to reflect on the experience and consider the way forward.
What worked well?
- Shared understanding across the group on the in flight and upcoming program of work
- Plans focused on finishing rather than starting
- Identification of cross team dependencies
- The energy and sense of camaraderie in the room and during the day
- The show opened on opening night!
What needs improvement?
- Planning!
- Air conditioning!
- Business participation!
- Planning at the right level of granularity
While the PI planning day had delivered unquestionable value in providing shared understanding and greater visibility of dependencies, most of the team indicated that their plans had not materially changed as a result of the day. (Although the focus on plans that limited WIP had helped.) Some of us also felt that a move from rolling wave planning towards PSI planning represented a move towards larger batch sizes and would be a step back in our mission to achieve flow. After some discussion we decided to hedge our bets; we would work on improving our rolling wave planning approach and monitor our progress over the next four iterations, before making a decision to hold another PI Planning day.
With the learnings from the PI planning day fresh in our minds it was time to think about how we could make our rolling wave planning more robust and sustainable. The key change we made was to add back the reunification at the end of the day. (This is something we had done previously but had been dropped over time). At reunification each team provides their sprint goals for the new sprint, advises of updates to their rolling four iteration plan and calls out dependencies and risks to the plan.
We have been using our revised rolling wave planning approach for about six iterations now. We had a check point with team late last year and decided to proceed with this approach for now, as opposed to adopting the practise of PIs. For us, right now, this practice is working and is still aligned with the SAFe principle of synchronisation and cadence. I don't know if our position will change in the future and I don't know if this practice makes sense for other Agile Release Trains.
In our enterprise context we are driven by alignment to upstream dependencies, not by putting stakeholders together in a room to make tradeoff decisions. Without that value-add, the PI construct doesn't help us. But do I regret holding it? No, it was a great and we learnt a lot. Admittedly most of what we learnt was how to improve our rolling wave planning to avoid the need for the PI days - and that learning has shown benefits already!
Order on Amazon Now!
Get the book from Amazon now!
Categories
Popular Posts
