Tuesday, October 14, 2014

In Retrospective

A retrospective is a meeting at the end of an iteration where the team gets together and discusses what worked, what didn't, what could be done to improve. It's pretty standard faire. Perhaps there may be a danger in deciding too many things at the retrospective, where there isn't necessarily time for everyone involved to truly think on any of the issues discussed or to truly understand any of the ideas for improvement that have been proposed. It could prove beneficial to revisit some of what was discussed before implementing any serious changes to process. If you have a well defined process in the first place it will be documented in a clear and concise way with proper change management protocols built in. I recommend creating a single document that has a diagram and supplemental text that describes the process at a level which would rarely change. There is a balance between the level of detail in the process definition and maintenance costs/usefulness. Unless you need the extra detail due to regulations, keep it simple enough so that it won't need constant maintenance for every nuance of change, but include enough detail so that everyone knows who does what, when and sometimes how. The how should be describes separately from the process document. If you are using standard procedures, just call them out by name or link to the doc or both. For example: A release process could be defined as follows: The release should have a release coordinator, a release engineer, other technical parties, and a qa engineer. A pre-production meeting should be held before the release and should cover what is going and when, the schedule should be reviewed and everyone should have a copy of the schedule. The coordinator should set up a meeting during the release and communicate to all parties involved throughout the release. The coordinator shall communicate to all external parties according to the release schedule. Etc... This should also be diagrammed with definitions for each role and domain specific terminology or link to such a glossary.

No comments:

Post a Comment