I have already stressed numerous times already that Agile contains many mechanisms that stress the importance of flexibility and change. One of these mechanisms, the sprint retrospective, is worth looking into a little more deeply due to the positive impact it has upon the development processes.
In essence, the sprint retrospective is a time for the team to identify things from the previous sprint that are either less than ideal and need to be improved or that are good and should be done more often. A time for constructive critique and praise in order to improve the productivity and results of the next sprint. Chris Mann and Frank Maurer have done an extensive study on opinions regarding the Agile process as a whole and found that the sprint retrospective is generally given praise by developers that utilize the Agile methodology. However, Mann and Maurer found in their study that there is one critique that the developers have regarding the conciseness of the meeting: They often find that the client, scrum master, and project-manager tend to be under-prepared for the meeting and veer off the topic, which causes meetings to drag on. I feel that I must second this critique as someone who works in software testing. Meetings with developers and project managers tend to get sidetracked when the two go off on long tangents discussing possible features they can add to the software in future versions, I find it necessary to reel them back into the primary discussion topic from time to time, a relatively simple fix to the issue.
Something people new to agile tend to get confused about is what kind of topics should be discussed during the sprint retrospective. Allow me to clarify this for the reader; the retrospective is all about the details of the process itself that need to be improved rather than features and bugs, those topics are reserved for the preceding the sprint review. A good example of such a topic is found in Mann and Maurer’s study; during one of the retrospective meetings the clients and developers agreed that they would no longer do extended sprints when they found that they needed more time to complete a task. They’re rationale for this was that the developers would end up not knowing what they needed to do and they agreed to instead either trim down the work or move it to the next sprint.
Once again we can see that agile gives developers a way to refine the process by which they create quality software and optimize their productivity. Critique and praise of the processes being used is important, not all teams function identically and it is therefore important to be critical of what processes are working in any given project. The retrospective is the time for teams to facilitate this critique at the end of each meeting.
Mahnic, V. (2011). A Case Study on Agile Estimating and Planning using Scrum. Electronics and Electrical
Engineering, 5(111), 123-128. Retrieved September 29, 2014, from http://ecoman.ktu.lt/index.php/elt/article/download/372/318
Mann, C., & Maurer, F. (2005). A Case Study on the Impact of Scrum on Overtime and Customer Satisfaction. Agile
Conference, 2005. Proceedings, 70-79. Retrieved September 28, 2014, from http://ase.cpsc.ucalgary.ca/uploads/Publications/MannMaurerAU2005.pdf
Retrospective Table [Image]. (2013). Retrieved Sepetember 28, 2014,
Thumbs Up & Down [Image]. (2013). Retrieved Sepetember 28, 2014, from: http://blog.roblox.com/wp