Agile Retrospective
Hi guys; lately I have been running a couple of workshops on the topic of Agile Retrospectives (if you are interested in participating, you can subscribe here), and I have been collecting a lot of fantastic ideas.
All this work is based on my book, Getting Value out of Agile Retrospectives, which you can buy right here.
In this blog post I want to tackle a specific issue that I heard about a lot during my training sessions: how can we explain what an Agile Retrospective is to non-technical people? (Senior Management, for example.) This “fluffy” thing called Agile Retrospective does not say anything to them.
So how can we explain to Non-technical people what an Agile Retrospective is, and why should we do it?
What is an Agile Retrospective? An Agile Retrospective is:
- is a team ritual
- is an regular and important time slot for the whole team
- is an event where teams stops and analyse their way of working
- is a place where the team reflects on how to become more efficient
- is an event that is used for reflection.
- is an event where teams look back and analyse how they performed
- is an event that is used to recognise hard working between peers
- is an event where teams find improvements on their way of working
- is an event where teams try to arrange new ways of working to avoid default thinking patterns
- is an event where issues are discussed without blame or accusation
- is an event where the critic is done on the working output and not on the people
- is a corner stone of any inspect and adapt cycle
- is a data mining event where the team collects information about what happened during the sprint
- is a creative event where the team generate dozens of different possibilities to help them to become better
- is a place where the team self reflect about their own working environment
- is a place where the teams learn
I believe with this list you will have more arguments to justify to non-technical people the necessity of an Agile Retrospective. Hope this will help you.
I would love to get a star rating for this post:
(4 votes, average: 4.75 out of 5)
Loading...
I tried to comment on LinkedIN but something went wrong.
Anyway, I’d like to add: “is a meeting where the self-adaptation ability of the team gets boosted”
All descriptions are relevant. If I were to describe sprint meetings, I would use the word ACTION more.
E.g. is an event where teams stops and analyse their way of working *and agree on action to improve*
This is in line with my general feeling that too many retrospectives lack clear action or promise too much action. And that’s a missed opportunity to really improve. Of course action can only come after reflection.
Big thanks for your comment :) You are completely right :)
Luis
1st comment:
I believe that if you want to explain to non-technical people you need to use the terms of non-technical people or managers.
Those terms that come to my mind in that context that could be mentioned are e.g.:
“lessons learned”, “good practice”, “room for improvement”…
2nd comment:
“Is a creative event where the team generate dozens of different possibilities to help them to become better”:
Yes, this is very good but I beliebe it is only the first step: diverging.
The subsequent 2nd step I am missing here: converging, or creating focus (after the brainstorming). This is where the team then picks just two or three of the items to put them into life during the next cycle.
I believ that “good managers” also want to hear that: that there is not just a lot of talking involved, but that there are very concrete, actionable and focused results at the end.
Very good points Andrea :)
Many many thanks :)
Luis
These are two reasons I would add to your list. I probably read them in your book, which I consider a valuable resource! So thank you for writing it!
1. The input from the team’s self reflection and assessment helps the entire organization realize what their best practices are.
2. The solutions teams implement to address challenges they encounter can be utilized/adopted by other teams throughout the organization that are facing similar challenges.
Thank you so much :)
heheh at some point its easier to have people remind us what we wrote :D :D
Big Thanks,
Luis
Sorry this is a bit of a shameless plug so I hope it’s of interest. We have a tool we originally developed for requirements discovery but have a number of customers that have found more value using it to solve other business problems. One of the areas we saw it used was in retrospectives to help the team reach a shared understanding of their ways of working.
Using a construct similar to user stories, asking the question ‘so that?’, or ‘why?’ for every step in the process highlights all sorts of improvements.
Nice to see everything in a simple list. I’m thinking on number three I like ‘efficient and effective.’ I like the frame of “is a creative event” among others. Nice article. I added it to my Retro Resources page as well.
Big thanks Jake :)
Have a nice day :)
Luis