Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Mon, 03 Jan 2005

Are companies more like wheat farmers or rice farmers?

Twice a year, Dawn and I drive from the Grandparents' house to the White Mountains to hike. On the way, we always read a nonfiction book to each other. This vacation, it was James Surowiecki's The Wisdom of Crowds. I may have more to say about it later, but for now, this extended quote:

In [the Green Revolution in India] rice farmers and wheat farmers made their decisions about new crops in very different ways. In the wheat-growing regions [...], land conditions were relatively uniform, and the performance of a crop did not vary much from farm to farm. So if you were a wheat farmer and you saw that the new seeds substantially improved your neighbor's crop, then you could be confident that it would improve your crop as well. As a result, wheat farmers paid a great deal of attention to their neighbors, and made decisions based on their performance. In rice-growing regions, on the other hand, land conditions varied considerably, and there were substantial differences in how crops did from farm to farm. So if you were a rice farmer, the fact that your neighbor was doing well (or poorly) with the new crop didn't tell you much about what would happen on your land. As a result, rice farmers experimented far more with the new crop on their own land before deciding to adopt it.

Pages 120-121 in the large print edition, which was the only one our
traditional Barnes and Noble had when we stopped by on the way north.

Seems fairly straightforward, but it made me think a bit about the effort to make Agile methods more mainstream. Let's assume that Agile development works for the visionary crowd. Now we want to get early mainstream project managers and executives to adopt it. Geoffrey Moore calls these people pragmatists. He has a rule: pragmatists almost always adopt only after their peers do. Those peers are other pragmatists in the same industry. A visionary entrepreneur or someone in another industry is like a neighboring rice farmer: so different that their experience doesn't predict much. It's only the fellow pragmatists who can be treated as fellow wheat farmers.

This produces a first-mover problem: how do you persuade the first pragmatist to try something? I'm not going to talk about that here, but see Moore's Crossing the Chasm. Instead, I'm going to assume that we've succeeded at that. For whatever reason, MegaCorp has one Agile project going and producing good results. Are we over the hump? I think experience tells us not, and Surowiecki gives us a way to talk about why.

Let's consider the other project managers and executives in MegaCorp. When they look around themselves within the company, they see a huge variation in project results. (That's why they've probably already flirted with CMM: they crave predictability.) I think of every project as being like its own little rice patch. Why should the manager of the next-door rice patch believe that another project's success with XP means anything? Especially if that project was a pilot project: it was probably staffed with enthusiasts, it was probably small, it was quite likely a greenfield project, the Hawthorne Effect was surely in play, etc. etc. All these are reasons to avoid the risk of change. (In Moore's terminology, software encourages managers to be either visionaries or conservatives, leaving a bigger-than-usual chasm.)

To me, this suggests that those who want to encourage the spread of Agility should perhaps concentrate more on the second Agile project in a company than the first. One of the two goals of the Agile Alliance is to help more Agile projects be created. During the next year, we want to reach out more toward project sponsors and other executives. (I should have been doing a better job of that over the last year.) Perhaps the best way to do that is to provide specific support for moving beyond the pilot project. That'd at least be novel, and I think it demonstrates a reassuring long-term commitment.

## Posted at 20:34 in category /agile [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo