Scaled Retrospectives: What are they? And will they get me promoted?

The Global Scrum Gathering recently completed in April, and I was fortunate enough to present a 90-minute workshop on Scaled Retrospectives.

I opened my talk with the way google amuses me with its ability to finish phrases or give me options other people have searched for – and for the most part, there are no original ideas.  If you have thought of something, its likely someone else has already thought about it as well, and then created a web page on the exact topic you think is completely original.

If you want to test this out, try typing something absurd, like “monkeys wearing….”, and you will get a whole host of possible topics:  dentures, hats, human clothes, diapers, sunglasses, etc..

During my search, I stumbled across “monkeys wearing wigs”, and then learned that Donald Trump may be in trouble for fabricating his hair piece from monkey hair that belongs to an endangered species of monkey.  What I deemed to be a completely ridiculous internet search, not only yielded results, but entire web pages dedicated to the topic.

With that said, go search for “Scaled Retrospectives”.  Three months ago, there was NOTHING on the topic.  And we (the agile community) have been scaling agile for a few years now.  Perhaps we are too busy attending conferences or trying to grow our twitter influence to spend time contributing to Scaled Retros.  I will posit that this idea of scaling retros will be what defines success for Fortune 100 Enterprises. Not SAFe.  Not a specific tool.  Not co-located teams.  Not Agile-minded Executives.  All of things are important, but above them all – are Scaled Retrospectives.

What is a Scaled Retrospective?

Its the notion of choosing 1 to 2 things every sprint, or every month, or any other cadence you choose – that meet the following criteria:

  1. The selected item is outside the sprint team’s sphere of control to change
  2. Its impeding the team’s ability to deliver
  3. Something needs to be done about it

That’s it.  But its not just collecting those items for each team, its also looking for patterns across the organization to help quantify impact.

The voice of many, will always be more powerful than the voice of one

When I started running these retros, I began data collection for over 100 teams.  Every team wanted to submit 3 to 5 things that were MUST HAVES to fix, which left me with a list of almost 500 items to collect, categorize, de-dupe, ask follow-up questions, make up context, speculate on impact, and form into something consumable for senior executives. Every sprint.  Not only was it not scalable, it was turning into a full-time job for multiple people.

We didn’t want to turn down the ideas and subsequent energy of teams, but we also couldn’t spend weeks collecting and organizing this information.

We experimented with only collecting these insights every quarter, but found out that more scaled retros gave us better real time insights into the challenges plaguing our teams.

A decision was needed, and I made it.  ONE VOTE.  Period.  That’s it.  Make it count.

I still had to go through data collection, but it put teams in a position where they started to talk with each other about how to use the Scaled retro to their mutual benefit.  It was an unintended consequence of the decision, but one that produced incredible results.  Team collaboration – at scale – to solve problems.

Our first scaled retro showed that 70% of our teams felt like we needed an investment in automated builds.  This wasn’t a decision made by senior managers or directors – it was the teams asking for help to solve a challenge that should be routine.  As a senior leader, your job becomes a bit easier when you have ONE item to support, as opposed to 70 items.

I have spent more than 3 years running scaled retros, and have come up with an approach that I believe is effective for producing results.  Instead of producing a 35 page blog article, I’m going to organize the presentation from the Scrum Gathering, into a blog series for folks just starting down this path.

I will also be looking for people that want to contribute to a Community of Practice in this area, and already have some names.  We need to pave the road for people that want to see continuous improvement alive in their Enterprises.  While I have a lot of answers, I am always looking for creative approaches and new ways of conducting these retros.  And admittedly, given that this is potentially a new original thought for the Internet, there are definitely areas we still need to explore together.

Whether you are agile, waterfall, waterscrum, lean, RUPpers, Six Sigma, Seven Sigma, or some other flavor of SDLC delivery model – Continuous Improvement should be at the center of your collective strategy.  This isn’t just for scrum masters, agile coaches, or folks within the agile space.  This is for everyone.  This transcends frameworks.  And yes, it can get you promoted.