Thursday, May 28, 2009
Big documents and bananas
This experiment placed five monkeys in a room with a banana tree in the center. Whenever a monkey attempted to climb the tree to pick banana, a sprinkler system would spray all the monkeys with water until the monkey retreated from the tree. They repeated this experiment until all the monkeys learned to not approach the tree. The monkeys liked being dry more than they liked bananas.
The next stage of the experiment involved replacing one of the monkeys with one who had never been sprayed with water. The new monkey soon started to approach the banana tree. However before the sprayers started, the other monkeys jumped into action and beat the new monkey away from the banana tree. This was repeated every time until the new monkey learned not to approach the tree.
The researchers continued to replace the original monkeys who were sprayed with water one by one with fresh monkeys. Eventually none of the monkeys in the room had ever been sprayed with water for climbing the banana tree. The monkeys still continued to beat up any monkey for approaching the banana tree. None of them "knew why” they couldn’t approach the banana tree. They just knew that the banana tree was off limits.
Sometimes we developers do the same thing. A company’s culture becomes intertwined with the “standard best practices” that aren’t questioned and never replaced. Personally I did this for many years pursuing waterfall methodologies. I wrote big documents up front (BDUFs) for projects that always failed to account for everything. Even after those projects shipped--following months of crunch and despair--I would start the next project the same way.
Are there any "banana tree" rules where you work?
Subscribe to: Post Comments (Atom)
This "experiment" is almost certainly an urban legend:
Actually, if you read them, neither of those entries refutes it. One of the comments say "almost certainly...".
A google search turned up this:
"Well, it seems to be true; not in the exact shape that it took here, but close enough"
I agree. Close enough!
Huh? That TinyURL link goes to an Answers.com answer that reads, in total, "yes":
Not the most credible support. What about a research article in a scientific journal?
That's odd. Yours is broken too.
You'll find two research articles referenced at the top of the article.
It's odd that you insist on research references after sending two links from snopes which don't confirm or deny the experiment and don't have any references either way. Double standard?
Just the usual (single) standard that "extraordinary claims require extraordinary evidence." That second link works. The study quoted there does seem to be the origin of the legend; whether that counts as "close enough" in its applicability to business psychology is evidently debatable. But thanks for the link.
The interesting point about the study (whatever the source) is that it appears to be an innate primal trait to do things we don't always understand the reasons for.
Most of us who have worked on large-scale projects have done things we don't always understand the reasons for (e.g. TPS cover sheets).
If you have not, consider yourself fortunate!
Honestly, who really cares if the monkey story is true or not? Fact is, this happens in organizations. People unquestioningly avoiding banana trees, even though it no longer (and maybe never did) make any real sense at all.
Truth is, it'd sort of be even funnier if the monkey study is false - maybe the monkeys are smarter than us!
Your argument for credible citation aside Allen, you know Mike's right. If you've never seen monkeys (managers, haters, old boys clubs) beating other monkeys (change agents, people with common sense & a desire to improve) away from bananas (best practices, promotions) where you work, I'd love to know which zootopia you work at!! I'll gladly apply to be the wet monkey munching all the bananas...
Seriously, everyone resists change - from my 4 year old nefew who resists bed time to my art directors who resist Agile because it "doesn't apply" to them (aka - they have a hard time breaking down big hairy goals into iterative sprint or release sized chunks).
I'm no head shrinker, but to explore a little, I think the urge to resist can start as healthy skepticism - which is great for the process of change. But I also think fear of failure, office politics or even peer pressure can take hold once the resistor has no more ground to stand on. Eventually, all they have to hold onto is the hope for an "I told you so..." moment sometime down the road. What is this, grade school?
Back to the topic - it's important for everyone (the resistors and change agents) to find common ground. "Can everyone agree there's a problem to solve? Can we be more effective? Do we want to stop over-engineering or creating huge docs that go out the window everytime the customer or PO demos the software?" Next, everyone has to be involved in the decision - "OK we all agree on the issue but some of you are apprehensive. Why and what specifics do you have reservations about? What would you do differently?" Finally, everyone has to see the benefits of your precious change - or it falls flat and people drop off.
I have found that tackling resistance to Agile has been somewhat easy with this or similar change management approaches.
Post a Comment