Agile Retrospective
An Agile retrospective is a meeting that's held at the end of an iteration / sprint in Agile software development (ASD ). During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward.
During the retrospective, each member of the team members answers the following questions:
- What worked well for us?
- What did not work well for us?
- What actions can we take to improve our process going forward?
The Agile retrospective can be thought of as a "lessons learned" meeting. The team reflects on how everything went and then decides what changes they want to make in the next iteration / sprint.
An atmosphere of honesty and trust is needed in order for every member to feel comfortable sharing their thoughts. Norman Kerth's work at the turn of the millennium was highly important to the development of Agile retrospectives and retrospectives in general. Kerth's prime directive states, "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
A framework, such as the one below, can be used to provide structure and keep discussion during the retrospective focused.
- Set the stage - get the team ready to engage in the retrospective, perhaps with a warm-up activity such as Plus, Minus, Interesting (PMI) (5 minutes)
- Gather data - create a shared picture of what happened during the retrospective (10 minutes)
- Generate insights - discuss what was successful and identify any roadblocks to success (10 minutes)
- Decide what to do - identify highest priority items to work on and put measurable goals on those items so they can be completed (15 minutes)
- Close the retrospective - reflect on the retrospective and how to improve it, and to appreciate accomplishments of the team and individual interactions (5 minutes)
Why would you do retrospectives?
Insanity is doing the same things and expecting different results. So if you want to solve the problems that you are having, and deliver more value to your customers, you have to change the way you do your work. That is why agile promotes the usage of retrospectives: To help teams to solve problems and improve themselves!
What makes retrospectives different, and what’s the benefit of doing them?
One retrospective benefit is that they give power to the team. Since the team members feel empowered, there will be little resistance to do the changes that need to be done.
What are the benefits of Agile Retrospective meetings?
In software development, identifiying types of waste can be relevant as below,
- Unnecessary or Partial features — Change in requirement causes certain piece of software become unusable. Sometimes unclear requirements results in partial features and mostly results in garbage.
- Dependencies between features — New features are always built on top existing ones or considering integration with other features. Any delay in integration puts someone on waiting and adds to overall development time.
- Multiple testing and review cycles — Each feature requires testing and review before going into production, if a testing & review cycle can combine multiple features, it can save huge amount of time.
- Bugs/Defects — I guess it does not need any explanation
Thanks to agile development practices and ‘retrospectives’ in particular these wastes can be disposed off very easily. An agile retrospective, or sprint retrospective as Scrum calls it, is a practice used by teams to reflect on their way of working, and to continuously become better in what they do.
References:
What is Agile retrospective?
What's an Agile Retrospective and Why Would You Do It?
An Agile retrospective is a key meeting in Agile project management IEEE projects for cse
ReplyDelete, specifically within Scrum and other Agile frameworks. The purpose of the retrospective is to reflect on the recently completed iteration (sprint) and identify ways to improve processes, teamwork, and overall project delivery. It’s a chance for the team final year projects for computer science
to review what went well, what didn’t, and how they can enhance their performance moving forward.