My first reaction was that this must be a mistake. No informed software expert could possibly posit agility against discipline. I looked it up after the conference. This attendee was indeed accurate. I found Boehm's article: "Rebalancing Your Organization's Agility and Discipline" here: http://www.agileprojectmgt.com/docs/Boehm20.pdf.
Wow.
Wow.
First paragraph of the abstract says: “we realize that ‘disciplined’ is not the opposite of ‘agile’ but it is our working label here for methods relying more on explicit documented knowledge than on tacit interpersonal knowledge”.
That’s like titling an article as “Rebalancing gun control and murder” and mentioning in a footnote that not all murders are caused by guns, but that “murder” is our working label for lack of gun control. However you fall on that topic, you can see the illusion being prepared.
Table 1 shows that the home grounds of “disciplined method” include “stable, low-change; project/organization focused”. How many of you, dear readers, work in such environments? Any?
Table 1 also conveys that “quantitative control” is the home ground of “disciplined” methodologies. Is this to mean that us agilists just shoot from the hip and decry measurement? Not in the least. What’s your unit test code coverage, Mr. Discipline? Do you measure it? I do.
Primary goals of the “disciplined” include “High Assurance”. Indeed. Excessive documentation, analysis paralysis, waiting to show users working code for long periods of time provides “high assurance”? That’s your “disciplined method” for you. Documents in lieu of working code? Is that what assures highly?
I would prefer Mr. Boehm’s table of “home grounds” to relabel the columns “Agile” and “Disciplined” with these terms: “Planning” vs. “Plans”. Here’s the trick. Agile relies on the act of planning and the discipline of responding to change. His so-called “disciplined” methods rely on plans that usually remain static and get modified by committee.
Mr. Boehm’s spider chart shows dimensions for attributes of a project to show whether it is more or less amenable to agile or “disciplined” methods. I’ll take them one at a time:
- Personnel. Essentially Mr. Boehm says you need smarter people to do agile. This is probably true. I would argue, however, that you’d rather pay one person $90K who can do the work of two people at $60K and that the diminishment of communication costs between people adds to the economies of scale beyond the numbers. This is true in any environment that you wish to consider. The best programmers, it is said, are 10 times more productive than the average. Why not pay twice the going rate for someone who’s only, say, five times as good?
- Dynamism. (%Requirements-change/month). If your requirements don’t change as much, agile is not right for you. What a silly statement. They probably meant to say that if your requirements don’t change as much, you can hire cheaper help who can’t adapt to change. Agile works well in dynamic (i.e. most) environments. You might be able to get by in the rare “stable” environment with excessive documentation, and delay between idea and working code.
- Culture (%thriving on chaos vs. order). I love this statement: “[disciplined devotee] thrives in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures”. When’s the last time you heard someone say “I am particularly empowered when somebody tells me exactly what to do and when to do it”? I’d much rather have a team of thinking, adaptable, empowered developers than drones who simply follow the process. Am I way out there?
- Size. This is the big knock on agile… that it doesn’t scale. I’ve seen it scale… well… fail to scale. I’ve yet to see a successful large-scale agile project up close and in person. But this should not be interpreted to mean that I discount the possibility. I believe it can be done. I just think that it requires enlightened leadership. That’s where the dearth lies.
- Criticality. Really, this is plain stupid. Sorry Barry, but this dimension really irks me. When’s the last time you worked as a leaf-node part of a team on a project in either a waterfall… umm, I mean, disciplined… approach or an agile approach. This dimension alone conveys to me that you have lost touch with software development reality. Agile is not the antithesis of discipline. You probably think that agile means “no documentation” – like many ignorant folks out there. Fortunately they’re not writing about it; alas, you are.
One of the paragraphs urges readers to “assess the likely changes in your organization’s profile over the next 5 years”. Please. If anyone has visibility beyond the next year, my hat is definitely off to you. And write it down, revisit it in a year and see how wrong you were. 5 years? No freakin way. Your vision of possible organizational stability warrants an inclusion in the fantasy walk of fame.
Mr. Boehm has a bullet that implies that dependability is a hallmark of non-agile methods. It reads: “key future trends to consider include the increased concern with software dependability and need for discipline”. The authors have crossed a line here. They're no longer using “discipline” as a catch-all for waterfall methods, they’re now using discipline as an inarguable quality. Again, Agility is all about discipline. They are clearly out of touch.
Here’s a phrase that disgusts me: “Examples of potential anomalies are: Operating with agile, fix-it-later developers with a growing, increasingly enterprise-integrated and dependability-oriented user base”. Really. “Fix-it-later developers”… implies that agile developers are hackers who let bugs fester. And that somehow, agile development conflicts with a user base that values dependability.
Unbelievable. Really. Mr. Boehm (and coauthor): Poke your head up into the real world. Join an agile project. Don’t just read about it and regurgitate uninformed opinions.
In sum, I am disappointed, and amazed at the observations in this article, which seem to be informed mostly from uninformed, anti-agile pabulum.
No comments:
Post a Comment