Get certified - Transform your world of work today


Scaling with Scrum Retrospectives

Using a Retrospective of Retrospectives for Scaled Programs

1 September 2015

Sagar Date
Cognizant Technology Solutions

The sprint retrospective is undoubtedly one of the most prominent rituals that helps move self-organized and self-directed Scrum teams into empiricism. In a retrospective, the team discusses the various aspects of the last sprint and tries to evaluate where they are on the journey toward agility and process improvements. Retrospectives help them develop a road map and definitive actions needed to reach their destination.


Although the retrospective event is held at each iteration and the team completes most of the actions in subsequent sprints, larger Scrum programs comprising multiple teams often need the changes from the top down rather than from the bottom up.

For example, teams often experience the following problems in a large Scrum program:
  • Communication among the program stakeholders needs improvement to fill the information gaps that eventually affect the team's work.
  • A consistent key performer at the team level is not acknowledged and appreciated by external stakeholders.
  • Team A wants Team B to notify them of crucial changes immediately, when they are planned, rather than waiting to be notified until the Scrum of Scrums.


As more projects and programs start using Scrum and experience these problems, a recommended solution is to plan and conduct a Retrospective of Retrospectives (RoR) at the program level, similar to the Scrum of Scrums ceremony. RoR helps Scrum teams bubble up the external impediments, highlight key achievements, and extrapolate good practices across programs and stakeholders. This also gives program management and stakeholders better visibility into the needs of their teams so they can then design a solid, top-down plan for improvement.

Problem revisited

Even when the RoR provides the teams and stakeholders with the platform to inspect and identify changes at the next level, one major problem that still exists, which is significant for scaled programs, is the adaptability rate. Although it depends on the maturity of the program, these changes are rarely using a top-down approach.


When scaling Agile, teams usually encounter the following challenges:
  • Program-level (macro) changes are more complex and more costly to introduce than team-level (micro) changes.
  • Scrum teams are more committed to the work than are the external stakeholders, which is the classic chicken-pig story. Partial assignments and distributed programs further affect the adaptation of changes.
  • There is a lack of event coaching. ScrumMasters work closely with the teams throughout the sprint cycles. They coach and guide the team through every event. Although Agile coaches are doing the same thing at higher level for scaled programs, lack of dedicated Scrum events prevents program stakeholders from learning new techniques.
  • Program goals are broader and deeper in scope than team goals, and many times they are not defined specifically for the program. Teams are held accountable to the Definition of Done and do everything they can to achieve this goal. Retrospective items are one of the factors that, when improved, eventually lead them to their goal.
  • Adapting lightweight governance without compromising agility is a problem. Agile governance that is not adapted at the program level ruins it further. It limits its ability to promote best practices, coordinate or synergize cross-functionally, identify gaps, and share knowledge.

Suggested path

Although the challenges cover various aspects, levels, and areas of the program, it's almost impossible to resolve all of them in one pass. Furthermore, all these problems need to be discussed in the RoR for the program to take the appropriate action.

An RoR backlog becomes the go-to tool to track and overcome the challenges through empiricism.
  • Finalize well-defined goals and actions after every RoR, with a target to achieve them by the next RoR.
  • Implement an information radiator. The RoR backlog board is maintained and displayed in the most visible place on the floor and provides at a glance the status of planned, in-progress, and closed items.
  • Create a group of Agile enthusiasts, coaches, and ScrumMasters from the program to maintain the RoR backlog. Identify one owner for each iteration through the use of volunteers or round robins.
  • Similar to the product backlog, the team, stakeholders, and management can add an RoR story or an improvement item at any time.
  • Implement a strategy for prioritization, affinity estimation, or T-shirt sizing to avoid cherry-picking and focusing on irrelevant items.
  • Split larger items into smaller items, such as user stories.
  • Reward contributors. The program's Wall of Fame helps to publicly recognize and acknowledge talent and efforts.


Programs that catered to the team’s needs through a top-down inspection and adaptation approach improved at a faster rate than the bottom-up approach for improvements, as was expected.

This article summarizes the retrospective initiatives program our team took in a scaled program. It not only helped stakeholders, management, and delivery teams adopt the Agile transformation and mature in a relatively short time but it also helped reduce the delivery cycle to one-third of the originally targeted timelines. A top-down approach for an Agile transformation has been proven to be the most appropriate approach in this case. The purpose of this article is to share the steps we took rather than the experience and not to take credit for any of the theories practiced and proposed earlier by any other author.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.6 (10 ratings)


Nikita Ajwani, CSM, 9/1/2015 2:58:11 AM
Hi Sagar, very interesting article and RoR seems to be a great idea.
But I have a case here, which is probably somewhat similar.
A program has 9 people (1 Scrum Master, 1 BA, 2 Testers, 1 Tech Lead, 4 Developers). Now, there are 4 projects and in each of them these 5 are common 1 Scrum Master, 1 BA, 2 Testers, 1 Tech Lead, what changes is the Developers for each Project. So, of the 4 developers, each project has a different one.

What do you think should be done in this case regarding the Scrum of Scrums or RoR?

How about having 1 Daily Scrum for all 9 people? or having separate retrospectives for each project team with the set of common people and one developer?
Sagar Date, CSP,CSM,CSPO, 9/1/2015 5:51:32 AM
Thank you Nikita for your comment!
As you stated in your scenario, I will say you have shared and fixed resources for your teams (not program).
When I propose top down changes through RoR, I would look at broader range of stakeholders from program - enterprise architects, POs, functional resource managers(after all they should know their resources being recognized) to Agile Program Managers/budget managers, release managers, SMEs and other entities who have strong interest in the software you are making to name a few.
From your teams, although eventually everyone contribute towards the program; the key shared members (except scrum master) you mentioned are necessary (again not all of them) but not sufficient towards program RoR. This is because many of the program challenges teams faced cannot be practically resolved themselves. e.g. team A needs one more resource who know automation can only be resolved by functional managers and budget controllers.
For your scenario continue with 4 scrum level team retrospectives, which you surely be doing, and get the other folks mentioned above into your SoS and RoR.
In-fact you can start with a pass of discussion/brain-storming to identify right stakeholders. This is based on the interest level of stakeholders into product as well as the historical data like frequently faced problem areas e.g. resourcing, technical, budget, end user representatives. Also make sure that agenda of SoS and RoR are exclusive, timebox, frequency and calendars are identified and attendees have commitment towards the time and help.

From team(shared+fixed), you can pick Scrum Master(process), Tech Lead(technical) and one member from test + dev. + BA.(coach them to choose though round robin each week/event than assigning someone permanent ownership). Idea behind is, we should limit utilizing team members bandwidth for program ceremonies and also at the same time giving every member the opportunity to get holistic view they will discuss at program level events. Being team agent into program level events also brings the transparency where team is assured that their scrum master and tech lead also echoing their problems to the broader audiences.
Let me know if it helps…
Tim Baffa, CSM, 9/1/2015 4:36:26 PM
@ Nikita,

The scenario you described seems too small to realistically benefit from a multiple-ceremony approach (RoR or multiple daily stand-ups). You did not state whether there were 4 backlogs (1 for each project) with 4 Product Owners, or whether one backlog/Product Owner was directing the work of all 4 developers.

My question to you would be - why is your organization isolating each of your developers by project? I would support a single-team approach with all 4 developers working together on sprint stories. The effort would then be with the business to prioritize the work among the 4 projects for the team to work on.

@ Sagar,

Interesting concept around a Retrospective of Retrospectives in response to scaling issues.

I don't disagree with anything stated, except for a couple items:

"A consistent key performer at the team level is not acknowledged and appreciated by external stakeholders."

"Reward contributors. The program's Wall of Fame helps to publicly recognize and acknowledge talent and efforts."

I would caution against any attempt to promote or acknowledge individual contribution. In my opinion, such activity is detrimental to team unity and identity, and does more harm than good. I would certainly acknowledge the accomplishments of the team (or the RoR contributors as a whole), but not on an individual basis. Treat them like the highly-functioning unit you want them to be.
Sagar Date, CSP,CSM,CSPO, 9/3/2015 4:20:52 AM

I would caution against any attempt to promote or acknowledge individual contribution. In my opinion, such activity is detrimental to team unity and identity, and does more harm than good.

Both agree and disagree with you here, my experience is with both the new born teams and mature scrum teams is complete contrast to each other.

While as you said recognizing individual could be detrimental to team, I feel that could be only case with new teams. Mostly those are into forming and storming or early norming. However as teams get older, mature and grow with self organized experience and coaching i found them enjoying and sharing a joy of individual appreciations.
Sumala Azariah, CSM, 9/3/2015 10:08:01 PM
Great article on RoR- In my experience I found that when agile is scaled to distributed teams with multiple stakeholders in a program, RoR inputs are gathered but not worked on systematically. The advice to have agile coaches or champions to track challenges and bring process improvements is a great idea and has worked well in my experience.
Jaykumar Chaundkar, CSM, 9/9/2015 1:54:09 AM
I went through this article but really It is a wonderful article on RoR. I especially loved the they way Sagar tries to explain concept of RoR in simple way(extremely productive). This article diffidently helpful to break the ice, and understand the concept of RoR in simple way. Also it will guide all distributed teams with multiple stakeholders where needs to be improve.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up