One of the most useful tools in the agile development arsenal is the process of a sprint retrospective.
The simple idea of a sprint retrospective is to review the product backlog and do any changes the team need to in order to keep the project on track. The sprint retrospective according to the authors of “Agile for Dummies” Scott W. Ambler and Matthew Holitza, they see a retrospective as a team progress check up. A check up where the team can meet up by themselves or with useful stakeholders to go over
any issues in the latest sprint and figure a game plan to tackle the issues discovered in the upcoming sprint (p. 32). The key thing to note is that the sprint retrospective is a learning tool and aids in product flow.
Using a sprint retrospective as a learning tool for any agile team is an imperative resource that teams should not neglect. The sprint retrospective is not something that a development team should be scared of. The team should be looking froward towards the retrospective during the sprint since this allows the whole team to reflect on the past sprint. It is a good place for a team to be in knowing what they still have to do, what they need to change product flow wise and bring up personal issues a team member might be having with a project. A problem with bringing up personal problems, noted in “Decision Making in Agile Development: A Focus Group Study of Decisions & Obstacles” by Meghann Drury, Kieran Conboy and Ken Powers, is that they found people can use a retrospective as a way to vent about the project. Drury, Conboy and Powers in their interviews look at some team member found the meeting to be chaotic.
Dev8D Retrospective by Steve Coppin
These members felt the retrospective would end up not directing the team down the path of completing the project (pp. 44-45). Venting problems with a project maybe use full only if those issues can help move the project forward, otherwise it can affect the team from tackling design issues. To drive this point home by the end of a given retrospective meeting there should be an idea of how to move the project forward. The diagram ”Dev8D Retrospective” from Steve Coppin, shows one lay out of how to represent information brought about in a retrospective. The diagram brings up four areas of different comments.
- What did we do well
- What didn’t go so well
- What could we do differently
- what still puzzles us
A team able to bring up issues in the project in those four areas can then start to develop ways of correcting problem and complementing good deeds the team was able to accomplish.
A good retrospective does a lot to move the project along and as not early should not be feared by the team. Any team will want to embrace all the negative and positive information coming from a retrospective as long as it can help progress the project.
Reference
Ambler, S., & Holitza, M. (2012). Choosing an Agile Approach. In Agile for Dummies (IBM ed., p. 74). Hoboken: John Wiley & Sons.
Coppin, S. (2010) Dev8D Retrospective [Diagram] Retrieved September 28, 2014 from http://blogs.kent.ac.uk/agile/2010/03/04/dev8d-retrospective/
Drury, M., Conboy, K., & Power, K. (2011). Decision Making in Agile Development: A Focus Group Study of Decisions & Obstacles. 2011 Agile Conference, 39-47. Retrieved September 28, 2014, from IEEE Xplore. Web Address. http://ieeexplore.ieee.org.libaccess.sjlibrary.org/stamp/stamp.jsp?tp=&arnumber=6005504
Wesley Eversole's ConNeTech 
Your description on the sprint retrospective describes it as a checkup. It will help the group to look at mistakes or shortcoming and discover any issues for upcoming sprint. You also mentioned that it can be taken into account as a learning tool. This is a great point since the feedback can be very constructive. I also like the fourth category you have in the list of your focus topics, what still puzzles us. In the development environment, even after having a sprint or two, there can be some vagueness in the details of the backlog and possibly the processes to follow for ending a successful sprint.
LikeLike
This is a pretty good basic understanding of what a Sprint Retrospection is and why it is important. Although, maybe my eyes are tired, there are a few sentence issues that take away from the reading of the blog. A few examples that can be cleaned up: “A problem with bringing up personal problems” (maybe “an issue with bringing up personal problems”), “A good retrospective does a lot to move the project along and as not early should not be feared by the team” (sounds a little awkward). If these few issues were to be cleaned up the blog would shine.
LikeLike
This is very good blog. Wesley, you have used very simple language which everyone can understand. You have included the importance of the Sprint retrospective which was the main point of this blog. I still saw some unclear point in your blog about sprint retrospective which you can clear up. You can mention more about how feedback plays role into the sprint retrospective. It is very important part of the sprint retrospective to collect feedback.
LikeLike
The description for Agile Sprint Retrospective is very detailed and properly organized plus good use of references. I like the way you used the image and its four outcomes. I liked lotheren’s opinion about cleaning up few examples that can be cleaned up. I also liked the way you explained further about team progress checkup.
LikeLike