Taking Part In My First SAFe PI Planning Session
It’s a new financial year for the project I’m working on and the client’s leadership wanted to be ‘more Agile’ by co-locating all the development cells in a hotel for two days and have a planning session for the next quarter’s worth of deliverables (adhering to an annual plan).
I’ve never been part of a scaled agile process before, having mostly worked in smaller teams and on smaller projects so this trip was going to be my first experience of this type of planning.
The SAFe Product Increment (PI) Planning session involves setting business context for the increments and then having the team plan and commit to work that will realise those increments but done as one big planning session so teams can freely communicate face-to-face when they need to discuss dependencies.
Prologue
The financial year just gone was a transition period for the client, having changed development partners to the company I work for in late 2019.
In March 2019 they sat down with the previous development company and set out their annual plan, based estimates on teams with over 10 year experience working on the product and then later that year they expected teams with no experience to deliver those same increments to the same timescales.
For the most part my team managed to deliver a number of key deliverables but they were hardly ever on time and we ultimately failed to deliver the last increment.
This isn’t a bad thing though. The team communicated the issues it faced, priority changes that impeded our progress and the client was more focused on helping us than punishing us for not meeting deadlines.
I was looking forward to the big planning session as having all the relevant parties in the room would allow us to communicate to everyone the potential issues we’d face, the workload and the slack in the plan we’d be adding to allow for ad-hoc work.
Most importantly though I was looking forward to spending time getting to know the client side team members, preferably over a pint or six.
The planning session was split into two days, the first day about setting business context and the second being the main planning activity.
The Planning Session — Day One
The first day was a long one, not due to the content of the meeting but the fact I was up at 03:30 in the morning to catch a flight down to the client’s site.
When we arrived at the hotel we had an hour to grab some breakfast before the main event started.
The client’s management team then spent the next 4 hours presenting what was achieved the previous year and the changes being made to the teams in order to facilitate the deliveries for the coming year.
These presentations pretty much re-treaded the same information we’d seen over the last month so there wasn’t anything new for the people from the company I work for but for the client’s staff this was all new information (more on that later).
As you can imagine, being up since way-too-early o’clock and listening to information we already knew meant I was ready to sleep by midday and I struggled to resist crawling into my hotel bed when check-in was available after lunch.
In order to ‘refresh’ everyone there was then a mandatory ‘well being’ exercise that involved making a collage of the client’s logo out of tiles we were given to colour in.
Looking at the SAFe PI Planning page it looks like this exercise replaced the ‘Team Breakout’ session which I think would have given us a lot more value than the well being session due to the client’s staff only just learning about what was expected of the team in the coming quarter.
We finished the day with a meal and most importantly for me, drinking loads of beer and jägerbulls (in order to stay awake) and getting to know everyone. I ended up winning the ‘human bingo’ game that was set up having filled out my card with the names of people who met the criteria on it.
The Planning Session — Day Two
The second day started well with a nice hearty breakfast and swapping tales of what stupid stuff we got up to the previous evening.
We then bundled into the same room as the previous day which had been transformed so that plastic sheets covered all the walls so we could use them for planning.
The management team then gave an intro to how they saw the session running and what the output was going to be (six sprints planned) and told everyone to ‘embrace the chaos’, little did I know how chaotic things would be.
I’ve broken down the planning session into four stages that we went through as the day progressed to try and give some order to that ‘chaos’.
Top Down Planning
Unlike the suggested SAFe PI Planning method where there’s a less strict plan from the business and more a set of intents from a backlog with teams to pull work from our team instead had a lovely Gantt chart with key delivery priorities on it.
Quarter one had five priorities on it with only two of those being delivered that quarter, the session was feeling more like a plate juggling exercise than a planning session.
There was a lot of similar functionality that could have been grouped together to decrease context switching in the team, but due to the scheduled delivery dates and the team not being given enough time to understand the plan there was a lot of people panicking and not taking a step back and thinking about things logically.
Deadline Induced Panic
The biggest cause of panic came about thanks to the first deliverable being due for the end of the next month.
This deliverable was something we were already working on but due to a lack of knowledge from the team and the 3rd party vendor we were working with we had to go back to the drawing board and at the time of the planning session there three potential solutions on how to implement the functionality.
The lack of clarity on the approach meant some of the team members were attempting to build three separate sprint plans but myself and my BA colleague nipped that in the bud by focusing them on mapping out the actual behaviour changes to the system and not the tasks needed to do to complete the work.
Taking Shape
Finally we had the first big deliverable mapped out with a list of unknowns we wanted to investigate and it was then my task to run around the room with our dependency notes having conversations with the other teams to map those on their boards.
We then looked at the second deliverable which was similar functionality to the first but for a separate market and using a separate 3rd party vendor, but as we had the management team to hand we were able to discuss another implementation option that would align us with some future work that wouldn’t happen until the next financial year.
This discussion unlocked a lot of potential for the team to not only deliver on the planned functionality for the year but also allow the client to reap the benefits of a change they wanted to make a full year ahead of schedule.
There were a few dependencies on contracts being signed that meant we couldn’t commit to that approach completely but it meant our sprint plan had the ability to show how ‘Agile’ we could really be.
The Final Plan
After what felt like hours on my feet (I’ve not done that much standing since I worked in a pub 10 years ago!) we had finally pulled together a rough plan of how we were going to:
- Use spikes to investigate the implementation of the 3rd party vendor solutions we’d rely on to complete the deliverables in the quarter
- Break the development work into small independent stories that meant we could deliver the functionality quickly and as everything was behind a feature flag we’d be able to do this without impacting other teams
- We’d be doing 80% feature work and 20% improvements (tech debt, bug fixes)
- We added slack into the sprints that coincided with the client’s monthly UAT cycle, as this normally reduced our velocity due to the team picking up urgent bug fixes (annoyingly not caused by the work we did but by other teams!)
The plan seemed to go down well and we were the only team that accounted for the UAT cycle which I hope meant our plan came across as being more realistic.
Going Home
So after the session wrapped up we legged it to the Airport to catch our flight back home but this almost didn’t happen.
The trip was during the start of the coronavirus pandemic reaching the UK and the airline we were flying with, which was already basically in administration, ended up going into administration the morning of the second day (which they blamed on coronavirus hurting their sales).
So we got to the Airport not knowing if we’d have our flight cancelled but luckily for us the company that made that route was actually using the airline that went under for bookings so we were OK and better still the flight back was a jet engine instead of the usual propeller plane so it was shorter.
Benefits of SAFe PI Planning
The main benefit I got from the planning session was being able to bring the right people into the conversations when we needed them and also being able to map dependencies across teams.
It was also good to just get the entire team together and discuss the features we’re looking to build (something that hadn’t really happened previously) and it was especially interesting to me to see the team dynamics in play.
This is mostly interesting to me as on the client side we have two people in a delivery manager / subject matter expert role and it was great to see how they handled that dynamic (turns out one person just did all the talking).
While I’m sure it will change as we actually do the work it was also beneficial to have the next six sprints planned so we could at least see what we’d need to focus on and had an artefact to barter with when it comes to resourcing.
Downsides of SAFe PI Planning
The majority of the downsides for me are specific to the approach that the client took, but one that I’d imagine affects more people would be the sheer amount of noise that a room full of 80 people generates.
There were times where I had to shout (I tend to talk loudly naturally) and we also had to stop people having smaller conversations within the team in order for ideas not to get lost and to keep the team focused.
The biggest downside for me (although this is specific to this session) was the fact that the client side team members hadn’t seen any of the items on the plan or the resourcing plan until the day before we made the trip down and I was sworn to silence until the client’s management team sent that information out.
In my company this information was shared ahead of schedule so we had a pretty good idea of what we were going to be working but as we’re just the development side of the equation and we couldn’t talk openly about the work it meant that all the questions that we had couldn’t be answered until the planning session.
This paired with the top down approach to the annual plan and the fact that the Product Owner (PO) wasn’t able to attend due to breaking their leg a few weeks earlier meant we were very much having to build a shared understanding of the work when we should have been focusing on planning how we’d deliver it.
And as the PO wasn’t about we didn’t have someone to make the decisions we needed to help focus and steer the conversation.
What I’d Improve
The next time we do the SAFe PI Planning session I think I’d ask a smaller set of the team to attend.
We had 12 people around the board at one point and it’s just incredibly hard to maintain focus when a group is that large, people can’t hear properly, smaller conversations break off and others just stand around bored.
If the session was more of a three amigos setup with representation from product owner, delivery manager, test, development and business analyst the conversation would be more focused and as there’s less people in each team the room would also be quieter.
As mentioned before the top down approach and lack of prior communications meant that we lost a lot of time discussing what functionality we were building when ideally we’d have a pretty solid idea of that before going into the session.
If we had that functionality defined to a good level that would have also allowed us to discuss moving deadlines around to increase the value the team delivered while reducing context switching but as the plan was pretty much locked in I’m not sure how far that would have gone anyways.
Would I do it again?
As that was quarter one being planned I’ll have to regardless of if I want to or not but I do feel like the next session will go easier, not just as it’s the second time round but also because the annual plan will have been in play for three months and we’ll have a good idea of how it’s playing out.
Of course, it being the first session it’s not like it was going to be perfect the first time!
I look forward to the next session as I want to float the idea with the management team of them building a portfolio of backlog items for the team to pull in and making the plan a little less rigid.
If by delivering three items at once (thanks to the magic of re-usable code and modularisation) we can get ahead of the curve then I can start asking them what the next annual plan looks like and ultimately make them think about how having that backlog can help the team deliver more value.
