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 recommendation 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 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.
Please click the “clapping hands” 👏_, if you found this post useful–it would mean a lot to me!_
To run an overall retrospective, you need to have:
For the intended discovery and discussion, I picked the following four topics:
The latest, 174 pages strong version of “Agile Transition — A Hands-on Manual from the Trenches” is available right here, and it is FREE!
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:
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.
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 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:
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 to the organization based on the top three ranking issues. This part required about 60 minutes and delivered eight suggestions in total, for example:
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 that a promising development: the team will become next year a product team as the application is no longer considered a project.
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.
Please click the “clapping hands” 👏_, if you found this post useful–it would mean a lot to me!_
Do you want to read more like this? Well:
Originally published at age-of-product.com on November 8, 2017.