Having made a business case for the fallow pattern and compared it to similar strategies, it is appropriate to explore how such a thing might work.
The principal purpose of the fallow pattern is to afford an environment for informal, up-front, cooperative peer review without the distractions or intensity of pair programming. The motivation is to reinforce the conceptual integrity and hygiene of the product, as well as expose programmers to each other's work. A secondary purpose is to formally guarantee programmers on-the-clock time for maintenance activities conducive to keeping a tidy operation, as well as additional valuable metrics.
The fallow pattern only considers programmers, and only during the implementation phase — in which the code the programmers are producing is that which is shipped — however that may occur in a larger methodology. It may well apply to other workers and processes, but this article does not address them.
The fallow pattern assumes that the process of implementing production code is some variation on the following theme:
A conceptual hopper, a bug tracker for example, is loaded with tasks. These tasks are then queued and disseminated to each programmer, according to an arbitrary rule set. When a programmer completes one of these tasks, the result is tested, likely generating more tasks which get fed back into the hopper and the process repeats. When more tasks are being removed from the hopper than those added, the project is likely advancing. When the hopper nears empty, the product approaches completion.
Necessary to the process is the decomposition of discrete coding tasks such that they be expected to take a single programmer less than one business week to complete. As programming essentially is the fine-grained decomposition of tasks, this should be a natural process; it already occurs to some extent in Agile circles. The purpose of the week limit is to punctuate the development with off-time, eliciting a sense of completion. It is in this process that perhaps the fallow pattern is of greatest value. The decomposition technique itself will be addressed elsewhere.
The fallow period ought to manifest as a contiguous block of either one half-day for very small teams or a full day. When another programmer completes a coding task, they switch positions, and the fallow programmer resumes a normal work-flow. The ratio of fallow programmers to coding programmers should be such that the former could comfortably visit each of the latter in a single period — realistically about 1:3 to 1:6. The total amount of time spent in fallow for any one programmer should not exceed 1/P where P is the aforementioned denominator.
Fallow programmers should be selected on a semi-regular rotation, accounting for meetings, absences, dependencies and emergencies. It may be desirable, in some extraordinary circumstances, to not have a programmer in fallow. To avoid slippage, however, the discipline should be retained. Therefore, schedule the fallow period anyway, and if it turns out it isn't needed, the programmer in question can just resume coding.