I'm a big fun of learning on own mistakes. I hate making the same mistake again. It makes me feel really bad. Repeating the mistake again can be a sign of lack of care for the end result. If one does care then he or she would mind to avoid running into the same problem twice. Sometimes we repeat our errors because of short memory. In this case I would suggest keep records of what went wrong and to buid a reliable guard against mistakes by changing the way we do things daily.
Same is for the process. Post mortem or retrospective reviews help remembering what went wrong on a project and give you insights what steps to take in order to avoid running into the same problem again in future. Just a look back may make a big difference in the way we do things. This is why I like it so much. With almost no efforts it provides plenty of ideas on possible changes. Here is the list of questions that I would ask to everyone who has been involved into the project:
1. What was good about the project?
2. What could be done better and how?
3. What was bad and how to avoid it in the future?
It also helps if you direct people thinking into concrete direction with questionnaire designed to elicit more details on the problems:
1. Did all the stakeholders have the same meaning of project goal?
2. Was documentation sufficient and clear?
3. Was system design profound enough? Did it make coding easier?
4. Did architecture help building a quality system?
5. Was change controlling mechanism effective?
6. Was the testing adequate?
7. Are you happy with defect tracking process?
8. Is the resulting product easy to support?
9. Was the planning accurate enough?
The list of possible questions can go on and on. This is up to you to decide if to mess with it. Every project is unique in the way things went wrong. Every team is unique in the way it fails. So, there is no universal list of questions. If one would try building it, it would be too general or too long. I recommend such list only for the beginning or to address a specific problem of retrospective review process (for example, people may tend skipping one of the processes from consideration).
The best way to generate list of improvements is to look back on the whole process from the very beginning step by step. Play it back from the moment you first heard about new product till the moment a release was sent out to end users.
It was always interesting to me how a retrospective look changes how thing look like. Some issues are being noted only if the whole process is played back. Thos thing may not even look like problems when you face them in day-to-day work. Sometimes we need the context that is yet to come to validate the decision we are making today.
Another very interesting effect is having issues indentified when you look at the whole process on a high level of abstraction. Thing that eat up several minutes a day may start looking not as negligible when assessed in perspective of several months of execution by ten people.
Do not let yourself fall a prey of excessive self-confidence. Your team may learn from mistakes as well as it may not. Make this process defined and visible. Share the ideas, implement the changes to the process and forget about the issues forever. This is much more reliable and natural than relying on everyone's personal memory.
No comments:
Post a Comment