In my recent web travels, I stumbled upon this study, which referenced this paper by Barry Boehm.
Barry is a well-known figure in the world of software development methodology (among many other accomplishments, he's the father of the spiral methodology).
I had the honor (at the last minute, and totally without foreknowledge) of sitting on a panel with him at Agile Scotland last April (2004), just after Barry's book came out.
Never one to shy away from expressing my opinion, I felt (and still feel) that Barry's characterization of an Agile/Discipline polarity was misleading, implying that Agile methods were not disciplined, and that plan-driven methods are. (The paper also seems to say that Plan-driven approaches are for the important projects, but that might just be me).
My reason was/is simple: Everyone I know, and every team I have worked with that has practiced an Agile method (XP in particular) expressed the feeling that doing so served to bring sustainable discipline to their process -- something sorely lacking in their environment. Note I said sustainable discipline -- some shops were missing the sustainable part (i.e. they had lots of structure, but nobody could keep within it and get anything done) or they were missing the discipline part (i.e. their software development process was a risk-unbounded free-for-all).
Like everyone else, I find it easy -- when someone seems to so "not see" something that I see so clearly -- to largely ignore their perspective. And like everyone else, when I do this, I miss opportunities to learn something. With Barry's work this is especially foolish since this guy's been around the block a few times (He's been building software since before I was born). So, I've always been reluctant to dismiss his POV out of hand. Hoping instead that we were simply seeing things differently.
Upon rereading the paper, I think that is the case (I still think Barry's tone is very open to misinterpretation however).
Barry's paper includes a chart showing five critical factors of software development environments and their "discriminators" for both Agile and Plan-driven approachs. One of them is 'Culture' (from the above referenced PDF, Page 5):
|Agility discriminators||Plan-driven discriminators|
|Culture||Thrives in a culture where people feel comfortable and empowered by having many degrees of freedom; thrives on chaos.||Thrives in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures; thrives on order.|
Now, when I hear 'thrive' I think 'sustenance', 'bountiful food supplies' and 'growth.' So this old norse root is kinda interesting, conjuring images of proto-vikings ranging the countryside seizing bountiful prey, tearing it to bits, roasting it on a bonfire, washing it down with mead, and then sleeping one off (see I was going for over-the-top metaphoric imagery, not mundane pedagogical pedantry).
And so, I think I have found a perspective where Barry's observations and mine are consistent. From this perspective, Agile does thrive on chaos, and plan-driven does thrive on order, and yet discipline is still central to Agile development.
Agile methods are used to turn chaos into order, consuming chaos and producing order as a by-product of navigating toward the true goal of the project (presumably to ship software). Agile methods (i.e. true Agile, not the market-speak Agile==Good stuff that passes for Agile these days) attract those people who are comfortable with Chaos-as-creative-potential, who seek to bring harmony to their software development process. They don't want chaotic process, they don't seek to build software in a chaotic way, but they are willing to seize chaotic opportunities, because it means a chance to define an "appropriate" process, one tailored exactly to achieving their goal, with no wasted effort. Agile methods are master toolkits for building processes that foster sustainable discipline. As such they are indirect tools for delivering software; used to influence the outcome, not dictate it. As Agilists believe the people are what will actually make or break the attainment of the goal, this makes a lot of sense.
Conversly Plan-Driven methods are used to turn order into product. They consume order (and may very well create chaos!) as they move toward their documented, specified, and largely immutable goal. They are giant air-craft carriers smashing through waves of change as they progress, largely indifferent to them, toward their goal (presumably to ship software). Big. Indomitable. Expensive. When they arrive at their goal, it is irrelevant what they had to plow through (or under) to get there, as long as the goal was achieved. Plan driven methods attract those who are comfortable with waste and inefficiency as long as they believe the cost will not exceed the benefit of achieving their goal. Plan-driven approaches are thus a direct tool, a recipe that we must follow in order get our product -- as long as we don't mind the cost of the ingredients, or how much of them we use.
In short, Barry is looking at the landscape from the beginning of the process, whereas I am viewing things from the end of the process. With Agile methods, having the discipline to succeed is a deliverable, with Plan-Driven methods its a pre-requisite. Knowing whether we have it or we need it, is very important to our success in this business.
In this sense, and in this sense only do I agree with Barry's notion that we must balance Agility and Discipline.
And so, I return to where I started: that those who think Agile means building software with no process, no plan, and no discipline are not seeing what I am seeing -- but maybe, its possible that Barry and I are seeing the same thing (if from different sides of the street).
That makes me feel better somehow.