Thimbles & Care

Interesting: Context Reports

This morning I realized I might have a productive way to twist status reports into a useful exercise. Let’s call them context reports. A status report documents actions both completed and planned. A context report documents the reason why (and to a lesser extent how) you’re completing these actions and I suspect this information is far more useful to everyone involved. Let’s try it out by transforming common status report items into context report bullets.

I found this from a link from the Typical Programmer: People and methodologies in software development. The abstract:

This thesis reports on research performed over a ten-year period, interviewing project teams, participating directly on projects, and reviewing proposals and case studies. The research addressed three questions relating to people and software development methodologies (Q1 through Q3), and produced six results (R1 through R6).

1. Do we need yet another software development methodology, or can we expect a convergence and reduction at some point in time?
2. If convergence, what must be the characteristics of the converged methodology? If no convergence, how can project teams deal with the growing number of methodologies?
3. How does the methodology relate to the people on the project?

The answers are:

1. A methodology is a formula describing conventions of interaction between roles.
2. People’s characteristics, which vary from person to person and even from moment to moment, form a first-order driver of the team’s behavior and results. Such issues as how well they get along with each other and the fit (or misfit) of their personal characteristics with their job roles create significant, project-specific constraints on the methodology. This result indicates that people’s personal characteristics place a limit on the effect of methodologies in general.
3. Every project needs a slightly different methodology, based on those people characteristics, the project’s specific priorities, and the technologies being used. This result indicates that a team’s methodology should be personalized to the team during the project and may even change during the project.
4. A set of principles were found that can be used to shape an effective methodology to the above constraints. These principles deal with the amount of coordination and verification required in the project, the trade-off between rework and serialization of work, and the trade-off between tacit and externalized knowledge in use by the team.
5. A technique was found to create a situationally specific methodology during the project and in time to serve the project, and to evolve it as the project progresses.
6. All the above suggests a repeating cycle of behavior to use on projects.
   1. The members establish conventions for their interactions — a base methodology — at the start of the project. This can be likened to them “programming” themselves.
   2. They then perform their jobs in the normal scurry of project life, often getting too caught up to reflect on how they are doing.
   3. They schedule regular periods of reflection in which they reconsider and adjust their working conventions.

These results have been used successfully on several industrial projects having the usual time and cost pressures on the staff.

I think this is exactly right. I’ve had an idea for a post about humans in software development floating in my head for a while; maybe I’ll get to it soon.