I think Retrospectives are the most complicated thing in SCRUM. According to the framework, retrospective should happen at the end of every sprint, where we discuss how we executed the sprint, what was good, and what was wrong, what the improvements are required to increase team stability, to increase its velocity.
ABBYY is a Product Company. Most teams have a long development cycle, so at best they have a quarterly Product Incrementing. And the Retrospectives are timed to such product increments, that is, they occur at best also, let’s say it, once a quarter.
I am Project Manager in the department of Mobile Technologies. In the next paragraph I describe my teams, what was the situation with Retrospectives, just to indicate the problem.
What happened at Retrospective? It was always a long and difficult meeting. During the meeting the team gathered a long list of pain points, possibly with some preliminary description of what should be done to resolve the identified problem. But what happened next? – Almost nothing: the team continued working during the next quarter until the next Retrospective. Where everything was repeated again: a long difficult meeting, and a long list of the pain points (formulated differently, so, I would say, everything from scratch!).
What is wrong here?
Having only quarterly Retrospectives, we failed to organize the continuous process. The retrospectives happened too seldom, some of the planned actions were performed, but, of course, not all of them. Many of the required actions were formulated too abstractly, usually having no clear action plan and no clear definition of done. And because the process was not supported by regular checks, it was fading incomplete.
So, what to do?
First, it should be noted that in Scrum framework, the idea of Sprint actually replaces the concept of Project – Sprint is assumed to cover the full development cycle. If in fact this is not the case, we need to turn to some ideas from classical Project management on how to organize the missed pieces of development cycle.
And here it is to note that I understood that the Continuous Improvement is also a Project, a meta-Project, that should be considered like a Project:
to build some additional action plans on how to achieve the goals set in definition-Retrospectives and
decompose the actions closer to the sprint level.
This requires some additional groomings – the same approach as for the Feature planning described in my previous article.
In addition, I should note that the Continuous Improvement is more like maintenance, and closer to Kanban than to Scrum. Do not expect that all the goals defined in the previous definition-Retrospective will be achieved by the next one. Some targets may simply be blocked for a long time just because the next PI does not have the same problems as the previous one.
The next definition-Retrospective should be based on the materials from previous one. During the next definition-Retrospective you just to refresh their status and add to them something new, identified during the next PI. And because of that I assume that the next definition-Retrospective will be already much easier! 😊
Conclusions
Continuous Improvement is also a Project, a meta-Project, a maintenance that usually lasts longer than the main development project.
If you can fit into the Sprint boundaries with your development cycle, then the concept of Retrospective as it is formulated in SCRUM may also suit you. But if you are bigger and not oriented on CI/CD, then be ready to make a hybrid of SCRUM with classical Project
What is left out in when we run retrospectives quarterly? – Plan and Check. The placeholder of classical SCRUM Retrospective is quite suitable for that purpose, surrounded, of course, by some additional groomings, providing required action plans and decompositions up to sprint-length steps.
Retrospectives are the "Check" part of the Planning procedure. Please refer to the first article ABBYY: Mobile Technologies – SCRUM Planning in Detail to learn more about how we adjusted Planning for the case when you mostly follow the paradigm of quarterly releases.
Thank you for your attention, and I would be happy for your feedback and your questions.
Good luck on your Stairway to Heaven!
