Within the SAFe framework, the Program Increment planning is THE ceremony to get everything started. But how do you survive it as a Scrum master, especially if you’re not experienced in practical terms and you have challenges at a team level?
My company runs Scaled Agile using the SAFe Framework, and in consequence I have become certified as a SAFe Agilist. But just like getting a Scrum master certification doesn’t effectively make you one (the attitude, the experience, the soft skills come much later with patience and resilience), nothing could prepare me for my first PI. This is effectively the main reason I haven’t written a blog post in a while; because it’s been a raging storm that has swallowed me completely, and only now I begin to tame it.
Don’t get me wrong: the PI was great for lots of reasons, being the first one the experience itself (will hopefully become routine) and also because I am still a newbie within my company and I don’t know well the faces, the relationships, the teams and the different dependencies. And that is all the PI is about, really.
School rules are simple: the PI planning is a ceremony where everyone meets in a sort-of super sprint planning (oversimplifying) that takes two whole days and where the output is a set of commitments for all Scrum teams for the next five sprints (leaving a 6th empty for innovation or adjustments). Effectively, a quarterly planning mapping all the connections between these teams, a predictable output with a big increment, also known as Art (Agile release train).
The primary outcome of a PI planning is the Program board, or all the features committed by every team for each one of the planned sprints, plus the different dependencies between those teams and the observed risks. The first two sprints should be fully defined, and all teams should have the same sprint cadence, aligned in time, with their individual capacity into consideration. Sounds good and easy, right?
Wrong. Many things can go downhill and effectively they do, but the lessons learnt from them are pure gold. Let me explain myself by showing the proposed agenda of those two days:
Now, let’s talk about what really happened to me, always from the perspective of a Scrum master (I know this is perceived differently by other members such as developers, product owners or stakeholders), and from a very specific scenario: a big team (with experience in Scrum), inexperienced in this specific ceremony, and being also the very first PI for many of the attendees.
The first day
Product / Solution vision and Architecture: This first time we did need more time and context. It was essential to discuss architecture and present an overview, but the deep detail should have been discussed during the breakouts, not before, yet it is important to remark some guidelines on the common principles. I enjoyed thoroughly hearing the product owners talking about the proposed features, and I believe the rest of the attendees as well. It was a first-timer for many developers (and myself) hearing other product owners and people from other areas of the business. Their perspective and proposals were fresh, and made us all feel part of something big and beautiful. We removed the silos here.
Team breakouts (part 1): Here is where a sort-of chaos begun. The team was moved to a separate room where we simply didn’t fit. As the only Scrum master for this big team (but with lots of capable brains within the team to help me out), I was unable to facilitate everyone’s needs on my own. It was just not physically possible. Sooner than later, luckily, the team decided to separate in smaller sub-teams and spread through the office where they could have the necessary space to come up with a plan of refinement. The initial chaos began somehow to flow smoothly, but by the time it began to take a certain shape, I had to attend my first Scrum of Scrums. I could not add much to it, unfortunately. By the time we had the second one I had more information to provide, but I wasn’t 100% sure I had all the information as I was trying to supervise four different workstreams. At the end of the session, the team had sort-of defined stories within each sprint, but not a clear view of definitions, points, dependencies and risks.
Draft plan review: By this point, we should all have had a rough idea on what to commit to in terms of backlog items, commitment dates and hard deliveries, dependencies, impediments and risks. In our specific case, we were not even halfway there. We managed to catch-up quickly the following day. At this stage, we were far from an ideal situation and, honestly, with quite a confused and weary team (including myself). Of course, when I had to explain the plans for all the different workstreams, I ended up needing help from some of the people who attended the breakouts 100% of their time. This exposed the team and my own capability to explain the scope of the work that had to be completed. Not necessarily a bad thing as it’s a good way to identify problems towards improving the PI planning, but it was extremely stressing and not as efficient as it should have been.
The second day
Planning adjustments: Just an overview of where we left the previous day and the outstanding work to do. Good to get the ball rolling.
Team planning breakouts (part 2): by the end of this session, we managed to reach the point where we should have been the previous day breakout. Again, we faced multiple workstreams with only me being the Scrum master for everyone. This affected dramatically my up-to-date knowledge about the work to be completed, and it was reflected in the final plan review. Nevertheless, we were happy with the result considering where we were the previous day. We managed to pull a decent board with sprints and capacity, but this was done in a hasty and inefficient way, especially if we had prepared the boards and the workstreams more efficiently for refinement. But not all hope is lost, as I believe this bit will improve dramatically next time.
Final plan review: This was a déjà vu of the previous day: I struggled with explaining the different workstreams (this time I did a bit better thanks to a more comprehensive board and better focus, but far from ideal), especially when comparing with teams that had a single workstream. Lots of support here (and a great teamwork exercise), but again very stressing. All dependencies should have been placed properly in the Program board and all the risks in the right place.
Assign business value & Program board: This is part of the final part review, and it was not done in an ideal way; we needed extra time to complete it. If we had completed the PI objectives bit during the team breakouts, we would’ve been able to do this at the same pace as other teams did. The product owner must be aware of this way in advance.
Vote of confidence: It was a really nice exercise and reflected reality from a really human perspective. Some people didn’t see the point of it. I personally did, but it’s true that we could have logged this more effectively.
Plan rework: We did not do any (and maybe we should have, but we were really exhausted by this point).
Planning retrospective: I think that after the long two days we could not run a regular retrospective. The feedback provided, though, was equally positive and constructively negative, so it was really great. I would make sure next time hosts the feedback is provided at all times, not just by the end. Not because there’s no need for a retrospective (it is always essential), but because by the end of the second day, people were quite tired.
I could write about many more things (missing stretch objectives, owning risks, etc) and I will keep doing it, since SAFe and its execution are worth several chapters, but for now I will just summarise a few takeaways and raw impressions:
Points to improve / have into account
- All features and scope for each workstream should be fully decided and agreed prior to the PI. No room for improvement here.
- We need everyone together in the same physical space, split in well-defined workstreams from the very start.
- Physical boards for all sprints and workstreams must be ready up-front with the corresponding capacity in each of them.
- One Scrum master for each workstream. I was unable to spend 100% of my time with just one of the sub-teams, but dividing my time between the different ones, and that impacted my knowledge about the output of the breakouts. My knowledgeability would have been far, far better if I had just been working with one or two teams.
- Use the right colours for the cards within the boards and provide points and the right format to all of them. Translating these cards later on into a digital version was incredibly complicated and confusing. This might sounds not important at all, but believe me when I say it is.
- Review all boards and check the teams capacity and whether we need to swap/create/delete any of the stories / dependencies/risks.
- Have all the PI objectives written properly in a SMART way.
- The end of the sessions outcome should always be: one board per sprint per workstream, with all stories (or at least, all features), spikes, dependencies and risks written in the right colour and the right format.
- The exercise itself was beyond fantastic. We managed to have a lot of people committed to the goal of having the PI defined, with lots of support and comprehension (all this from the human perspective, not just the professional). Everyone were in the room for the whole two days and the atmosphere and energy were overwhelmingly good.
- The potential of the PI once refined in the upcoming iterations is immense.
- The PI planning exposed the weaknesses of the Scrum teams: size, estimation, capacity, knowledgeability, communication and transparency. Sounds ominous but I believe this was a great eye-opener.
- Good output of the session.
- The Program board is an excellent tool to track the progress of the Art, although difficult to update.
We are now approaching the middle of the PI commitments and, as expected, plans change (basic Agile rule). Going through these changes is another different exercise, and incredibly complex in this specific case, but the good news is: seems like we will definitely improve for the next PI. And it’s not only being a good way to set new ways of tracking and communicating, but also boosting the human side of our work by forcing us to be in touch with all the different departments and check the dependencies in a scheduled, organised way.
The pros and cons of SAFe against LeSS or DAD is another matter; I will speak about them when I absorb my knowledge and I know more about them all. But for now I just feel privileged and honoured, despite the challenges, of being part of this PI. Because there’s nothing more beautiful in life than learning.
IMPORTANT: I have every intention on writing another post about this in a year from now. It will be interesting to see my own contradictions on how I see the PI process after I’ve been through a few of them.