Organizational Pattern: Producers In The Middle
February 26th, 2010
(From Organizational Patterns of Agile Software Development )
In a project, not all roles hear everything. But much of the information communicated has important implications for the product.
Within any software project, there are many activities, roles, and individuals competing for attention. Of course, there are the developers. But project managers have a need to be at the center of everything. They need to have their finger on the pulse of the project; to know everything that is going on. That’s their job. In a similar manner, perhaps to a lesser degree, other roles also need to be involved in the project.
But all roles are not equal. Certain roles (developer and a few others) contribute directly to the product; they create it. Most other roles contribute indirectly to the product; they (should) exist only to help the producers do their job. The producer roles need information in order to do their job.
Therefore,
The producer role(s) must be at the center or very near the center of the hive of communication. Make sure the producers are party to all, or nearly all communication about the project.
Organizational Pattern: Don't Interrupt An Interrupt
February 25th, 2010
(From Organizational Patterns of Agile Software Development )
It’s important to balance a desire that SOMEONE ALWAYS MAKES PROGRESS (4.1.20) with the thrashing that can accompany short-term priority calls. One worker will inevitably be blocked on you—you can’t do both things at once. Complete, omniscient foresight and scheduling are unreasonable to expect.
Therefore:
If a developer is already working in “interrupt mode” on a critical issue, don’t put that work aside until it is complete or until that issue itself becomes hopelessly tangled.
Organizational Pattern: Day Care
February 25th, 2010
(From Organizational Patterns of Agile Software Development )
Your experts are spending all their time mentoring novices.
You begin to hear things like “We are wasting our experts,” or “A few experts could do the whole project faster.” Indeed, the experts are not proceeding at the rate you or they would expect, because training the new people is draining their energy, time and concentration. But the new people must be trained, by experts, of course.
At the same time, you must make progress on the project itself.
Therefore:
Put one expert in charge of all the novices, let the others develop the system.
Separate an experts-only “progress” team from a training team under the tutelage of one or more mentors. Select the mentors for their ability to teach design and programming (object-oriented design and programming, for example) to novices. Let the progress team design 85-95% of the system, let the training team focus on quality training, delivering only 5-15% part of the system. Transfer people to the progress team as they become able to contribute meaningfully.
Make sure that the training team does not simply do training exercises, but actually contributes to the final system in an ever-increasing way.
If you have many people to train (more than, say, six), you will have to design a series of tasks for them to attempt. Otherwise you may give them a small, real part of the main system to design.
If the people in the training team are the ones who know the domain, you will have to make some further adjustment, or else the division may cause conflict.
