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.
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.
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.