Knowledge Sharing Pattern Language
Pattern
KSP04
Trust or Check
| |||
|
Problem | A project manager is unsure about how to follow a project team member’s progress in a project. |
Initial Context | The check activities here are introduced in addition to the normal quality assurance activities defined in software development processes. Here it is assumed, that normal document reviews, code reviews and testing are implemented. |
Roles | A Project Manager managing the project. The project manager is the key actor in this pattern. A Project Team Member, normally a Software Engineer, implementing tasks in the project. |
Forces | The results of the work of a project team member implemented in a project are visible normally only when some testable and/or visible artifact is produced. In some cases this may result in a situation, where a project team member implementing a single assignment behaves as if everything would be fine and the delays or problems are visible only after the deadline of the assignment. The purpose of this pattern is to help to have an understanding of possible problems as early as possible.
Constant checking and surveillance by the project manager takes time and may affect negatively the team spirit. It is not reasonable always to follow all project team members and their progress at a detailed level. Some kinds of criterion is required to determine when more follow-up might be required and when not. |
Solution |
|
Resulting Context | After implementing these kinds of checking activities, the project manager knows the project team member better and can, in the future, either trust easier or knows what kind of checking activities are required. One result can also be that the person is found not to be suitable for these kinds of assignments.
The potential negative results of the surveillance must be followed. See also the potential pitfalls. |
Instances | This pattern should be used always when assigning a new project team or when assigning a task (must be decided for all project team members participating in the task implementation). In many cases the pattern implementation is finished after deciding that a person can be trusted and the normal quality assurance activities in the project are enough.
Potential pitfalls:
|
Process Connection | Supports Project Management process, project realization. |
Practices
Examples of recommended practices for check activities (see step 2 above):
- Establish good communication relationship to openly discuss about possible problems.
- If reasonable, divide the assignment into smaller subtasks with clearly defined results. Follow up so that the results are achieved.
- Use pair programming with a pair that you can trust and has the required competence.
- Have an unofficial preliminary review/testing during the task to have better understanding of the situation and the progress.
- Have someone else test the code/results produced by the team member.
Last changes at 26th December 2007