16 simple ways to explain What is Retrospective in Agile
16 SIMPLE WAYS TO EXPLAIN WHAT IS RETROSPECTIVE IN AGILE
Hi guys; lately I have been running a couple of workshops on the topic of Agile Retrospectives, 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 a Retrospective? An Agile Retrospective is:
- is a team ritual
- is a 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 anAgile Retrospective. Hope this will help you.
Of course, this blog post served just as a small summary. If you really want to understand what an Agile Retrospective is you must go there:
What Is An Agile Retrospective
If you are interested in getting some Agile Retrospectives exercises, I created a blog post with dozens of Agile Retrospectives Ideas, check them and see if you find something interesting.
ORGANISATIONAL MASTERY SCORECARD
We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.
Take The TestIf you liked this article, feel free to visit my company Products and Services pages.
We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.
With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.
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 😀 😀
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
I tried some of the retrospectives from this website. It really worked. Thanks.