The ART of Awesome PI Planning

Get in Touch

Em Campbell-Pretty September 24, 2014

Category:

“100 people in a planning meeting sounds like a contradiction in terms.” That was not exactly the supportive sentiment I was hoping to get from my parents. It was the weekend before PI Planning, and I was trying to explain to my parents what we were attempting to do over dinner.

Having freshly returned from Jean Tabaka's Scaling Agile Collaboration Workshop, I was VERY focused on planning for the big day. Jean had said you should allow 2 hours of preparation for every hour of workshop and up to 5 times this for large planning meetings. Did she mean me personally as the facilitator or everyone involved? Had we done enough? Had I done enough? All was about to be revealed.

It was not the best start to the day as I rocked up 15 minutes late to my 7 am pre-meeting with the Release Train Engineer (RTE) to find her still working on slides for the morning session. (Not that I could judge, as I quickly dropped a handful of planning instruction slides into the back of the presentation.)

Last-minute changes were still arriving by text message from the CIO, including a change to the run order. “No!” said a loud voice in my head. The day hasn’t even started, and my run sheet is already redundant. Well, I guess that could be seen as a slight overreaction, but I was 0-2 at this point, and I was starting to get concerned.

By 8 am, I was calm again. The room had been set up the afternoon before. The planning board, the feature kanban and the agenda were all up on the walls. The team tables were decorated with team avatars representing each of the newly formed teams.

The RTE had chosen superhero groups as the theme for her Agile Release Train. As is always the case with these things, the teams had taken a few liberties when choosing names - Los Pollos Hermanos, Fringe Division, The Matrix, Master Builders and the Justice League. Each table has a supply of Post-its, index cards, sharpies, blu tack and planning poker cards. As I added the final touch to each table (anti-stress scrum balls), the CIO entered and kicked a scrum ball the length of the room. Something tells me it is going to be a good day.

PI-Planning-Feature — PI Planning Feature Kanban

As participants slowly begin to arrive, the CIO quite rightly points out that some music is in order. He then quickly whips out his iPhone and plays “Everything is Awesome”. I play DJ for a little while while the last-minute audiovisual adjustments are being made.

The CIO opens the event at 9:05 with an inspirational speech that sets the perfect tone for the day, reminding everyone that this first Agile Release Train forms a part of the broader IT strategy to: “Maximise Values, Minimise Time, Eliminate Waste and Engage the Team.” He was followed by the RTE, who set the context for PI Planning and introduced the teams. I was next with a quick run-through of the agenda before introducing the business sponsor, who set the business context and shared her vision for the future of her line of business.

From there, the morning continued with a series of short, sharp feature overviews provided by the business. Then, it was time for the architecture briefing. Unfortunately, the System Architect was at home sick, so using the magic of Google Hangouts, he presented from home.

This turned out to be a pointed reminder of the value of in-person communication. The poor architect, on the other end of a computer screen, was unable to read the room, and the audience was trapped listening to a 45-minute version of what was supposed to be a 15-minute architecture briefing. (At least we learnt from the experience, as banning remote presentations was one of the first decisions made when the team started preparing for the PI 2 planning event.)

With the room a little flat, we were keen to inject some energy before the teams started planning. My colleague had spent the morning offstage and had cooked up a plan—a whole train version of the ballpoint game. While the idea has potential, I think it might need a little more refinement! However, fun, energy, and much laughter had been injected back into the room, and we broke for lunch.

After lunch, it was time for the teams to get planning. It was not long before I realised just how underprepared we were. From what I hear, this is true of almost all trains at their first PI Planning event. It wouldn’t be until well after the two days had been and gone that I would get some perspective and remember that it was me, all those months ago, that suggested we needed to stop trying to predict how the train would work and instead learn by doing. As a learning experience for an Agile Release Train, the 2-day PI Planning event is invaluable.

Don’t confuse our under-preparedness with a lack of preparation. In the eight weeks leading up to the event, there was an extraordinary amount of preparation activity, in parallel with delivering on in-flight project commitments. Squads (aka agile teams) were formed, features were cut, the ART backlog was created and prioritised using WSJF, everyone was trained, briefings were prepared, and the logistics for a two-day, 100-person PI Planning workshop were put in place. In many ways, everything that could reasonably be done had been done.

During the first afternoon of PI Planning, many missed opportunities became obvious. Some of them had been foreseen but not actioned; others took us more by surprise. In no particular order it became clear that it would have been preferable for:

the teams to have had time to form as teams before the event
both team members and business stakeholders should have had more input into the process of breaking down epics into features
the Scrum Masters to have had more facilitation tools in their kit bag

On the other hand, the energy was incredible. Like what I experienced with the PI-lite approach we took with the EDW Release Train, but somehow different. I suspect this difference was the inclusion of the business folk. Watching the teams collaborate with their business stakeholders, many of them for the first time, was magical. The draft plan walkthrough at the end of day one showed that all teams had made good progress, but we were probably slightly behind where we wanted to be. It was time for the teams to head home and the leadership team to reflect on the day and make some priority calls to inform the next day's activity.

After a short health break, the leadership team, made up of both business and IT folks, reconvened for the Management Review & Problem Solving session. The first order of business was to get everyone’s thoughts out into the open. It was time for Post-its, sharpies and silent writing. The topic was “What did we learn?” and the response from the leadership team was overwhelmingly positive. The value of the collaborative conversations enabled by the day was obvious to everyone. As you would expect, there were also a number of items that needed to be actioned either the next day or over the coming days.

The final part of the management review was a conversation about feature priorities. The discussion was rich, and the leadership team's willingness to make compromises was the stuff of true servant leadership. It was 8 p.m., and we had a set of positive messages to deliver to the team. It was time to head home for a well-earned rest.

Day two of PI Planning kicked off with a little more “Everything is Awesome” and a few words of encouragement from the CIO before getting on with the planning effort. We took a bit of a gamble and gave the teams all morning to plan, not just the 2 hours suggested by the standard SAFe agenda. Five teams new to agile, trying to plan a 12-week PI in two days was quite an ask, and we wanted to give them every chance to succeed.

By the final plan review, most teams had a pretty solid plan for at least the first few iterations. It was time to R.O.A.M. the program-level risks. As the teams had read through their plans, they had surfaced risks that were outside their control. The RTE had been collecting these, and it was time to get them all Resolved, Owned, Accepted or Mitigated. Talk about a leadership opportunity!

As I read out each item, I watched the CIO, the business sponsor and other senior leaders take ownership of various risks on behalf of the teams. It was lean leadership in action. With the risks ROAMed, I asked the CIO and business sponsor to accept the risk profile for the PI, and we captured a photo of the two of them in front of the risk board.

Next up, it was time for the moment of truth - a walkthrough of the program board followed by the confidence vote. Having played back the integrated plan to the group, I asked each team, in turn, to provide a confidence vote for the plan, using a “Fist of Five” where:

5 = Very high confidence; will happen
4 = High confidence; should happen
3 = Good confidence; the team should be able to meet the objectives
2 = Little confidence; probably will not happen
1 = No confidence; will not happen

The first three teams all responded with a nice mix of 3s, 4s and 5s. By this point, I was feeling pretty good about the outcome. The fourth team thought it would be funny to all vote 1 and see my reaction. I am reliably informed I went white as a sheet before they quickly changed their votes to 5s, much to my relief. The fifth team also returned votes in the 3 to 5 range, providing a full sweep. Now for the finishing touch - would the Business Owners accept the plan? A photo of the CIO and business sponsor shaking hands in front of the program board sealed the deal.

To wrap up PI Planning in a true agile fashion, it was time to retrospect. Each table was asked to do a simple star-style retrospective - stop/start/do more/do less/keep. Again, the feedback was overwhelmingly positive, with improvement suggestions focussing on “stop playing the awesome song” and “time box the architects”. For me, a highlight was watching the business people go and sit with the teams they had been working with rather than returning to the business group tables at the back of the room. That’s when I knew we had started a change journey that had the potential to go beyond the delivery of software to change the organisational culture.