Thuật ngữ Retrospectives trong Agile là gì? Luyện thi PMI-ACP
Retrospectives is an Agile process for self-evaluation (similar to a “postmortem” meeting or “lessons learned” meeting in traditional project management) by the Agile development team only to analyze, adapt and improve the entire Agile development performance – a learning opportunity for the Agile team and the project to improve productivity, capability, quality and capacity
Lessons learned are to be implemented by the Agile team right in the next iteration for instant improvements – a continuous process improvement for timely implementation
To be performed at the end of each iteration (usually once per month, or every week or two) with all development team members only for up to 1 hour
Focus on what went well, what went wrong and how the team can improve in next iteration and beyond without finger-pointing:
- Set the stage – get people comfortable to speak and outline the topics for discussion
- Check-in – everyone express in 1 or 2 words about the expectation of the retrospective
- Focus on / focus off – which side to focus on (e.g. dialogue vs debate)
- ESVP – choose 1 from among “explorers, shoppers, vacationers and prisoners” that describes their feeling anonymously
- Working agreements – work on different topics in small groups first
- Gather data
- Generate insights
- Decide what to do – identify the high priority items to devise an action plan
- Close the retrospective – express appreciation and feelings
- Plus / Delta – what should be done more / what should be changed
- Helped, Hindered, Hypothesis – three flip charts for participants to add ideas on
- The chosen improvement stories will be put in the non-functional backlog to be carried out by the whole team to improve Agile processes
- Support the growth of the self-directed team for enhanced performance
- Retrospective Meeting vs Review Meeting
- Retrospective meeting is for the development team only with the primary aim for process improvement
- Review meeting is for demonstration / getting acceptance of deliverables with management, product owner and stakeholders, backlog item(s) may be identified for the next iteration
- Retrospective Meeting vs Lessons Learned Meeting
- Retrospective meeting is carried out once per iteration and identifies one area for improvement
- Lessons Learned meeting is carried out at the end of the project / phrase as the project closure activity and all the lessons learned are to be identified and documented (according to PMBOK® Guide)
SCRUM – SPRINT RETROSPECTIVE MEETING
After the Sprint Review meeting took place the Scrum Team and the Scrum Master get together for the Sprint Retrospective. In this meeting all team members reflect on the past sprint and check three things: what went well during the sprint, what didn’t, and what improvements could be made in the next sprint. The meeting should be time-boxed (e.g. 3 hours).
The Sprint Retrospective is an integral part of the “inspect and adapt” process. Without this meeting the team will never be able to improve their overall output and cannot focus on the overall team performance. Therefore actionable suggestions to improve performance should be available at the end of the meeting.
DO WE NEED SPRINT RETROSPECTIVE MEETING FOR EVERY SPRINT?
If you go back to the article on Scrum Meetings one of the regular meetings that is expected to happen every Iteration or Sprint is the Retrospective Meeting. However, in real life scrum projects, many people actually skip the regular retrospective meetings for a variety of reasons (we will get to that in a bit) and just continue working on the project. The purpose of this article is to help you decide whether your scrum team (or Project) requires a retrospective meeting at the end of each sprint.
Reasons Scrum Teams Give – For Skipping Retrospective:
Whenever we talk about doing a retrospective at the end of the sprint, one or more members of the scrum team may have some reasons or should I say excuses as to why a retrospective isn’t needed. Some of the popular reasons include:
- They are boring, nothing fruitful comes out of these meetings
- We have real work and cannot waste time in such meetings
- We are very good and have delivered a lot of story points in this iteration. So, can we skip it?
If you have been a Scrum Master, chances are that you would’ve heard either of these or maybe some more reasons on why they want to miss the retrospective.
Are Retrospectives Really Boring?
A retrospective meeting isn’t one of those meetings that gets everyone excited. Nobody likes to look back in time to figure out how things could’ve been done better. This is where the role of the scrum master comes in. The scrum master needs to the keep the discussion focussed and not become a finger pointing blame game. The scrum master should mix things up by asking a different team member to facilitate the retrospective every time and so on. The next article will cover the topic about how a Scrum master can run an effective retrospective meeting but you get the picture right?
Can a Team be too busy for Retrospectives?
Retrospective meetings are part of the work or job description for a team that is doing scrum projects. Realistically speaking Yes, there may be a few instances where the team could be really busy like toward the end of the release (Last iteration) and people are scrambling through to get the last few bugs fixed. During these situations a smart scrum master would wait until the tight deadline related activities are done and then schedule the retrospective.
Have you heard of the story of the woodcutter who took up a job in a log house?
A very strong young man took up the job of a wood cutter in the local log house. He was big and strong and could easily crack a log in two with a single blow of his axe. During the initial few days the log house owner was quite impressed with his ability and saw that he finished up his pile of logs fairly easily. As days went by, even though the guy was as strong as he was before, he took more and more time to finish his job. The same log that broke in two with a single shot now needed three or four shots each. No matter how hard he hit the log, it would still not give in.
Can you think of a reason why?
The young man, too busy in his quest to finish his work quickly, kept pounding away on the logs without thinking about whether the blade of his axe was still sharp as before. He is still the same but his axe has worn out due to the continual use and if he had spent maybe 15 or 30 mins every week to sharpen his axe, his efficiency wouldn’t have come down.
Yes, cutting logs is his job and sharpening the axe may be considered a low-value activity but if you think about it, this 15 or 30 min sharpening will ensure that he is able to continue his output with the same level of efficiency.
Get the picture? This is what Retrospetive does for your Scrum team. This 1 hour you spend every sprint will help your team identify improvements and work towards them.
Can a Team be Too Good for Retrospectives?
Yes, this is a very real possibility but even teams that have been doing scrum for many years still spend a few hours regularly to do retrospective because you will always be able to identify ways to improve. It is highly unlikely that the team is so good that, there are no further improvements either to be identified or worth implementing.
Some Last Words:
One of the key aspects of Scrum is the ability of the team to inspect and adapt. This by definition means that we regularly introspect and understand areas that we are doing good/bad and continue on the good ones and improve on the bad ones. Having the Retrospective Meeting is the disciplined approach for the same.
The retrospective meeting gives the team an opportunity to inspect what went well/not so well in the last sprint and make adjustments. This is crucial in any scrum team and is not one of the meetings you can skip. Even if your team is resisting to the idea of doing frequent retrospectives (like in a team with 1 week Sprints), you should try to schedule periodic retrospectives at least every 2-3 iterations to make sure the team can polish their axe and avoid slowing down.
What is your take on retrospective meetings? Sound off on the comments section for the benefit of the others….
HOW TO RUN AN EFFECTIVE RETROSPECTIVE MEETING
We talked about why it’s a good idea to do a retrospective regularly – right? I had mentioned in that article that we will be having a separate article to talk about how to conduct effective Retrospective meetings that are productive and add value to the scrum team/project.
Before we get into conducting or running a retrospective, there are a couple of prerequisites or like I tell my team, there are two important ground rules that we need to follow.
Rule 1: No Management Team in Retrospective
Even though Scrum advocates that the scrum team shouldn’t have any roles like a lead or manager, it is very difficult in real life to run an organization without people managers. The Retrospective is supposed to be an open discussion where people can share their opinion and ideas freely. The presence of someone from the management team is a very big detriment to an open discussion.
As Scrum Master it is our responsibility to ensure the meeting is productive and does not get impacted due to the presence of the management team.
Real life trivia: The senior management team may suggest to you that, their presence will give them an insight into the mindset of the team or get to hear first-hand their suggestions. But, trust me – their presence will only result in the team being more cautious and reserved about what they are going to say and end up missing vital improvement points. One of your scrum team members may feel that senior management isn’t supportive enough on the project initiative and keep pulling out members to work on adhoc assignments which is impacting team velocity. But, if someone from senior management is present in the meeting, do you think he/she will be willing to say that point out loud? Even if management team members promise to keep an open mind and not be judgmental of the team, the fear factor will always linger in the teams mind and will result in pointless retrospective discussions.
So, what if your Management Team insists on attending the meeting?
As Scrum Master, there are a couple of things you can do:
- Educate the members of Management that their presence results in people being more reserved and isn’t resulting in effective discussion
- Explain to the members of the Management that, you will eventually collate all the improvement/feedback points and as representative of the scrum team, you will bring all those points to their attention/review
Every member of the management team would be interested in understanding how they can help the scrum team/project and if you help them understand that their presence is causing a problem, most likely they will listen. More importantly, if you are committing to share the suggestions with them, they don’t have the need to actually attend the meeting personally – isn’t it?
Rule 2: No Finger Pointing or Blaming during Retrospective
This again is a very important ground rule that I try to enforce during my retrospectives. When we are blamed for some mishap, it is natural human tendency to become defensive and try to refute the allegation and defend ourselves. When one member of the team points a finger at another and blames them for some mistake, the discussion deviates into the more of a personal attack territory which is firstly unwarranted and secondly uncomfortable for all parties in the meeting.
I always try to keep the discussion from getting into that territory and all team members are encouraged to share their points without pointing fingers at other members of the project team.
Bonus Rule: Full Attendance
This one is a no brainer. In order to collect feedback from all members of the team, I try to schedule the retrospective on a day that the entire team is present. Of course, unplanned sick leaves are unavoidable but usually I schedule the meeting and request all participants (including product owner) to attend the session.
Running a Good Retrospective
Ok, coming back to the topic at hand of running a good retrospective, I try to follow the simple/tried & tested – Start/Stop/Continue Approach.
I like to run the retrospective by asking team members what would they like to Start, Stop and Continue doing. Each team member takes turns and suggests points that they think the team should start or stop or continue doing – plain and simple.
Some examples could be :
- We should start doing code reviews to improve code quality
- We should continue to have a quick demo with the product owner after we finish story development and before the full-fledged testing of the story starts
- We should all start showing up on time for stand-ups
- We shouldn’t start work on a story or task until the current assigned task/story is completed
- And so on…
You may be wondering – what will go under the Continue option?
Usually, new ideas that go under the start category must be checked for their effectiveness in the subsequent retrospectives and if the team feels the idea was good, they can reiterate the same by including the point under the Continue category. After a couple of sprints if the team is habitually following the suggestion, we no longer need to include that point in the continue section as well.
Spice Things up
Sometimes, this start/stop/continue may become too monotonous if we do the same thing again and again. Team may feel the meetings are becoming boring. You may think of ideas to spice things up.
We could do things like – pass a stick pad bundle to all participants and ask them to write their suggestions, fold up their point and put it in a basket. After 30 mins, we start taking out one item at a time and the team can discuss on the point. Or you could ask a different member of the team to run the meeting every week so they too understand the tricks of the trade.
Or, we could document all the key takeaways from the retrospective and start off the next sprint retrospective by looking at these points and evaluating if we have really worked on the improvement items. in my projects, I document the sprint wise retrospective findings in a wiki and we review the previous weeks improvement points and assess where we are before we add more entries to the list. This way the team understands that you as the scrum master are serious and aren’t doing this to just tick off one of the recommended meetings list.
Some last words:
I personally find that this start/stop/continue method is fast, easy and effective way to run a retrospective. By not associating any names and focusing only on actions, we don’t waste our time on feelings. We don’t need to worry about whether team members are happy or sad – we just focus on work.
Each item we document will directly result in change in the way we work. The team will start doing newer or better things, they will stop low value activities and continue to strive towards being a better team as a whole. That’s the point behind the whole retrospective meeting isn’t it?
Nếu có bất cứ chia sẻ về luyện thi PMP, PMI-RMP, PMI-ACP hay góp ý bạn vui lòng chia sẻ ở dưới phần bình luận. Tôi rất vui lòng về điều đó. Cảm ơn.