The Software Process and Measurement Cast 265 features our essay on retrospectives. Retrospectives are part of most methodologies, even though there are many different terms. For instance, most waterfall frameworks call them post implementation reviews or postmortems. And each methodology focuses on different nuances. Agile, as a macro set of frameworks, has more aggressively embraced retrospectives than waterfall or iterative frameworks. Retrospectives in Agile reflect the adoption of the principle of kaizen (Japanese for improvement, often interpreted as continuous improvement). They should be focused on discovering what will make the team or organization deliver more value. While many retrospective techniques posit the questions “what worked well” and “what did not work,” the real reason to do any retrospective is to identify, agree on and plan for what can be done better. The exact process any team uses is a reflection of the technique the team wants to use, what works in the organization and the specific team situation. For example, the timing of retrospectives varies significantly depending on the framework and the organizational culture. Most waterfall projects do a retrospective at the end of the project (or release), while Agile projects typically do retrospectives at the end of every sprint, at each release, at the end of the project and occasionally on an as needed basis. In Agile, retrospectives occur when change can actually be applied to the project to impact the current delivery.
Posted on: Sun, 24 Nov 2013 22:00:49 +0000
Trending Topics
Recently Viewed Topics
© 2015