To improve Agile Retrospectives, learn what’s wrong.
The problem is not your team, or the process. The problem are your outputs.
Based on http://www.extremeuncertainty.com/main-reason-agile-retrospectives-dont-work By Leon Tranter
If you are in a software development team that uses #Agile methodologies, then you know that the key for your team’s continuous improvement in the long term are the #Retrospective sessions. Yes, there’s a few more events in #Agile (Stand up meetings, Estimations, etc.) but Retrospectives are specifically designed for continuous improvement.
Tell me if this sounds like your situation: Project Managers, Scrum Masters, and Software Development Engineers are on board with Agile. You’ve read all about Retros. You get together at the end of every sprint, discuss what went well, what went not so well, and what could be improved. Everything sounds great; but the team doesn’t feel like the retrospective is getting them anywhere. Results are recorded and then forgotten, nothing gets done and people are quickly discouraged. You’ve tried different formats and techniques. But still no improvements.
What’s wrong?
Leon tells us that most people will try to change the inputs, (inviting different people, getting a different facilitator) or changing the process (the questions or structures around the meeting). But the problem is usually with the outputs.
The outputs in your retrospectives are more likely to be complaints, questions, or general ranting or blaming, which makes the retrospective a bit of a witch hunt. Then people lose trust and the issues discussed are never really transcendent. If this is the case, nothing is going to change! What do you expect your team to do with these results (Complaints, rants, etc.)? Change and improvement will happen only if the outputs of the Retrospective session are concrete action items with an assigned owner and a given timeframe. Every team should be committed to dedicating some time to continuous improvement, and the best way to do so is through effective way is to LEARN FROM THE EXPERIENCE AND PLAN CHANGES FOR THE NEXT EFFORT.
This came up during our conversation with Luke Homann, Conteneo’s CEO. The team will most likely point out something very general: “QA is taking too long” or “Communication needs to be improved”. Not that those are not valuable contributions, and if that’s the case the whole team will most likely agree. But if that’s the result of your Retrospective, then again: What do you expect your team to do with these?
For a retrospective to be valuable, the output necessarily needs to be an ACTION ITEM, an ACTIONABLE ITEM, a PRECISE, EXPLICIT, ACTIONABLE ITEM. To clarify: An Action Item.
It is up to the facilitator to keep digging to determine the root cause of these issues that come up and establish an action item. One way of doing this is the “5 Why’s” technique. Using this technique, you can find that QA is taking too long because of a config problem of some components, as Luke found out; or that the real communication problem is your team’s time zone difference, so that’s what you need to fix (Perhaps using a cool slack bot that allows you to have asynchronous meetings?)
That’s only the first step. Things are not just going to happen on their own. You also need to assign a team member to take ownership of that action item, establish a timeframe and obviously do a continuous follow up on the item.
So it goes like this:
Have a Retrospective > Find Issue > Establish Action Item > Assign an Owner > Determine a Time Frame > Follow up > Next Retrospective.
Taking in consideration that these action items are in no way user stories or “tickets”; How do we keep track of them?
The best way is to put them up on the team’s board. Not the sprint board. On your task board. Either physically or digitally, the open action items from every retrospective should always be visible for the whole team. If you use Atlassian, then put them on a page on Confluence using the Retros add-on. If you use Trello, put them in one of your boards, etc. This way you and all of your team will have visibility of the progress.
It’s worth mentioning that not every action item will be solved in one sprint. For this matter, and for follow up purposes it is good practice to start your next retrospective by reviewing the action items that came up in the previous session and talk about what was done. If an action item is still open, then you can escalate, persist, or give up on the item. Obviously giving up is the last option!
Visit SoftwareDevTools.com for to try cool tools for Agile, remote teams!
