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.
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.
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