How can you ensure your team takes action on their retrospectives?

The way I do it: 1. For every action items, I look for a sponsor/owner. Anyone can own it, and takes the accountability to ensure it is implemented or reminded to the team periodically. 2. 2 times a week, we revisit the action items, within the Sprints. We spend 3-5 minutes in one of the DSs to discuss on it.

To ensure productive retrospectives and cultivate a culture of continuous improvement within your team, it is crucial to establish clear objectives, fostering a safe and open environment for discussions. Employ structured facilitation techniques to guide conversations while respecting time constraints. Document actionable items with assigned ownership and deadlines, and consistently follow up on their progress. Encourage team members to reflect on the effectiveness of actions and secure leadership support for the retrospective process. When consistently applied, these steps create a culture of continuous improvement where insights from retrospectives lead to tangible actions and a more dynamic and responsive team environment.

Great formats are helpful. And no, great formats are not sailboat, Halloween retrospective and the likes. Formats that are simple, avoid cognitive overload, and speak of true issues for the team is key. Changing format every single sprint is a logistics nightmare and prevent change to have a follow up. The best formats are: - A key question the team is constantly trying to answer. - A dashboard that aggregate quantitative and qualitative data they want to keep pursuing for improvement.

Action Items: Clearly define and document actionable tasks arising from retrospectives. Prioritize: Ensure the team collectively prioritizes action items based on impact and feasibility. Follow-Up: Regularly revisit and review progress on action items in subsequent retrospectives. Celebrate Success: Acknowledge and celebrate the completion of action items to motivate the team. Continuous Improvement: Encourage a culture of continuous improvement by learning from retrospectives and adapting processes. By establishing clear action items, ownership, and a culture of accountability, you can ensure that your team takes meaningful actions based on retrospective insights.

After a few trials, I've found leveraging product backlog an effective way to make outputs from retrospective meetings actionable. During backlog grooming the team gets an opportunity to spend quality time on retro outputs to scope them well and do relative prioritisation. This exercise also makes the team think of their inputs in actionable manner or as "SMART criteria" because to add a task in the backlog you need to write it clearly and make it actionable. Another thing I find very effective in every retro call is to spend 5 mins to status check all the inputs identified in previous retro. This allows the team to stay on top of the retro actions and builds confidence that their inputs are taken seriously and have a positive impact.

I agree that prioritization and assignment are vital. In my experience, prioritizing the most impactful actions is key to driving real change. However, I don't necessarily assign actions directly. Instead, I encourage team members to volunteer for actions they're passionate about, fostering a sense of ownership and commitment

Yeah, we as a team always try to have list down the retro items in a board where it's visible for everyone and try to talk/spend time over the following sprints to ensure that the team overcomes the issues either its behavioral or Technical. To make sure everyone in the team is involved, we will assign each activity to an individual to make sure they aren't left out in any activity.

One practice I find valuable is making full use of Retrium for retrospectives, enabling effective prioritization, assignment, and tracking. As an Agile Practitioner, I don't believe in assigning work but rather prefer the approach of simply asking, "Who would like to take responsibility for this item?" This fosters a sense of ownership and collaboration within the team.

Every retrospective should have action items documented on the same board (along with other columns like what went well, etc or whatever format is being used). Each action item should have an owner listed along with it. While the action items can be marked as done as and when they get completed, the action items should be reviewed on the next retrospective.

During the "Deciding what to do" portion of the retrospective it is important to identify as a team at least 1 and no more than 2 action items. We want to keep the number small so as to be able to focus on it and if it is too large, then we aren't sure what change made the positive (or negative) change. It is also important to not assign actions to the team members, ask for a volunteer about who would like to own the Action Item making it clear that owning it does not mean that they are responsible for making the change themselves, rather that they are responsible for reminding the team about the agreed upon change.

Improvement items should be added to the Sprint Backlog or whatever approach you use to make work visible and transparent. More importantly, keep it simple, reduce friction, and make it easy to follow up by incorporating continuous improvement into your existing way of working.

Based on my experience, incorporating action items into a sprint has proven effective in ensuring accountability and visibility. As the prompt suggests, this practice can become a talking point during daily stand-up meetings if further discussion is needed, or it can be taken offline for a more in-depth examination.

Make your Action Item(s) highly visible. They should be able to be easily discovered by any team member as a continual reminder of the agreed-upon change.

As I mentioned above, constantly revisiting the item until it's done or until it loses importance is key. In fact, as you place retrospective items in the scope for the upcoming spring, prioritize it accordingly to the rest of user stories and tasks. It HAS a relative importance and this should be acknowledged. It's an interesting experiment to write the item either as a user story or at least with WHO/WHAT/WHY/WHEN.

1) Regularly Review Progress: During retrospectives, review the progress on previously identified action items. This helps the team stay accountable and allows for adjustments or additional actions if needed. 2) Celebrate Successes and Learn from Failures: Acknowledge and celebrate the successful implementation of action items. Equally important, use any failures or incomplete actions as opportunities for learning and improvement. Discuss what prevented those actions from succeeding. 3) Feedback Loop: Encourage team members to provide feedback on the effectiveness of implemented actions. This feedback can help refine the process and make retrospectives more impactful over time.

Sprint retrospectives can foster a culture of trust and continuous improvement by emphasizing experimentation and learning from mistakes. Encourage team members to openly discuss challenges and opportunities for improvement. Instead of assigning blame, frame mistakes as learning opportunities. Collaboratively identify experiments or actions to address issues, and ensure they align with clear objectives. Trust among team members and a commitment to continuous improvement will be nurtured when the team collectively learns and adapts from their retrospective insights, fostering a culture of innovation and growth.

As per my experience we can include the action items from the retrospective into your day-to-day, whether it’s in stand-ups, or weekly team status updates.

Asking for feedback on the retrospective does two major things: - the team critiques and improves format and ROI of their time sent in retros. - the team start to become owner of how retrospectives run in their best. When retrospectives improve, 30 minutes or so are sufficient for the team to work on the discussion and selection of the most important situation or issue of the sprint. Or on any ongoing issue. Avoid too many format change. Great retros do not require fancy formats, but more so insightful questions and great facilitation.

In my experience, asking for feedback during retrospectives is essential for several reasons. It allows the team to reflect on what worked well and what didn't in the previous sprint, enabling continuous improvement. It empowers team members by giving them a say in the process, fostering a culture of collaboration and open communication. Constructive feedback can uncover issues or opportunities that might have been otherwise overlooked, ensuring informed decisions and prioritized improvements.

Most of the improvements are systemic and not at a team level. So, as a Scrum Master, I actively work with management to bring those changes or remove those impediments on the way of the team from delivering value. Also, I periodically do retrospective of retrospectives to ensure continual improvement.

Often, members of varying experience and exposure are put together to work in a team. Like team norms, the team should create a collective vision to align on what great quality work looks like and at the same time agree on an approach towards suggested improvements. This includes which parties have accountability for what. Then, retrospectives should provide the team a frequent chance to inspect the feedback received and adapt to ensure that the work is progressing well in the intended direction. If work is not done up to the team's requirements of quality, the team should plan the improvements into upcoming sprints. Great work focuses on outcomes and takes away blame from a single person. The team should work together to deliver quality.

Retrospective feedback is a great way to improve the speed and quality of the sprints while building a cohesive team. Accepting the feedback is really the most important step. Then the process ensures actions are taken. Process could be jira tickets assigned with due dates and follow-up review of previous sprint actions and results.

Recognise and reward the team for their actions to motivate them to continue taking action and initiatives on the retrospectives.

Avoid broad and ever-changing format for retros. And talk about what matters and is actionable. Teams only take action when the retrospective speaks of the things that matter to them. While there are changes needed in structures of the organization, it's a bit of a blind spot to consider teams cannot work on improvements for themselves, despite the circumstances in the organization. Finding what matters to the team is key. Is it that they should work on a better pace? That they could learn how to better negotiate requests? Sometimes it's as simple as getting their build to work faster. When quality and improvement are properly defined, agreed upon, and measured, teams don't struggle to move forward with incremental change.