6.4. Retrospectives
Last updated
Last updated
Retrospectives (or “Retros”) are used to improve the process, the collaboration, and the tools. The team members discuss what they liked, what they learned, and what they lacked. The outcome of a Retrospective should be an improvement of the current process.
Usually, the Retrospective comes right after the Review and concludes a Sprint.
As an attorney, improving the way you work within your team as well as with your client is crucial. Due to the big impact a Retrospective can have, it should be a standard meeting at the end of every Sprint, but at minimum at the end of bigger or new projects. Within your team in the firm, asking yourselves these questions is part of the continuous improvement process. For this, a separate Retrospective-like meeting can be held on a monthly or quarterly basis.
As they are working in litigation, Alice’s team is one of the teams in Lawyering & Co. that has quite a lot of external meetings, hearings, and court dates. As most of these are scheduled without much of their input, finding spots to meet internally is tough. The next time the whole team will be together is their regular team meeting, which they always try to protect as it feels important to have at least one occasion per week during which all of them meet at the same time.
Even before they started their meeting, Alice is eager to hear how their Agile efforts are doing. When the topic of improving the processes comes up, they discuss if they should add a “Retrospective” topic to their agenda, as Agile has a distinct meeting to review the process, collaboration, interaction, and tools—with the Goal to learn and improve. They quickly decide that it would have to suffice to hold this meeting once a month for a start, scheduling it with the second team meeting of the month. To hold it once per Sprint, as Agile methodology would recommend, would really hurt their scheduling. Once they had done a few Retrospectives, they could reassess their frequency.
Practically, as they are currently in a setup where Alice is working on a few urgent topics and Fiona and Gabriel are working on the Horizontal Builder’s case, both with some pragmatic support by Oliver, their update is rather quick, and they turn to the Agile parts. The resumé was quite quick: they feel energetic, Agile looks promising, but there are ample topics to learn and improve on. They are doing ok with the work on the Elements each of them took, albeit struggling from time to time on detailing them out as expected in Agile—they hope that with practice, mastery would follow. Having not had many Agile meetings, they still agree to include them as part of their team meeting agenda, which they will extend to accommodate the new topics. Yet, they continue to mull over what they would do with the actual cases, especially the review and planning and corresponding interactions with their clients.
Then their first Retrospective comes around, the team sits down and discusses what had worked well for them, what hadn’t, and what they wanted to improve, noting it down in the relevant document.
Participants
Alice, Fiona, Gabriel, Oliver
Frequency/ Duration
Once a month, after the second team meeting of the month
What went well? Using the structure of the Elements to clarify requirements. What can be improved? Having to spell out Acceptance Criteria, DoD, DoR and so on seems like a lot of work for smaller Items. Measure to be taken: When drawing up these parts of an Item, each team member will reflect if the Item or parts thereof be standardized and if so, store them in a central location in their knowledge space. If they feel like an Item is self-explanatory, they will address this in Planning.
Participants
Team
Frequency/ Duration
Once per Sprint, max 3 hours
Look back on the team’s performance and drawing up improvement measures: What went well? What can be improved?
