Here's another video from Ward in which he shows the working environment at AboutUs and talks a bit about the connection between his conception of wikis and agile programming.
In an evolution of the recommended extreme programming workspace setup. AboutUs gives everyone a desk on wheels rather than undedicated pairing stations, so that developers can rearrange the configuration to match who they want/need to work with at the time.
"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.
Martin Fowler, just wrote a typically insightful article about the number of development teams he has encountered, which, with the goal of being agile, adopt scrum for project management, but run into problems when they fail to adopt approaches to actually executing the project which enable successful iterative development.
I highly recommend that anyone interested in truly being 'agile' digest this article.
As an aside, as a side-effect of reading this article, I once again found myself looking at the original wiki, Ward Cunningham's WikiWikiWeb, which was pointed to by several links in Martin's article. Every time I find myself browsing around on Ward's wiki, I find at least three useful ideas.