The Overall Retrospective for a Team and Stakeholders

After rebuilding an existing application on a new tech stack within time and under budget our team had an overall retrospective with stakeholders this week to identify systemic issues. We found more than 20 problems in total and derived eight detailed recommendations the organization will need to address when moving forward to the next level of agile product creation. 

Read on and learn how we achieved this result in under two hours with an overall retrospective attended by 16 people.

The Origin and Purpose of the Overall Retrospective

The concept of an overall retrospective is a ceremony borrowed from Large-Scale Scrum:

“The Overall Retrospective is a new meeting in LeSS. Its purpose is to discuss cross-team, organizational, and systemic problems within the organization.”

Source: Large-Scale Scrum.

We decided to adopt two changes by comparison: a) we ran the team’s overall retrospective after achieving a significant result: the application launched successfully four weeks earlier, and b) all team members participated, not just representatives from the team. (Instead of having two teams, we worked as a large, distributed team anyway.)

The purpose of this overall retrospective was to provide recommendations to the organization on how to improve working in an agile manner for future teams and products.

Preparing for the Overall Retrospective

To run an overall retrospective, you need to have:

1. A large room that provides enough space to host up to 20 people working in front of several boards and walking between them.
2. Large stickies in different colors—each team shall have a different color.
3. Sharpies.
4. Sticky dots for dot-voting.
5. Board labels that address the topics of the overall retrospective.

For the intended discovery and discussion, I picked the following four topics:

1. Working with the organization.
2. Working with customers.
3. Agile and Scrum.
4. Technical excellence.

The overall retrospective started with creating four teams — one for each topic. Given that sixteen people attended the ceremony we ended up with four teams of four people each working in parallel on four issues.

The overall retrospective had three different phases:

The Ideation Phase

In the ideation phase, all teams were working at the same time for seven minutes on a topic, each creating their three most important issues in an open discussion. At the end of the time-box, the team moved the resulting three stickies to the backside of the board to prevent creating bias in the following group. Then each team moved on to the neighboring board. This way, all teams were cycling through all four topics within about 30 minutes.

The Clustering Phase

At the end of the fourth cycle, each team was asked not just to move their three issues to the backside but also have a look at the already available nine other stickies. Their task was to cluster all twelve stickies at the board into similar topics to prepare for the third phase of the overall retrospective: the ranking of the issues by dot-voting. 

The clustering phase took about ten minutes as we discovered that we listed similar topics on different boards. The team hence decided to have a brief check on all four boards to identify related issues and put them on the same board.

The Ranking and Discussion Phase

The third phase of the overall retrospective started with a dot-voting on the identified issues across all boards. In total, each participant had six dots, and everyone was free to assign them (there was no limit on the number of dots that could be attached to a single issue). This part took about ten minutes.

The three highest rankings issues were:

1. Autonomy in technical questions (17 out of 96 possible votes).
2. Longevity of teams (11 out of 96 possible votes).
3. Clash of cultures: Agile vs. Waterfall (7 out of 96 possible votes).

These top three issues attracted almost 35 percent of all available votes.

The final part of the overall retrospective was a lean coffee to create recommendations for the organization based on the top three ranking issues. This part required about 60 minutes and delivered eight suggestions in total, for example:

• Empower teams to make appropriate technical decisions for their product/project.
• Involve the overall team in the initial definition phase of the product/project.
• Don’t move people on and off the team.
• Empower the product owner in the sense of the Scrum Guide.
• Align project governance with Agile practices, for example, in procurement, legal, HR.

If you are now under the impression that this organization is still in the early stages of its Agile journey you are right. The good news is, though, that the team’s success also triggered a promising development: next year, the team will become a product team as the application is no longer considered a project. 

Conclusion

The overall retrospective with the team and its stakeholders proved to be a success. Everyone was positively surprised by the compact nature of the retrospective and its outcome. Of course, the overall retrospective cannot guarantee, in the end, that the recommendations will be accepted. At least, the people involved in building the new application lived up to their part of taking responsibility for continuous improvement.

How do you educate your organization? Please share with me in the comments.

Download ‘Agile Transition – A Manual from the Trenches’

The latest, 174 pages strong version of Agile Transition – A Hands-on Manual from the Trenches is available right here, and it is free!