"Once I built a railroad, now it's done
Brother, can you spare a dime?"
A couple of evenings ago at the monthly meeting of Agile RTP Jason Tanner from Enthiosys led a discussion of experience in introducing agile development methods to companies.
He led off by encouraging the audience to make index cards inscribed with impediments to the adoption of agile methods which the attendee had encountered, and tape them to a whiteboard. He then took the cards off and discussed them.
One of the first was something like, “people who can’t work without a detailed long-range plan.”
For some, reason, the old depression-era song “Brother can you spare a dime?” popped into my head as soon as that discussion started.
Planes, Trains, and Automobiles
Kent Beck tells the story in Extreme Programming Explained: Embrace Change (2nd Edition) (XP Series)
"Driving is not about getting the car going in the right direction. Driving is about constantly paying attention,
making a little correction this way, a little correction that way."
To me that’s the real difference between agile and waterfall approaches.
The waterfall “tradition” attempts to avoid getting off the road by starting out with a plan. If it works the plan is like a set of railroad tracks which forces the train to always go in the right direction. The engineer doesn’t need to pay as much attention.
Agile methods are much more like driving, setting a general short term direction, with the current long term goal in mind, and reacting to feedback so that constant correction keeps the project from going into the ditch. At a more mature level, it becomes more like flying a plane, which is like driving a car, but with more complex feedback-control relationships and in three dimensions rather than two.
The Problem with Tracks
A railroad is a great thing as long as it goes where you really need to go. But getting on the wrong train can be a costly mistake. You can end up traveling a long way away from your goal, and waste a lot of time in the error and in recovering from the error.
You might enjoy the scenery along the way, thinking you are progressing towards your goal, until you realize your mistake. This is a great metaphor for some of the waterfall projects which I’ve seen go astray. Of course those projects suffer the expense not just of riding the wrong train, but of designing and building the railroad through a process of design based on incompletely understood requirements.
As Yogi Berra said, “If you don’t know where you are going, you’ll end up somewhere else.” And all too often in developing software, we don’t really know where we are going except in a general or vague sense. Requirements based on this level of understanding are fragile in the face of knowledge gained about the problem context and about the solution as development proceeds. If you are riding the train, you might start to get a sense that you might not be where you need to be gradually, an increasing unease perhaps rising to panic.
If you are on the wrong track, you can end up wasting lots of time and lots of dimes!
I’ve found that it’s much better to file a flight plan, then react to changing weather, input from flight controllers, and radio instructions from “the home office” when business plans change and I now need to get to Chicago instead of St. Louis.
And that’s why that song popped into my head, I was thinking:
Once I built a railroad, but it went to the wrong place.
Trackbacks
Use the following link to trackback from your own site:
http://talklikeaduck.denhaven2.com/trackbacks?article_id=544
That sounds like one of mine. Let me tell you where I’m coming from…
I’ve been on several Agile teams, and noticed that the really successful ones were self-selected groups. These people joined the team in no small part because they wanted to be on an Agile team. The two “Agile” teams that I’ve been on, where the Agility was mandated on people not originally hired for an Agile project, were also successful, but not as much, and had some real persistent friction that showed no sign of letting up. You can lead a horse to water, in theory.
I’ve spent enough time talking to the resistance and trying to get their point of view that I think I can say this with confidence:
I have an Agile mindset. It seems to come naturally to me. I get it. But it does not come naturally to everyone. I mean no disrespect. Other people have different mindsets.
We like to think of our brains as completely general-purpose machines that can “get” anything, if only properly trained, and there’s a certain truthiness to that, but it is ultimately not true. It is not true in the same way that my cats don’t entirely understand doors; millions of years of evolution has not prepared them for that. It is worse than not understanding: the patterns necessary for understanding the topic at hand do not occur in the brains in question.
It may seem pessimistic, but I maintain that there is nothing, short of neurosurgery, that will put these people in an Agile mindset. Their brains are wired differently. No amount of talking to them about railroads and cars will bring them around; they will get back on the train the first chance they get. I know it sounds harsh, and I may be overstating my point just to make sure it gets across this time. And I really do mean no disrespect, because I am specifically thinking about some really intelligent people. But you must have the right people for an Agile team. Mandating Agility can work if you’re lucky and happen to have the right people, but I would not leave it to chance.
It’s not an academic point. There are large organizations that are trying to mandate Agile top-down, as if all the employees will be led to the water and drink up and be joyful. I think that’s optimistic. I’d like to believe that roughly half of a large existing non-Agile organization can be turned Agile, given some careful team formation. My fear is that if organizations do not face this reality, and persist in trying to turn everyone Agile, Agility will end up losing too many political battles, and I’d rather see half-Agile organizations than non-Agile organizations. At least with a half-Agile organization, I could find an Agile team, and be productive and happy.
At Agile Universe 2002, I heard Martin Fowler wondering out loud in a keynote address about whether or not Agility is a paradigm shift. I was thinking, gosh, I hope not! One of the characteristics that Kuhn noted about paradigm shifts is that it takes a whole generation for the new ideas to become generally accepted, because too many people in the industry just can’t wrap their minds around it, and you have to wait for them to die off. But surely, Agility would sweep the software industry by 2003, 2004 at the latest! 2030? You gotta be kidding! Well, now it’s 2009. About 1/4, 1/3 of the way there, do you suppose? 2030 is starting to look like a reasonable estimate. You can find pockets of Agility around now, but isn’t it just a bit like being Object-Oriented in 1976? (Not that you would know from personal experience, of course, Rick ;-)