Agile Software Development

Project evaluations (or retrospectives) are a nuisance. Everybody knows they are important, but nobody performs them. With at least ten new projects starting every week in our company, how can I instruct our people to get all project stakeholders together (in ten different settings) and construct a "lessons learned" list of the ten projects that were delivered the week before? Nobody is available for such meetings because they are all too busy making sure the new projects are initiated properly. Sure, this is no excuse. But it is reality.

Automate the Process
To get around this problem I have decided to automate the evaluation process.

This morning I was looking over several of our project backlogs and noticed something that really caught my attention. In addition to user stories that addressed the functionality we are developing, our project teams have been adding stories to the backlog that have nothing to do with project tasks (or maybe they have everything to do with project tasks). The stories are about improving processes and practices, organizational issues, team matters, and even the project structure.

Retrospectives initially were not a part of Scrum at all. There was supposed to be a retrospective part during the sprint review. Over the time it evolved into two separate sections: Sprint Review focused on what and Sprint Retrospective focused on how.

Every agile software development process by definition requires periodical retrospectives in order to pause, have a look at the current practices and improve the way of working. There are two kinds of retrospectives: major retrospectives that happen at the product release or major milestone and minor retrospectives that are carried out at the end of iteration.

Iteration retrospectives

Iteration retrospectives are carried out at the end of the every iteration. The main goal is the daily habits improvement. By discussing of what went wrong, what went well team gets a chance to share the individual observations, aid daily problems and eventually grow as a constantly improving team. Not to loose the power of periodic retrospection it is very important for an iteration retrospective to result in a specific set of changes. Reviewing own work takes emotional energy and people would not be willing to invest it if it won’t result in a visible outcome.