Scaling Retrospectives

The Plea
Retrospectives are near and dear to my heart. I love facilitating them to this day and tend to try something new quite often. I have found it to be a fertile ground for learning facilitation techniques.  Today I will discuss scaling retrospectives. While the scaling discussion is receiving a great deal of press in the agile world these days, we have overlooked the retrospective area in my opinion. Time for a change:

The Setup
Consider the following two intents:
The intent of a team retrospective is to seize the opportunity to inspect itself and to plan for improvements the following iteration.

The intent of a program team and a portfolio team is to serve one tier below and maximize the value creation from those tiers.  While I may dive into alternative approaches for the portfolio level teams in the future, for now I will focus in on the program team.

The Pitch
Given the two aforementioned intents, let’s take a look at the agile manifesto by grabbing just a few of the guiding principles. As we go through, think about the scaled agile team at the program team level. How could they as a team make each of these better?

Simplicity–the art of maximizing the amount of work not done–is essential.
The art of evolving a plan. Planning is an essential part of flowing work through a scaled agile system. Not having an effective planning cadence from the strategy of the organization down to the delivery teams’ user stories can kill organizations. Moreover, the way you plan may not even fit your business model. Everyone, especially the program team, is responsible for maximizing the amount of work not done to get value out of the system. So what improvements can be achieved through progressive elaboration, story mapping, etc. for your program team? What practices do they need to keep or stop doing?

Working software is the primary measure of progress.
Pop quiz hot shot. Who’s responsible for working software? Many agilists focus on the scrum delivery teams and hold their feet to the flames. While my development brethren (shout out .Net devs) should not shirk their responsibility, I’ll tell you that it’s the program team that takes on a larger portion of the responsibility because they can make a gigantic difference in how organizations deliver a solution.  The program team is responsible for making strategic decisions as to when and when to not take on less than desirable software. This forces the quality decision to the correct spot. The program team should be focused on maximizing the value the delivery teams provide and any good product owner knows that a short term win by reducing quality is just that, short term and very costly in the end.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This one is all about the organization enabling the delivery teams to do well. I would ask all program teams to pay attention to the last sentence. How can you best enable your delivery teams to get the job done? Working with them to give them a clear understanding of the vision. Slicing stories better. Helping to protect the team’s capacity. Identify what it is and go make it better.

The Handoff
It would be easy to look at all of the principles and discuss for the program team. While that’s too big an undertaking for this blog entry, I’ll leave you with the last manifesto principle:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
If we have defined above, albeit a small part, what it means to be a successful program team, then we can and should easily retrospect on what it would take to make the team even better.  This means that we should establish a cadence or rule as to when we will either retrospect or “stop the line” to reflect on the desired outcome for scaled teams.

Here’s what I want from you.  Not many people I know are testing this stuff out.  So test it with me.  Give me feedback as to what you have tried.  What success have you found if you tried a retrospective at the program team level?  What failed?  What do you need to start and stop doing?  Sound familiar?