2007/10/01
We have started to use a form of informal reviews in project team and so far it has given quite positive results.
The main purpose why we decided to try out this practice is because due to the nature of our project it wasn't possible for multiple people to work on closely related tasks. Hence the typical knowledge sharing related to team members having related everyday tasks wasn't very effective. However thanks to these reviews we have been able to increase overlapping of knowledge areas of the project. This has allowed us to do more task switching so that people can work some time on one server and when that gets boring switch to doing stuff on some other server. As a byproduct we have probably also increased the quality of our work results.
We have following basic rules for executing these reviews:
- there is no single reviewer - everyone can do reviews
- if someone finishes a task he will mark it as "Resolved" in Jira and if he wants he can ask someone particular to review it or just leave it in the "To be reviewed" pool
- keep the "To be reviewed" pool as small as possible at all times
- reviews can be done together so that the reviewed explains what he has done or in case of simple tasks reviewer can just do it alone and ask questions if needed
- all tasks are reviewed. That includes non-implementation tasks like writing documentation or installing some new tool to testing server
- in case of really trivial tasks the team can decide that no review is needed
- finally and most importantly review is not assessment of someone's knowledge but a possibility for both parties to learn something
In projects where knowledge sharing is happening naturally through dependencies between different tasks this practice might not be that beneficial but if there are many small loosely connected components I think such reviews are worth trying.
