{"id":351946,"date":"2024-05-20T21:59:01","date_gmt":"2024-05-20T21:59:01","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=351946"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=351946","title":{"rendered":"ABBYY: Mobile Technologies \u2013 Retrospectives<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

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.<\/p>\n

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\u2019s say it, once a quarter.<\/p>\n

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.<\/p>\n

What happened at Retrospective<\/strong>? It was always a long and difficult meeting<\/strong>. During the meeting the team gathered a long list of pain points<\/strong>, possibly with some preliminary description of what should be done<\/strong> to resolve the identified problem. But what happened next? \u2013 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!). <\/p>\n

What is wrong here?<\/h2>\n

Having only quarterly<\/strong> Retrospectives, we failed to organize the continuous process. The retrospectives happened too seldom<\/strong>, 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. <\/p>\n

So, what to do?<\/h2>\n

First, it should be noted that in Scrum<\/strong> framework, the idea of Sprint actually replaces the concept of Project \u2013 Sprint is assumed to cover the full development cycle<\/u><\/strong>. If in fact<\/strong> this is not the case<\/strong>, we need to turn to some ideas from classical Project management<\/strong> on how to organize the missed pieces of development cycle. <\/p>\n

And here it is to note that I understood that the Continuous Improvement<\/strong> is also a Project, a meta-Project<\/strong>, that should be considered like a Project:<\/p>\n