Scaling Retrospectives

WRITTEN BY Tim Wise

look forward

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?

 

leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *

4 comments on “Scaling Retrospectives”

  1. Leading Agile

    Tim Wise

    Hi Ben,

    Thanks for reading and for the comment.
    While I like the idea of a retro of retros, especially the open space style that Kniberg and Sunden were doing at Spotify, I want to encourage a different continuous cadence instead of a release or project level cadence. That’s the spot I am picking at here. It’s really important to me because I often (always?) find that program or product owner teams have a very large impact on maximizing value creation and they often aren’t coached to reflect on themselves. How many of us are guilty of only doing retros at the team leaf level of organizations? I certainly was for a long time. Not anymore ;)

    All the best

    Reply
  2. Allison

    I too have noticed that program-level retrospectives either don’t happen or are held only at the end of a release initially, and I’ve seen scrum teams request more retrospectives at the program-level because they see the benefits of having them at a more regular cadence. And as a coach, I think it’s pretty cool when my teams influence others to become more agile in their practices. :) We also hold retrospectives across the organization a couple of times each year to improve as a whole.

    Reply
  3. Leading Agile

    Tim Wise

    Great stuff Allison. I teach program teams (and portfolios) that they too are agile in the agile system. So far, I think it’s yielded the best result. Really cool to see others doing this, thanks for commenting.

    Reply