Retrospectives
| last edited by: Antonio Villarruel on Mar 25, 2022 10:25 AM | login/register to edit this page | ||
| Keywords: Knowledge and Skills PMI-ACP Retrospective | |||
 OverviewThe Retrospective completes an Agile Iteration and is a vital part of the Agile Feedback Loop. Team and Product Owners usually are stating and demonstrating value created during the last iteration and discuss what went well, what could be improved upon and how. This phase is comparable with the "lessons learned" process during the closing phase of a regular project following the PMBOK at the very end of a project where depending on the duration of that project remembering and stating those issues might be difficult.
The Retrospective at the end of every iteration gives the opportunity to adjust the process more frequently and when memory is still fresh and utilize proposed improvement measures for the next iteration and therefore for most of the remaining life cycle of the project. Instead of stating what we could have done better in an Agile Environment, we adjust our process immediately. Difficulties to remember issues and their solution after time had passed during a longer project, fatigue of the project team that often had been going through the hardest and most exhausting phase of the project to complete and deliver and the starting process of team dissolution often prevented this process at all, cut it short or made it less efficient.
Criticism and potential conflict was often avoided knowing that a team member might not be on the next project in the same team and realizing that "lessons learned" could only have impact on the next project, but not change the outcome of the current one. For the same reason, it might have been very difficult to get stakeholders and sponsors involved. Since team and product owners might talk on a very personal level about conflicts in the team, between team and product owners or between product owners and the intent to improve on the process often includes criticizing individuals, that (vital) part of the meeting is usually not public and separated from the first part. Iteration Retrospective and Iteration Planning often are scheduled "back to back" to smoothly transition into the next iteration and potentially save meeting time for team and product owners. It is generally recommended to keep both meetings separately time-boxed and when performed back to back not to exceed 2 hours total (with a break) to keep attendees attentive and focused. Commonly Retrospective and Planning are time-boxed one to two hours each. It is recommended to separate the two meetings initially to emphasize the importance of both and prevent unintended merging, or when later combined time would not allow to perform all tasks in due time and length or the combined meeting time would exceed two hours. Since the Retrospective meeting is held after every iteration at the same time and at the same location it is often used and referenced updating users and stakeholders on the project progress. This might offer a powerful opportunity to include those groups into the project feedback loop and create ownership for the project on a broader base. Agile Teams commonly spend less time with Retrospectives the longer they work together and the further they are along in a project since their process has evolved and improved from iteration to iteration, hence the common desire to combine Iteration Retrospective and Iteration Planning in one meeting.
Regardless of what we discover, we must understand and truly believe that everyone did the best job they could, given what was known at the time, their skills and abilities, the resources available, and the situation at hand.
Step 1 (5 min): Team safety check: Each team member anonymously writes down a number between 1 & 5 on a post-it note. All post-it notes are collected and stuck on the board in front of the group. The number represents how "safe" each team member feels to express their true feelings in the room at this time, with these people. The aggregated result determines how the team should interpret the remaining discussion in the retro. The definition of each number is as follows:
Step 2 (10 min): Team brainstorming under the following 3 headings: Using a whiteboard or butchers paper, each team member takes a pen, gathering around in a scrum and brainstorm method ideas under each of the three headings. No discussion allowed. Step 3 (10 min): Review each of the three lists one item at a time. Each team member who wrote the item can elaborate on the intent & meaning (less than 1 minute per item). Questions of clarification are fine, but no discussion is allowed. Step 4 (5 min): Voting: Each team member takes a pen, gathers around in a scrum and votes for items that he feels are important and warrant further discussion. Various voting techniques can be applied; the simplest is to allow each team member to vote as many times as they want, but not for the same item more than once. Sum the votes and identify the top 2 or 3 items. No discussion allowed. Step 5: (balance of your time - 25 min) Discuss each of the top voted topics. Step 6: (5 min) Document & confirm actions, owners and due dates. Share this list with the team (via email, SharePoint, Visual Management, etc) Follow-up: The team holds each other accountable for ensuring actions are completed.
|
|||
| last edited by: Antonio Villarruel on Mar 25, 2022 10:25 AM | login/register to edit this page | ||
