– retrospective – audit – reviews, generally – code review – sign off / approvals – training sessions – presentations
Also, Post IMplementation Review
Retrospectives and Post-Implementation Reviews also allow you to check your results after the fact, allowing you to learn lessons about how to prioritise and how much to prioritise.
After any activity, you can perform a retrospective. Level of formality may vary.
Post Incident Review
decision making processes, ego
(See also review, code review)
Sign-Offs are used in Waterfall after each stage.
Sign-Offs are actually a de-risking process in two ways.
First, they allow you to Meet Reality: taking the results of the Specification stage, and putting it in front of a group of stakeholders gives the people on the project a chance to check their Internal Model against those of other groups, be they users or sponsors of the project.
Second, they allow lots of people to be involved in an approval, or a decision process. Extreme Programming has a single On Site Customer, and can get unweildy when you have mulitple products and multiple owners within the same team. This problem is not solved by a sign-off process, but is mitigated to some extent.
Third, they provide a written record that something was agreed. This is useful because:
Usually, it’s hard to get sign-offs. This is because it’s hard to get lots of people to agree on anything. The process often involves several walkthroughs, and iterations until everyone is happy. Sadly, in order to bring people on board, the iterations usually involve adding more complexity to the project, rather than reducing it, which has the effect of actually increasing risk.
## Code Review
slowed down by bureaucratic risk
Helps solve Disenfranchisement problems
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.