Retrospectives can potentially
be one of the most beneficial tools in software development; then again
most retrospectives I’ve participated in where a complete waste of
time…
The idea of a retrospective, or postmortem as we called them about 10 years ago, is simple. At the end of the project take the time to define 3 things:
1. What went right and should be kept?
2. What went wrong and should be changed?
3. How to make things better the next time around?
So, how come most projects either don’t perform retrospectives, or carry out postmortems but don’t learn from them and keep doing things in the same unproductive way?
The answer to the first part of the question comes from the statement behind the second part. If a Manager “tries” doing retrospectives on a couple of projects and doesn’t get any added value, why should she continue doing them?
I think the problem is not with the concept of the Retrospective, but with how it is carried out in many Organizations and what is done with the results that come out of it.
There are a number of recurring mistakes and wrong-doings that can be seen in most postmortem failures:
1. Lack of Manager Leadership – If Senior Managers don’t give retrospectives their full attention and don’t communicate (using personal example) their importance, then middle management and the rest of the team will not treat these activities seriously.
Postmortems need to be lead by someone with authority and charisma; this is the only way to successfully guide the team through the complex process of reviewing, analyzing and learning from past activities and results.
2. Not gathering issues and facts throughout the project – Bad retrospectives focus mostly on the issues that happened during the last legs of the process, since these are the things we remember better and the ones that still have an emotional effect in most of us.
It is very hard to keep track of issues if we don’t record them when they happen, and it is even harder to analyze them if we don’t have objective data. The Project or Team manager needs to find ways to record important issues when they happen, and store information that will help the team understand how and why they took place.
A good idea I got from a Group several years ago was to create an e-mail alias that people could send important issues as they happened. At the end of the project the team running the retrospective can use these e-mails as a starting point for their process.
3. Letting postmortems turn into Witch Hunts – In some Young Organizations or after a very stressful project a postmortem can easily turn into a personal Witch Hunt. The most effective way to stop this from happening is by not letting it start in the first place.
If during the analysis and discussion process the team starts taking the subject into personal tones and levels, it is the job of the Manager to stop this on-the-spot and to turn the subject to a solely constructive and impersonal discussion. If necessary she should make a time-out or call a recession until people have a chance to cool down.
4. Lack of clear Lessons Learned, Action Items and Follow-through Plan – The big mistake of creating a large list of things to improve and yet continue working in the same way…Improvement doesn’t happen by itself, it needs to be pushed by people who keep track of the unwanted behavior and constantly make an effort to correct it.
A good practice is to focus on only 3 things to improve from each retrospective, and then during the following project to implement a way to measure these 3 things and constantly track their improvement.
I personally like to take my targeted improvements and start reviewing them on the weekly (or periodical) management and team meetings, 10 minutes before each meeting and 2 minutes during the meeting itself is usually enough to ensure these action items stay in-mind and on-track.
Last but not least, as I was looking more material for this article I found something really amazing from a group of people I was not taking seriously enough. The Game Development Industry, or at least the New Engineers specializing in this area have been using and publicly posting their retrospectives more than any other groups that I know of. I suggest you take the time to review this site, and learn both from the way the can seriously analyze their wins and mistakes; you might even read something that can be leveraged to your team or project.
http://qablog.practitest.com/2008/07/good-project-retrospectives/
The idea of a retrospective, or postmortem as we called them about 10 years ago, is simple. At the end of the project take the time to define 3 things:
1. What went right and should be kept?
2. What went wrong and should be changed?
3. How to make things better the next time around?
So, how come most projects either don’t perform retrospectives, or carry out postmortems but don’t learn from them and keep doing things in the same unproductive way?
The answer to the first part of the question comes from the statement behind the second part. If a Manager “tries” doing retrospectives on a couple of projects and doesn’t get any added value, why should she continue doing them?
I think the problem is not with the concept of the Retrospective, but with how it is carried out in many Organizations and what is done with the results that come out of it.
There are a number of recurring mistakes and wrong-doings that can be seen in most postmortem failures:
1. Lack of Manager Leadership – If Senior Managers don’t give retrospectives their full attention and don’t communicate (using personal example) their importance, then middle management and the rest of the team will not treat these activities seriously.
Postmortems need to be lead by someone with authority and charisma; this is the only way to successfully guide the team through the complex process of reviewing, analyzing and learning from past activities and results.
2. Not gathering issues and facts throughout the project – Bad retrospectives focus mostly on the issues that happened during the last legs of the process, since these are the things we remember better and the ones that still have an emotional effect in most of us.
It is very hard to keep track of issues if we don’t record them when they happen, and it is even harder to analyze them if we don’t have objective data. The Project or Team manager needs to find ways to record important issues when they happen, and store information that will help the team understand how and why they took place.
A good idea I got from a Group several years ago was to create an e-mail alias that people could send important issues as they happened. At the end of the project the team running the retrospective can use these e-mails as a starting point for their process.
3. Letting postmortems turn into Witch Hunts – In some Young Organizations or after a very stressful project a postmortem can easily turn into a personal Witch Hunt. The most effective way to stop this from happening is by not letting it start in the first place.
If during the analysis and discussion process the team starts taking the subject into personal tones and levels, it is the job of the Manager to stop this on-the-spot and to turn the subject to a solely constructive and impersonal discussion. If necessary she should make a time-out or call a recession until people have a chance to cool down.
4. Lack of clear Lessons Learned, Action Items and Follow-through Plan – The big mistake of creating a large list of things to improve and yet continue working in the same way…Improvement doesn’t happen by itself, it needs to be pushed by people who keep track of the unwanted behavior and constantly make an effort to correct it.
A good practice is to focus on only 3 things to improve from each retrospective, and then during the following project to implement a way to measure these 3 things and constantly track their improvement.
I personally like to take my targeted improvements and start reviewing them on the weekly (or periodical) management and team meetings, 10 minutes before each meeting and 2 minutes during the meeting itself is usually enough to ensure these action items stay in-mind and on-track.
Last but not least, as I was looking more material for this article I found something really amazing from a group of people I was not taking seriously enough. The Game Development Industry, or at least the New Engineers specializing in this area have been using and publicly posting their retrospectives more than any other groups that I know of. I suggest you take the time to review this site, and learn both from the way the can seriously analyze their wins and mistakes; you might even read something that can be leveraged to your team or project.
http://qablog.practitest.com/2008/07/good-project-retrospectives/
No hay comentarios.:
Publicar un comentario