Think of any biological system, like a
BeeHive, for
instance. A minimum number of bees are required to collect nectar for
the good of the hive and Queen Bee. If they cannot find enough, the whole
hive may die. If they get enough, the Queen bee will lay more eggs, but
hopefully not so many that the feeding and rearing of the new bees
becomes a burden that endangers the hive.
--
DavidCymbala
(Er-r-r, Patterns are allegedly to be built from examples of known systems, not speculation or inventions. It worries me to see one written without examples, makes me think this is
SpeculationInPatternFormat (which would be ok if you just said so). see also
ResultingContextNamesProblems --
AlistairCockburn)
{ You're certainly right. I'll be re-writing this as a pattern if it
actually merits it someday. -David }
I've seen instances of this "pattern" lead exactly to the opposite of
desired behavior in software development.
People will work to optimize what is measured, or what they believe
is measured, and a reporting system leads them to try to divine what
second-order artifacts and activities are being monitored as indicators.
It may be O.K. if you're monitoring progress on the actual end-user-delivered
artifact, using a proven and time-honored measure like, oh, lines of
code or something...
What happens is that people manipulate the reports to "draw attention to
themselves." If they get attention, rewards, or resources, they feel
important, and may even feel they're accomplishing something. Elite teams
probably figure this out faster than the others.
And I don't know about you folks, but I've yet to see a software house
where everybody isn't 120% busy. It's a strange phenomenon, because
productivity drops if you try to increase this number through overtime
(because people burn out) or if you try to decrease it by "working
smart." I think that the developer duty cycle is one of the most
misconstrued measures of productivity or anything. The goal is
not
to keep people busy. People need think time (
UnderTime) on effective
projects, too. I think there is another kind of "working smart" based
on sound domain knowledge, passion for the job, and strong customer
engagement that makes the 120% work harder for you. But that's a whole
'nuthuh set of patterns...
Examples:
- A project where resources were added to groups that weren't solving MRs (bug reports) at the same rate as other groups
- A large project where the ISO process empire became an effective way for teams to draw attention to their own "needs" and get "resources"; the project ended up drowning in the staff hours allocated to process
- The pattern (anyone know where it is?) TheSqueakyWheelGetsTheGrease.
I, like
AlistairCockburn, remain very skeptical that this is a pattern.
--
JimCoplien
This is well-placed criticism, Alistair and Jim. I finally finished reading
Jim's OrgPatterns in the PLoP1 book, and realized that I missed the
boat on making my point. This idea may not be clear enough for a
pattern, but may just be a general guideline. -David
Is the
CriticalNumberOfWorkers concept a corollary of the model in Robert Axtell's paper "The Emergence of Firms"?
http://www.brookings.edu/~/media/Files/rc/reports/1999/06technology_axtell/firms.pdf
In Axtell's paper, workers are characterized by their propensity/ability to add value, as opposed to their propensity to free-ride or ability cause more harm then good.
On page 22, Axtell says, "It seems that the optimal size of a homogeneous group is very nearly at the stability boundary of the group.... it might be dangerous to select the optimal group size, for a small perturbation to the next larger size could bring on unstable oscillations, and presumably, the demise of the group."
On page 36, Axtell notes that in his simulations, "It is as if firms facing declining effort levels maintain total production, perhaps through the incorporation of new agents."
On page 47, Axtell has interpreted his model's "firm growth and demise as a process in which agents are attracted to high-income firms, these firms grow, and once they become large get over-run with free-riders." In a footnote, he states that "In reality the life cycles of firms are thought to be intimately intertwined with product and industry life cycles".
On page 67, Axtell notes that in his model, "successful firms are not profit maximizers, but rather are those who attract and retain productive workers." This is partly because his model does not have any explicit ways for profits to produce compounding growth, other than through accretion of workers.
When an organization drops near or below its
CriticalNumberOfWorkers, it may suffer from the
TalentPump AntiPattern.
See also:
FixedCost,
TalentPump