Blasphemy, I know. Lest the keyboard burn my fingers, I should say that I really like Agile a lot. What I don't like about Agile is that it means
whatever you choose it to mean. Agile is a brand name, useful for selling books and expensive consulting. But it isn't a specific methodology. Consultants and Agile boosters use the Agile brand the way terrorists use the al Qaeda brand, to make whatever agenda they happen to be pushing sound more powerful.
If a dev organization uses any Agile practices at all, and delivers software at the end, its Agile boosters or Agile consultants proclaim, "See, Agile works." If the organization uses Agile practices and the software is late, broken or unusable, they say, "We just weren't Agile enough!"
If a dev organization uses any Agile practices at all, and delivers software at the end, its Agile boosters or Agile consultants proclaim, "See, Agile works." If the organization uses Agile practices and the software is late, broken or unusable, they say, "We just weren't Agile enough!"
Because Agile doesn't mean anything,
it's easy to defend any practice, no matter how lame, by calling it Agile. Don't like being held to a schedule commitment? There are agilistas out
there saying, "You can't estimate schedules anyway so Agile
doesn't do schedules." Don't like specs and planning documents? There are Agile boosters saying, "The code is the documentation." Rather
jump straight to coding instead of doing design? There are Agile-branded supporters
for that too.
Particularly disingenuous are allusions by agilists of a certain stripe to the Standish Group's CHAOS reports and the "Software Crisis". Standish makes money by selling an expensive annual report which perports to show that most software projects are delivered late and over budget (which mean the same thing). This particular strain of agilists proposes to solve the crisis by refusing to schedule. That might cut it on the web, but anywhere hardware must be manufactured or media ordered to coincide with release, refusing to schedule just won't satisfy stakeholders. These same agilistas like to compare their brand of Agile against a straw man comprising the worst habits of traditional development. This doublespeak put me off taking Agile seriously for years.
I am also leery of developers who claim to be agilists, but whose agenda is to discard any rigor or discipline in an existing software process in favor of blasting off in a blaze of coding glory. There are Agile processes that don't do up-front design, and others that don't do documentation, scheduling, or whatever. These devs take this as an excuse to do away with all these things, with predictably appalling results.
I am also suspicious of one-size-fits-all prescriptive agile processes like XP. Pair programming (a required practice in XP) is helpful, but very expensive. A mature team can be successful with a less expensive feedback method; code review or maybe static analysis. XP may be the perfect process for a particular team in a particular company. It's just not perfect for every team at every company.
Particularly disingenuous are allusions by agilists of a certain stripe to the Standish Group's CHAOS reports and the "Software Crisis". Standish makes money by selling an expensive annual report which perports to show that most software projects are delivered late and over budget (which mean the same thing). This particular strain of agilists proposes to solve the crisis by refusing to schedule. That might cut it on the web, but anywhere hardware must be manufactured or media ordered to coincide with release, refusing to schedule just won't satisfy stakeholders. These same agilistas like to compare their brand of Agile against a straw man comprising the worst habits of traditional development. This doublespeak put me off taking Agile seriously for years.
I am also leery of developers who claim to be agilists, but whose agenda is to discard any rigor or discipline in an existing software process in favor of blasting off in a blaze of coding glory. There are Agile processes that don't do up-front design, and others that don't do documentation, scheduling, or whatever. These devs take this as an excuse to do away with all these things, with predictably appalling results.
I am also suspicious of one-size-fits-all prescriptive agile processes like XP. Pair programming (a required practice in XP) is helpful, but very expensive. A mature team can be successful with a less expensive feedback method; code review or maybe static analysis. XP may be the perfect process for a particular team in a particular company. It's just not perfect for every team at every company.
Most Agile shops I've worked in
had decayed Agile processes, announced with great fanfare
by Agile boosters some years before I arrived, and since
collapsed to a few residual practices like feature request sticky-notes on the wall, or daily stand-up meetings. But the "sprints"
were ten week marathons, and the code only shambled out of QA into customer hands a couple times a
year. I'm sorry, but this isn't Agile. Not capital-A Agile, and not little-a agile either.
I think this situation is sad, because if every dev team combined rapid iteration with feedback from design review and test, plus the amount of rigor in other processes that was appropriate to the quality desired from the work products, we would live in a world of far more beautiful software than what we see today. I don't know what to call this methodology. Sure it's Agile, but it's Agile in a specific way.
I think this situation is sad, because if every dev team combined rapid iteration with feedback from design review and test, plus the amount of rigor in other processes that was appropriate to the quality desired from the work products, we would live in a world of far more beautiful software than what we see today. I don't know what to call this methodology. Sure it's Agile, but it's Agile in a specific way.
I've come to the conclusion that there is some indefinable something that a successful team has that is missing from unsuccessful teams.
ReplyDeleteAnd when they're successful (because of course, they are successful teams), then *whatever* methodology they happen to be using is the "right one". They could invent a new one, "Foosball Programming" (we need to kick this project out the door!), and make money with books and consultancy fees.
But in the long run it won't matter. Unsuccessful teams will fail (because they are unsuccessful teams) no matter the methodology they purport to use, and no matter how many books they buy or consultants they hire.
You have to have that certain something. If we could figure out what that is, and bottle it, we could make millions.
I disagree, at least partially. Good methodology can make a decent team great. Bad methodology can block a good team from achieving at their highest potential.
DeleteIn my experience dysfunctional teams usually mean dysfunctional leadership. A good manager can figure out who's spoiling the team dynamic, and deal with them. Often this means nothing more than making it clear what behavior is expected. Most workers want to please their boss, because they want to be regarded as valuable (and stay employed). Only in extreme cases does it mean cutting out a cancerous team member. A good manager will take this hard action for the good of the team.
This comment has been removed by the author.
ReplyDeleteAgile has all the characteristics of a cult. The picture at http://agilemanifesto.org/ resembles old paintings of the founding of some new religion. Notice especially the "divine light" dominating the upper center of the picture.
ReplyDeleteI worked on an Agile team just once. I didn't mind the stand ups (but who wants to be called a "pig"), but paired programming drives me nuts. When actually writing code (which is after all, the gist of what we do), I need to be by myself (most of the time; and a cube is fine). I try to get into "the flow" and I have been writing very good software for decades that way. It just doesn't work sitting shoulder to shoulder with somebody else--at least it doesn't work for me.
The key to Agile in my opinion, is that it forces the mediocre programmers, the ones who would otherwise be sitting in a cube finding every excuse in the book not to work, to actually *do something*. Maybe that's good for them, but is it good for the better members of a team?
And "modified Fibonacci sequence" for assigning story points? Give me a break. Go read up on this Fibonacci sequence pseudo-science.
All methodology is religion. You must believe or be cast out. The difference is that a good methodology works actual miracles, that every participant can observe first-hand.
Delete@Kurt: I hope you're kidding about "religion" there. Systems engineering, bits and pieces of which made into Agile, is a real, engineering field: you can get a Ph.D in systems engineering.
ReplyDeleteOf course, we're not real engineers, we're programmers; some programmers (and even managers) like to call themselves engineers, but that's laughable. Ask an electrical engineer, or a mechanical engineer about their "methodology," not how they get things done, but how they get to the point where they're doing anything important at all. Unlike programmers, they can't just drop out of college and start Microsoft or Facebook, or start writing code for Google.
I think that programming has somehow just got stuck in its infancy--for decades now. And I agree that it's a good team--not a "methodology"--that does good work, to the extent that's possible with software.
Anyway, I think the rest of the world will eventually catch on to what we programmers are foisting on them, and we'll end up having to behave more like real engineers: you know, 4-5 years of very intense academic study; then you get to be a junior engineer for a few years where everything you do is under the direct supervision of a senior engineer who doesn't want to take a chance on losing his license, etc.
You can get a PhD in religion or philosophy too. Nothing about a PhD makes a discipline into a science.
DeleteI think programming *can* be pursued as a science. I don't meet all that many programmers doing so.
When a person embraces a prescriptive methodology uncritically, accepting a single named idea like XP as the savior of their team or company, they won't accept any derviation or contemplate any change in practice. Anyone suggesting any other idea (code review instead of pair programming, scheduling, sprints spent on design, production of an architecture document) is, to such a person, a heretic who must be cast out. This is exactly the kind of magical thinking that you find in religion. It is the basis of my charge that methodology is religion.
Even a successful method must be embraced by the members of a team. A team member who doesn't buy in creates disharmony that is desctructive to the team. The heretic must be cast out.
I think we mostly agree--except in my opinion, it is not inevitable that a methodology will become a religion. That's why I brought up systems engineering (although in the hands of programmers it would likely end up, as you say, a religion).
ReplyDeleteAnother example of this problem is TDD. I have yet to find anything written about this which is not wildly evangelical: "We will now do it this way; we will not even consider any other way; it is the way, the truth and the light."
I might be open to TDD in certain, perhaps limited, cases. However, would it be too much to ask for, say, five reasons why TDD is a good idea, how it helps, what it adds, what errors or other difficulties it avoids? And five reasons it is not a good fit, causes problems, makes the design worse, etc.? This is the kind of reasoned, cautious discussion I like to see rather than religion and activism.
*Any* repetitive activity becomes a religion if adherents accept its truth on faith alone, expect obedience without understanding, if the heathen must be converted, and heretics cast out.
DeleteEvangelism happens to people who believe they have actually witnessed a miracle (good outcome of the methodology), but cannot articulate a proof.
People are lazy when they can be. Magical thinking about a good methodology is just one example. It's hard to do careful experiments and collect data, and easy to say, "Well everyone knows that..."
There always some differences that get to cause and that should be thing according to me, When its about discussing agile consulting is more like the basic need which surely helps a big time.
ReplyDelete