How should work be reviewed and considered as worthy to publish or put into production? Engineering teams building products need to have processes for review and approval. On student teams, these standards may be unclear. In a professional setting, there are a few major patterns with the most important artifacts like code and externally-facing documentation going through established processes. But smaller artifacts like internal documentation or minor designs might not. In every setting, it is valuable to have agreement within the team about what the review and approval standards are. Misunderstandings about approval systems are common especially within student teams and can be easily prevented with early discussion.
1. Consensus: Some teams may wish to have consensus among all members before making any significant decision. This is typically unrealistic and violates the principle of unity of ownership. Someone must own the ultimate choice and be responsible for its implementation. Even after everyone has had the opportunity to raise their arguments for and against each design option, some may be unpersuaded. There might be insufficient funding or time to test each option and a singular decision may be necessary (a “one-way door decision”).
Some may believe that consensus is the default approval mechanism. While it may be possible on student projects in which the stakes are lower, it should be avoided in favor of subdividing ownership and adopting a different approval system for each component.
2. Majority: Others may wish to have major questions decided by majority vote. This also violates the principle of unity of ownership, because no artifact is owned by the majority but instead by specific contributors. In student teams without a clear leader or manager, this may seem attractive as alternative to Consensus in the face of one or two persistently dissenting voices, but does not resolve the core problem of ownership of specific components.
3. Reviewer Pattern: An implementer or author creates an artifact and must get agreement from others for it to be considered valid for promotion. This is typical for code artifacts which should require at least one other developer before being put into the testing and deployment pipeline. The implementer owns the solution, but the reviewer owns the examination of it and making sure it follows team standards. The implementer owns the incorporation of feedback from the reviewer. The reviewer still controls its final approval.
4. Commentator Pattern: An author creates an artifact and solicits feedback from others, but addressing this feedback is not considered mandatory for promotion or publication of it. This is faster than the Reviewer Pattern, but usually does not achieve the same level of quality control. The Commentator pattern is more common for some kinds of internal documentation.
5. Retroactive Audit: Decisions are recorded and available for future review by the team. This maintains accountability while allowing individuals to make quick decisions. Small purchases and rapid prototyping benefit from high speed and retroactive auditability instead of proactive review.
For example, when preparing a group presentation, how should it be reviewed? The common practice is to give certain slides to specific people. But does that contributor have the final decision on that content? This should be discussed within the team at the beginning of the preparation of the presentation. If the presentation requires some consistency of content, then it might be valuable to make the Reviewer Pattern explicit at the beginning. If this isn’t clear, and one contributor’s artifacts come under criticism from the rest of the team, then that person may feel unfairly targeted and undermined if he implicitly believed the Commentator Pattern was being used. If the common understanding is that everyone’s slides need to be approved by at least one other person, then that minimizes the chance of frustration.
Clarity of approval patterns further improves team cohesion.
Mike's Engineering Blog 