3

As a Scrum Master for two teams within SAFe, I have the standard scheduling down pat. I can attend all regular meetings and the teams are running relatively smoothly. However, we are working in a scaled agile environment and there is one event that regularly makes me want to clone myself: PI Planning.

In other words, the event when all Scrum teams that are developing a huge project physically come together to adjust their planning for the next two months. This includes a retrospective and a planning session. While the planning is doable (larger time window and lots of preparation), leading two teams through a common retrospective within the same time slot of thirty to sixty minutes is a challenge. Yes, the questions are the same for all 100+ participants, but we as Scrum Masters are supposed to lead and encourage our team, make sure the time limits are kept etc.

In the past, I solved this by placing both teams physically next to each other, but found that the discussions of the two teams mutually distracted them and that I was running around like the proverbial "chicken with its head cut off."

As the rule of thumb seems to be "Scrum Master = 1/2 full-time job", I suppose there are many SMs out there with similar issues.

How can one person juggle two teams when sequential work is impossible?

  • Are both teams having retro together? If not, is it necessary to do the retro at the same time? – ppasler May 10 '17 at 10:41
  • @ppasler - All teams are doing a retro together about the last program increment, every team works within the team and then the results are presented to the general audience. I can't do two retros, because I'm not asking the questions. I will however have both teams thinking about the general "what went well, what went wrong, what are we going to do better" beforehand, hoping that they need less guidance at the actual event. – Stephie May 10 '17 at 10:46
  • I see, this some kind of scrum of scrums retro, have a look at this: scrumalliance.org/community/articles/2016/february/… I have no experience myself, but this quite makes sense to me. – ppasler May 10 '17 at 10:57
  • 1
    50-person teams doesn't sound very agile, even within SAFe. It also sounds like your PI Planning isn't long enough (the recommendation is 1.5-2 days), doing enough breakouts, or leveraging the role of ART Engineer. scaledagileframework.com/pi-planning – Todd A. Jacobs May 10 '17 at 22:18
  • @CodeGnome not my teams, all participants in the agile release train. I'm working with about a dozen developers. And I agree, 50 per team sounds strange. Our PI Planning is ca. 2 days, which I can juggle just fine - I typically have even time to support my RTE. It's just the retro that makes me dizzy. – Stephie May 11 '17 at 14:48
2

TL;DR

I'm not a huge fan of SAFe, so you may prefer an answer from someone who is. With that caveat out of the way, I believe the foundational error is that your ART Engineer is conflating the Iteration Retrospective (which should be a separate event) with the PI Planning event. Teams should not be doing iteration retrospectives within PI Planning at all.

The only retrospective defined within PI Planning is the Planning Retrospective, which is run by the Value Stream Engineer, not the Scrum Master. Your problem can therefore be resolved by adhering to the framework as defined, rather than rolling additional retrospectives into the wrong event.

PI Planning Shouldn't Include an Iteration Retrospective

PI Planning is similar in intent (if not practice) to Scrum's Sprint Planning meeting. It has a defined agenda, as pictured below.

Standard PI Planning Agenda

However, note that the retrospective defined in the agenda is a planning retrospective, not an Iteration Retrospective. There's no Iteration Retrospective in PI Planning at all!

PI Planning Retrospective: The "PI Planning" Definition

According to the framework, the Planning Retrospective is described under PI Planning as follows (emphasis mine):

Planning Retrospective and Moving Forward. Finally, the RTE leads a brief meeting retrospective to capture what went well, what didn’t, and what can be done better next time. Following this, next steps are discussed, including capturing objectives and stories in the Agile project management tools, scheduling upcoming key activities and events … and cleaning up the room!

What isn't made as clear as it should be is that this retrospective is to reflect on the PI Planning event, not on the iteration. As such, it's not a breakout session or a set of concurrent meetings, and doesn't have to be run the same way as an Iteration Retrospective.

PI Planning Retrospective: The "Post-PI Planning" Definition

However, the framework does offer a slightly better definition that is under Pre- and Post-PI Planning. The agenda items are given separate context within Post-PI Planning, which helps to clarify the purpose of the agenda items listed.

Post-PI Planning Agenda

Furthermore, the definition of the agenda item here uses the same section heading for the agenda item but also describes who owns the agenda item as the Value Stream Engineer (VSE):

Planning Retrospective and Moving Forward. Finally, the Value Stream Engineer leads a brief meeting retrospective to capture what went well, what didn’t, and what could be done better next time. Following this, next steps are discussed, including capturing objectives, use of project management tooling, and finalizing the schedule of upcoming key activities and events.

Because it provides both context and an owner for the agenda item, this description seems much more clear. However, please note that it also differs from the other definition by giving this job to the Value Stream Engineer (VSE) rather than the Release Train Engineer (RTE). In either case, the agenda item owner is not the Scrum Master, and you are therefore not the one who has to manage the retrospective or juggle the participants.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.