A couple of weekends ago, my wife and I were out for a bicycle ride on the Washington & Old Dominion (W&OD) - a paved, multi-use trail that stretches 45 miles from Washington, D.C. to Purcellville, VA.
We were westbound on a section of the trail between Route 7 and Dry Mill Rd. We were coming up behind a runner when the runner stopped suddenly and looked up. The upper two-thirds of a dead locust tree crashed down across the path. The tree fell harmlessly to the ground, but lay across a section with high-sloped sides. The tree had completely blocked the trail. Our initial attempts made it obvious that we didn't have enough muscle power to move the 10-inch diameter main trunk.
Soon other cyclists and runners began to arrive. Most began to dismount - except one guy on a shiny new $5K+ bike who didn't seem interested in helping. Ideas were quickly tossed back and forth about how to get the thing out of the way. I even heard my wife say something like, "This tree isn't going to get moved unless everyone helps." (wink, wink, nudge, nudge…).
As we organized to lift the main trunk, we noticed that part of the trunk was covered with a vine. It didn't look like poison ivy, but you never know. One woman said that she wasn't allergic to poison ivy, so she'd lift that section. One person with a bad back volunteered to clear smaller debris. By working together, in 10 minutes we had cleared that entire mess and we were back on our machines.
As we rode up the trail, we talked about what we had observed. We chuckled about the able-bodied guy who seemed willing to stand there and watch everyone else clear the path for him. However, for the most part we were impressed by the way this ad hoc team had worked together.
Of course, I began to pontificate about how this experience was an analog to software projects. We had been part of a self-organizing team. Each participant had different strengths and had contributed where they were best able. Some used their strength to lift. Some contributed their immunity. Others came behind and cleaned up. This simple project hadn’t required a detailed plan, but someone had worked to remove obstacles (i.e. "This tree isn't going to get moved unless… ").
If we’d had many trees to move, we probably would have wanted a plan to tell us which trees to move and when. We would have wanted to be able to tell the W&OD trail users when they would be able to use each section of the trail. We might have organized a brief planning meeting before moving each tree to be sure that we were being as efficient as possible.
To be sure we were on track, we would periodically ask everyone to briefly describe what they had done, what they were planning to do, and what was stopping them from being effective. That might have allowed us to discover that one team member was worried about scratching their new bicycle, but we certainly would have been able to understand everyone's contribution.
Historically, humans have cooperated very effectively to solve problems. That's one of the things that has allowed us to survive as a species. When the problems are more complex, we've learned that it's important that someone create a plan so that things get done in the proper order, etc. However, I think we would also agree that sometimes we have fallen into the trap of focusing too much on the plan and not enough on the people.
That’s why even when we're doing large, complex things it's essential that we make use of some of the same basic techniques that have worked on ad hoc projects.
I think that most agile practitioners would say - and I would agree - that agile software methods aren’t radically new or different. They’re simply a recognition and codification of the behaviors that have made humans successful as a species.
What do you think?