The Tree

 

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.

  • Work to a high level plan (10 trees in 3 hours, trail cleared by 6 pm)
  • Employ short planning horizons (finish the current tree before starting the next tree)
  • Prioritize work (clear trees at mile markers 4, 6 and 8.5 first)
  • Employ self-organized teams (let the team decides how to clear each tree)
  • Leverage individual strengths (take advantage of Patty’s poison ivy immunity and Fred’s ability to clear leaves very quickly)
  • Improve the process (For the next tree, let’s be sure to…)
  • Give everyone a brief chance to be heard ("I've cleared the small branches, now I'm going to clear the leaves", "I'm worried about scratching my new bike")
  • Designate someone to clear impediments ("Next time, I'll arrange for a safe place to lean your bicycle so it won’t get scratched")

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?

Tom

Comments:

Hi Tom,
Great to see more practical wisdom from you and the OUM Team (David's paper was well received here at InSync11 this week as well).
Your example shows that to get big projects right, you just need to be able to do all the small things right - you really don't necessarily have to have done exactly the same thing previously. There were a lot of 'basic' skills in your example, you didn't have to phone for a civil engineer! Your common sense approach is so refreshing - thank you.
Jeannie

Posted by Jeannie Dobney on August 18, 2011 at 03:37 AM GMT+05:00 #

Jeannie,

It's great to hear from you. Dave mentioned that he had finally had the chance to meet you at InSync. I had hoped to be there, but couldn't make it work.

I tried to organize an OUM Level 3 training course in conjunction with InSync, but my offer came too late and there were other things which were higher priorities. However, Dave is a very experienced OUM instructor (40+ classes). If there is sufficient interest we can set up a partner-facing OUM class. As Dave mentioned in the InSync session, we are also in the beta period of an OUM Specialization.

Thanks for your positive comments. It always interesting to observe how humans behave in these little instances where roadblocks (pun intended) are throw in their way. These situations tend to bring out the best (and sometimes the worst) in people.

Thanks again for staying in touch.

Tom

Posted by Tom Spitz on August 18, 2011 at 04:17 PM GMT+05:00 #

Post a Comment:
  • HTML Syntax: NOT allowed
About

OUM Logo
The Oracle® Unified Method (OUM) is Oracle’s standards-based method that enables the entire Enterprise Information Technology (IT) lifecycle.

Read:

· Brief

· White Paper

· Customer Program Data Sheet

Connect:

· OUM on Twitter

· OUM on LinkedIn

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds