BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Death by Agile Fever

Death by Agile Fever

Leia em Português

This item in japanese

Bookmarks

Eight years have passed since the discovery and characterization of the dreaded UML Fever [1] which has been responsible for creating waste and inefficiency on software programs across the globe. It is with great satisfaction to report, however, that during this span most of its known strains have gradually eroded from the face of the software engineering landscape. Few and far between are the UML diagram manufacturing dynamos that some programs once became due to a mistaken belief that such activity was indigenous to a new, improved, and revolutionary approach to successful software development.

Despite UML Fever’s welcomed dormancy, the furnaces at the software industry’s silver bullet foundry have continued to be very busy producing high grade bullets for the naïve, desperate, and ignorant to use on software programs in damaging ways. The damage caused by these silver bullets has spawned a number of new maladies plaguing software development that have yet to be characterized for the purposes of facilitating diagnosis and treatment. One of those observed maladies is Agile Fever

Agile Fever is a condition that robs otherwise rational people of their common sense in regard to adoption and application of Agile based processes for developing software. The consequences of Agile Fever have contributed to misapplication, misuse, and misunderstanding of Agile based software development processes with costly impact. For example, managers have been observed to base performance success criteria on the number of their programs that have adopted Agile even if not prudent to do so. Other programs have adopted Agile in contexts where there is no hope of a return on investment. And still other programs have invested in training and reorganization but develop software exactly the same way as they used to but with new terminology taken from the Agile dictionary.

Before any Fragilistas1 who might be reading this article get their knickers in a twist due to a belief that it is an attack on Agile and must be avenged with flaming commentary against its author, fear not. Furthermore, this article will deliberately avoid fanning the contentious flames related to Agile’s scalability to large teams, its applicability to developing safety critical software, or its general business value. While the academics of the world focus their attentions on resolving these and other issues, there are real software development efforts wasting real money, and wasting real time by misusing Agile in a number of common forms. The objective of this article is to characterize those common forms, in terms of Agile Fevers, so that they can be recognized and treated.

The Agile Fevers described below are the most common ones infecting some of the software development organizations that have adopted Agile based processes. Many are related, some are preconditions for others, but most are largely the result of decision makers who are not qualified to be guiding adoption and execution trajectories of Agile based software development processes. Finally, it is of critical importance to recognize that the Fevers documented below are not theoretical nor can their existence be debated as they have actually been observed. What can be debated, however, are the causes of these Fevers and the most sensible ways to treat and avoid them.

The Fevers

The Agile Fevers can be generally characterized as belonging to one of three stages that are aligned to the timeframes associated with transitioning to an Agile based software development approach: Early, Middle, and Late stages. As many readers will correctly recognize, some of the Agile Fevers are fuzzy in terms of where they might be best allocated stage-wise or that some of the Fevers might span all stages in some form. This article is less concerned with a perfect categorization of the Agile Fevers than it is to identify and characterize their symptoms so they can be recognized and treated as soon as possible.

Early Stage Fevers

The Early Stage Agile Fevers are collectively the most dangerous of all as they are the most numerous, easiest to catch, and have the highest potential for causing damage to a software development effort. Software programs considering the adoption of an Agile based development process must maintain a high state of awareness for detecting Early Stage Agile Fevers to ensure that all decisions are made based on facts and pursuit of value as opposed to misunderstanding and hype. The following diagram illustrates the Early Stage Agile Fevers.

  • Lemming Fever: A person with Lemming Fever is one who knows about Agile simply based upon what he or she has been told, be it true or false, without having any first hand knowledge of it themselves. The consequences of Lemming Fever can be very dangerous if infectees have any kind of decision making responsibility as it pertains to a program’s Agile adoption trajectory. The danger tends to increase as a function of an afflictee’s seniority in the program organization due to the greater consequences of bad decision making and the ability to dismiss underling guidance. Lemming Fever is one of the most dangerous Agile Fevers as it is usually a precondition to many and has the tendency to aggravate the symptoms of all others.

Information is not knowledge.
Albert Einstein

  • Easy Button Fever: This Fever is present in a person who believes that adopting Agile is as simple as pressing Staple’s Easy Button and as a result, their program can immediately begin reaping the benefits of Agile as imagined during the Lemming Fever stage of infection. Depending on a program’s existing development methodology, however, the shift to an Agile approach could mean significant change and might include reshaping the customer relationship, working with fuzzier requirements than in the past, understanding that rework is a realistic possibility, and that schedule slides are part of the culture with which to evolve the customer’s desired product. Typical infectees have little or no idea about the features which are typically credited for delivering Agile’s productivity improvements or the possible inapplicability of those features to their programs.

Instant gratification is not soon enough.
Meryl Streep

  • One Size Fits All Fever: Victims of One Size Fits All Fever believe that Agile based development processes are applicable to any and all development efforts with a return on investment being implicit in adoption. While tailoring is an important part of Agile adoption, the extent to which Agile must be tailored for a specific program’s context is an important barometer of its appropriateness. If daily meetings are tailored out due to non-colocation, customer involvement is tailored out due to lack of interest, schedule flexibility is tailored out due to hard deadlines, and requirements evolution is tailored out due to inapplicability, Agile might be the wrong "size". One Size Fits All Fever is a mental mindset that may stand alone from other Fevers that are typically associated with the tactical misuse of Agile.

The reason there's so much ignorance is that those who have it are so eager to share it.
Frank Howard Clark

  • Elbow Grease Fever: Elbow Grease Fever is often an escalation of One Size Fits All Fever buts its infectees do not necessarily believe that Agile is applicable to all software development efforts. This Fever is raging on a program when the decision has been made to force fit an Agile based software development process into its routine while having few or no properties in the Agile Sweet Spot [2]. The Agile Sweet Spot is a collection of characteristics that a software program should have to increase the probability of success as it applies to adopting an Agile based software development process. Classical symptoms of Elbow Grease Fever are characterized by Agile being adopted very late in a program’s development lifecycle or in cases where firm schedules, rigid requirements, and little flexibility undermine the benefits of adopting the Agile approach.

A long habit of not thinking a thing wrong gives it a superficial appearance of being right.
Thomas Paine

  • Hallelujah Fever: A person infected with Hallelujah Fever is very thankful that Agile has arrived to save the software industry from the development sins being committing since the dawn of the computing age. Its infectees classify tactics such as iterative and incremental development, which have long been leveraged by software engineers to reduce risk and promote early customer engagement, as falling under the Agile umbrella and falsely praise them under it. Hallelujah Fever frequently escalates into Cook the Books Fever where infectees credit adoption of Agile based software development with any observed productivity improvements as opposed to correctly giving credit to adoption of long recognized best practices.

I find war detestable but those who praise it without participating in it even more so.
Romain Rolland

  • Parrot Fever: Every software development effort infected with some form of Agile Fever tends to have at least one person suffering from Parrot Fever. This Fever is one where infectees are lightening fast to quote chapter and verse of whatever publications their software development process may be based upon in defense of any suggestion that it is misapplied or not working out as well as expected. Although characterized as an early stage Agile Fever, it actually spans all stages and only grows more serious with time. It is a typical reaction for uninfected people to develop a strong desire to strangle those infected with Parrot Fever.

Teach a parrot the terms 'supply and demand' and you've got an economist.
Thomas Carlyle

Middle Stage Fevers

The Middle State Agile Fevers are ones that typically appear later in the Agile adoption, but may also be present in the early stages of Agile adoption. These Fevers are largely the result of continued misunderstanding of the development context in which Agile is best suited as well as side-effects of trying to force it into where it might not belong. The following diagram illustrates the Middle Stage Agile Fevers.

  • Homonym Fever: The primary symptom of Homonym Fever is when an afflictee confuses the definition of agile in the dictionary with its capitalized form, Agile, which describes a methodology for developing software. While afflictees are typically aware that the dictionary defines agility as quickness, lightness, and ease of movement, they believe that the benefits of Agile are realized by somehow completing tasks faster as opposed to those benefits being realized largely as the result of improved communication and culture changes on a number of fronts. Afflictees of Homonym Fever will regularly interchange Agile and agile to describe a program and/or its development process without truly understanding what makes them different. Ask a suspected infectee what makes their program "Agile" as a test for possible infection.

Where misunderstanding serves others as an advantage, one is helpless to make oneself understood.
Lionel Trilling

  • Cargo Cult Fever: Cargo Cult Fever is one which afflicts a group of people imitating the superficial exterior of a process such as Agile without having any understanding of its underlying substance. The consequences of this Fever are that the people using the process do not have the context to evolve or tailor the process based on changing priorities, schedules, or constraints. An organization infected with Cargo Cult Fever often ends up with Road to Hell Fever as the result of its inability to adapt to variable conditions.

Reason obeys itself; and ignorance submits to whatever is dictated to it.
Thomas Paine

  • Simon Says Fever: Afflictees of Simon Says Fever are recognized by their participation in Agile related activities without the slightest idea as to why those activities are being conducted or why they are part of them other than because they are included in some Agile "checklist". The most common cause of this Fever is failing to tie all development activities to adding value and falling into a comfortable, robotic regimen that is merely an illusion of progress. Simon Says Fever is very commonly present in organizations where Cargo Cult Fever is raging

Rules are for the obedience of fools and the guidance of wise men.
Douglas Bader

  • One-Eyed King Fever: This Fever has the potential to severely impact the successful adoption of Agile and occurs when the Agile blind are coached by people with only a slightly better understanding of Agile than they have. The most common symptom occurring in the presence of One-Eyed King Fever is failure of a program to tailor Agile to its specific context or the failure of a coach to recognize and act on a low probability of return on investment as it pertains to a program’s adoption of an Agile based process.

Don't worry about the horse being blind, just load the wagon.
John Madden

  • See No Evil Hear No Evil Fever: This Fever is one whose existence is inexcusable in a software development organization. The primary symptom of See No Evil Hear No Evil Fever is when Agile decision makers reject expert input as it applies to adopting or tailoring of an Agile based software development process and continue on a trajectory that was likely read from a book. This Fever is very commonly present in those already suffering from Parrot Fever.

The highest form of ignorance is when you reject something you don't know anything about.
Wayne Dyer

Late Stage Fevers

The Late Stage Fevers are largely those that involve conditions where a program is trying to make the best out of a situation that has gone awry. In addition to just trying to get the job done under self-complicating circumstances, it is not uncommon to see tactics attempting to justify adoption of an Agile based software development process. The following diagram illustrates the Late Stage Agile Fevers.

  • Goofus and Gallant Fever: The symptoms this Fever can be best summarized by using prose familiar to many who have read the Highlights Magazine cartoon of the same name: "Goofus fails to capitalize on Agile’s advertised benefits by not following directions, but Gallant delivers his software program under budget and ahead of schedule because he does". You may not hear these exact words from afflictees of Goofus and Gallant Fever, but the message will largely be the same: you did not achieve expectations associated with adopting an Agile based software development process because you did it wrong. There might be some truth to the assertion, but no one can do Agile "right" if the program’s context was not in the Agile Sweet Spot from the start. Say what? No daily stand ups with a staff of 50+ non-colocated people? No requirements evolution with a customer that is 12 time zones away on a fixed price contract, with rigid requirements, and unaware that the program has even adopted Agile? Goofus and Gallant Fever is typically an escalation of Elbow Grease Fever where Agile has been forced into a program where it should not have been.

The search for someone to blame is always successful.
Robert Half

  • Road to Hell Fever: This Fever is typically present in organizations that intended to take advantage of Agile’s advertised benefits, but for whatever reasons, did not execute on a development process trajectory where they could be realized. As a result, an organization afflicted with Road to Hell Fever will exhibit symptoms of conducting business in a pre-Agile form in terms of continued non-colocation of staff, infrequent customer interaction, inflexible requirements evolution, and adherence to rigid schedules even after making a sizeable investment in training and reorganization. Similar to Goofus and Gallant Fever, the symptoms of Road to Hell Fever are very commonly late stage side affects of a previous Elbow Grease Fever infection where an Agile based software development approach was forced into a suboptimal context.

Ignorance is the soil in which belief in miracles grows.
Robert Green Ingersoll

  • Cook the Books Fever: This Fever typically afflicts those who were responsible for the sometimes sizeable investments necessary to transition an organization from using a "traditional" software development approach to one that is Agile based. Symptoms include creative approaches with which to measure productivity under Agile as well as falsely claiming benefits under the Agile umbrella that actually resulted from adoption of long recognized best practices. Cook the Books Fever is one of the most dangerous as its associated success stories have the possibility of causing Lemming Fever in other software development efforts, and fueling the spread of Agile Fever.

Fiction reveals truths that reality obscures.
Jessamyn West

The Antidote

Agile doesn’t cause the Fevers previously described, people do. Whether these people are well intended, have studied at the finest schools, or have high IQs, they are typically ignorant of Agile in many dimensions. They have little idea about the qualities of Agile which are the bases of its advertised productivity improving features, they believe that those improvements are guaranteed by merely adopting Agile, or have little idea that the extent of Agile’s ability to deliver benefit is highly dependent upon program specific context.

The antidote for the many forms of Agile Fever is education. Unfortunately, the infectees who are most desperately in need of such education are often unaware of what they don’t know about Agile, are unreceptive to learning about what they don’t know, or believe that those trying to educate them are simply village idiots who have not yet seen the brightly burning Agile light.

The objective of defining one’s software development process should not be to make it Agile-based, but defining it to be the most efficient and productive it can be given a program’s unique context. The Frog and the Octopus Model [3] proposes nine universal concepts that are relevant in some form to all software development efforts (The Frog) and a set of program unique variability factors (The Octopus) influencing those universal concepts. The Frog and the Octopus can be used to help guide the definition of a program’s software development process without the clutter of whichever silver bullet might currently be in fashion.

In fact, using a model such as The Frog and the Octopus is an effective way to engage people infected with Agile Fever because it removes reference to Agile from the discussion of software development altogether. Instead of putting an infectee immediately on the defensive by suggesting, for example, that an Agile based software development process may not be the best fit, a better tactic is to discuss the applicability and value of adopting development strategies in a general sense. Those discussions might include considerations that are typically associated with Agile based processes such as requirements flexibility, schedule elasticity, extent of customer engagement, ability to co-locate the staff, and any other attributes that might be relevant to the program’s context.

Once the applicable development considerations have been identified, they each need to be evaluated for relevance, value, and cost of realization without any discussion of being associated with a particular development approach. Adoption and tailoring of an Agile based software development process should be done on the basis of return on investment as opposed to fashion. Because the cost and value of adopting Agile are variable and depend upon program specific context, the benefits realized by one program are not representative of what all programs should expect by doing so.

While the Agile Fevers identified and characterized in this article were written using a tongue in cheek style, the associated examples of misuse and misapplication of Agile are genuine and might be occurring on a software development effort near you. As opposed to these problems being a case of industrial sabotage caused by rogue employees planted by a competitor, they are tragically self-inflicted and often continue even amidst the availability of experts who are capable of rectifying them. Until the unqualified, the inexperienced, and the unbiased are reconsidered in their roles as decision makers pertaining to adoption and tailoring of Agile based software development processes, there will be little hope of eradicating the dreaded Agile Fever.

References

[1] Death by UML Fever.
Alex E. Bell, Death by UML Fever, ACM Queue, 2(1):72-80, March 2004.
[2] Kruchten, P.B. 2010. Contextualizing Agile
Software Development. EuroSPI 2010 conference
(Grenoble, France, September 3-5, 2010).
Available here
[3] The Frog and the Octopus: A Conceptual Model of Software Development
Philippe Kruchten

About the Author

Alex Bell has over 30 years of software engineering experience working for Boeing, Raytheon, and Hughes Aircraft. He has been involved in all aspects of software development in the context of shipboard, airborne, and land based C4ISR programs. He graduated with a Bachelor of Science degree in Systems Science from UCSD, has authored a number of similar articles condemning insanity in the software industry, and is a Technical Fellow at Boeing.


1 Fragilista is a term describing an Agilista who is thin skinned and lacks the strength to control his or her emotions in response to a perceived attack on Agile.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • It's good to have a critical look at Agile

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I cover a lot of the same dysfunctions here: postagilist.wordpress.com/2011/04/06/rhetorical...

  • Its not really about Agile

    by Curt Hibbs,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Despite the title, this article is really not about Agile at all. It is really about hype and incompetence and the misuse of the same.

    Try taking every instance if the word Agile and replacing it with "Design Patterns", "Technical Debt", or even "UML" -- the entire article still makes perfect sense.

  • Re: Its not really about Agile

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm with you on Design Patterns, since it's run by essentially the same people (Agilists).

    Technical debt and UML? Really? Is there a UML manifesto? A certified Technical Debt master?

    Few clans and cliques are as closed minded and insular as the Agile movement.

    The fact that there is a movement at all (fueled by a manifesto no less) makes it seperatist by nature.... Saying that everything is plagued to the same degree as the Agile movement when it comes to parrotism and separatism, etc, and willful ignorance, does a disservice to these other fields

    PA

  • Re: Its not really about Agile

    by Curt Hibbs,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I just picked three topics at random just to illustrate how the text of the article could apply to anything -- I wasn't saying those examples were necessarily valid.

  • Yes it is...

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, you are using a straw argument, to try to shift the blame away from agile.

    Agile is guilty of these sins, and it's simply untrue that everything else suffers from them in similar amounts.

    Sorry, "everyone does it" is not only not true, it's a very lame attempt to deflect valid criticism from a very guilty party (the Agile movement).

    The Agile Apologists pull these stunts constantly -- perhaps that can be added to the list.

    Nice try.

    If the Agilists would learn, sometime, instead of constantly trying to ignore and shift the blame, perhaps the movement woulnd't be still riddled with all these dysfunctions.

    PA

  • misguided?

    by Terry Bunio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I usually find myself a proponent of questioning Agile practices and examining the real value of Agile. (but I honestly believe that Agile practices are usually the best option) I expected that this article would be aligned to my thinking but I was wrong. This article should be re-named the 'Methodology Fevers'. In my opinion, all of the fevers can be observed by following any methodology too closely and without a critical eye. I didn't see one fever that was only applicable to Agile.

    It is unfortunate that the author chose to centre in one one methodology when the same fevers apply to all. That includes the fervent criticism of Agile.

  • Yet another "everyone does it" comment

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Wasn't that topic already covered in the comments above?

    I thought I'd share a list I found on wikipedia recently. en.wikipedia.org/wiki/Agile_software_developmen...

    Another criticism is that Agile’s drive to impose itself into business systems is cultish in its nature. Faith-based similarities include:

    Agile claims absolute universality, of being applicable to all levels of business, and useful to all members in any given organization.

    Agile claims infallibility (that its technique is absolutely correct as-is, and not to be changed or questioned).

    Agile requires meetings that involve ritual activity (“planning poker”, for example).

    Agile requires system-specific jargon for comprehension (Kanban, story points, scrum, epic, etc.), terms which are not readily understood by the layman or un-initiated.

    Agile attempts to create an ideological “monopoly of method”, excluding alternatives, competitive models, and any mixture or dilution of its core principles.

    Agile seeks to become closely allied with the “heads of state” (business leaders, in this case) to gain favor, authority, and reinforcement of its claims.

    Agile employs professional, full-time clergy (i.e. “Scrum Masters”) who alone possess the appropriate credentials of education and formal ordination (e.g. Agile certifications).

    Agile attempts to gain new members through viral reproduction and the socialization of the un-initiated into the ranks.

    Agile tries to minimize diversity of opinion by accepting different views within the system only rather than through the formation of new methodologies or alternatives

    PA

  • the link

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

  • Re: Yet another

    by Terry Bunio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think we may need to agree to disagree. Can you repost the Wikipedia link? I couldn't follow it.

    I am DBA/PM that has been on traditional and waterfall projects for over 7 year apiece. (traditional longer...)

    I first must state that I also disagree with Scrum and do not follow Scrum in how I prefer to conduct Agile projects.

    All of your other comments on Agile are, in my humble opinion, incorrect. Are they your own comments or are they from a specific source?

    Again to illustrate my point, I can create a set of opposing statements about waterfall:

    - Traditional Waterfall claims absolute universality, of being applicable to all levels of business, and useful to all members in any given organization.

    - Traditional Waterfall claims infallibility (that its technique is absolutely correct as-is, and not to be changed or questioned).

    - Traditional Waterfall requires meetings that involve ritual activity (For example, Specification sign-off rituals and project status meetings)

    - Traditional Waterfall requires system-specific jargon for comprehension (WBS, Earned Value, Use Case), terms which are not readily understood by the layman or un-initiated.

    - Traditional Waterfall attempts to create an ideological “monopoly of method”, excluding alternatives, competitive models, and any mixture or dilution of its core principles.

    - Traditional Waterfall seeks to become closely allied with the “heads of state” (IT Leaders, in this case) to gain favor, authority, and reinforcement of its claims.

    - Traditional Waterfall employs professional, full-time clergy (i.e. PMI-ceritifed Project Managers) who alone possess the appropriate credentials of education and formal ordination (e.g. Traditional Waterfall certifications).

    - Traditional Waterfall attempts to gain new members through viral reproduction and the socialization of the un-initiated into the ranks. Specifically the inclusion of PMI certification as criteria for new hires.

    - Traditional Waterfall tries to minimize diversity of opinion by accepting different views within the system only rather than through the formation of new methodologies or alternatives

    My main point is that promoting these extreme points of view is misleading, incorrect, and not constructive. Following either the waterfall or agile methodology too closely will cause the same problems.

    Neither is totally evil, neither is fully correct.

  • Re: Yet another

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What you are doing, is another well known antipattern. You are building up a strawman of waterfall and then bravely knocking it down.

    As do most agilists -- I cover that in my post here: postagilist.wordpress.com/2012/06/13/the-perenn...

    I would grant you that traditional business (so called waterfall) does try to align itself with heads of state but that is the only similarity.

    Are there 2 day waterfall master courses? Is there a waterfall movement? Is waterfall inflexible? No, except for the straw versions (see above).

    As per the wikipedia link it should appear soon (I pasted it into another message that went into mod Q) in the meantime just google for agile criticism wikipedia and it will take you right to it.

    PA

  • Re: misguided?

    by Alex Bell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    As PostAgilista already stated, your "issue" has already been addressed in his previous post. If what you were saying was true, I would have written this article long ago. With all due respect, my guess is that you are really a Fragilista trying to masquerade as an objective reader.

  • Re: misguided?

    by Terry Bunio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for the reply Alex. We will also have to agree to disagree. Let me just say I don't believe that the issue has been dealt to my satisfaction. Just because you state that it has doesn't mean it is true. Also trying to name me a Fragilista is slightly disappointing. I was trying to put forth an opinion for discussion, and you have responded in a similar way to the Agile purists you criticize. Who is now not open to alternate approaches and diversity of opinion?

    As PostAgilist mentions in his blog, we should encourage discourse in the following manner:

    1) Respecting the opposition

    2) Realize that there are multiple paths to success for any given problem

    3) Decisions will be made based on reason and practicality, not on academic, philosophical, bullying, emotion, demonizing or any of the above mentioned anti patterns.

    4) Argue your case — nicely — supported by facts.

    So further to point 4, what are your facts that Agile projects are more susceptible to these issues? What Agile projects have you been involved with? How large were they and what did they deliver? Were they project or product development? What Agile or XP practices did they follow? What traditional practices did they follow?

    Terry

  • Re: misguided?

    by Curt Hibbs,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Terry, I agree with completely, and I go back to my original point. This is really about hype and misuse.

    Are there people in the Agile community that are guilty of the types of hype and misuse described - certainly there are!

    Is that problem universal with everyone in the Agile community - absolutely not!

    Overall, is the hype problem a serious issue Agile community - this one is a lot more subjective. I tend to think not, but it probably heavily depends on precisely which subgroups you interact with the most.

    In any case, it is helpful to be fact-based. It is not helpful to engage in ad hominem attacks.

  • Re: Yes it is...

    by Curt Hibbs,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, you are using a straw argument, to try to shift the blame away from agile.

    Agile is guilty of these sins, and it's simply untrue that everything else suffers from them in similar amounts.

    Sorry, "everyone does it" is not only not true, it's a very lame attempt to deflect valid criticism from a very guilty party (the Agile movement).

    The Agile Apologists pull these stunts constantly -- perhaps that can be added to the list.

    Nice try.

    If the Agilists would learn, sometime, instead of constantly trying to ignore and shift the blame, perhaps the movement woulnd't be still riddled with all these dysfunctions.

    PA


    You've completely misunderstood my intent (or, more accurately, I have probably done a poor job of communicating it). I do not deny that hype and misuse occur in the Agile community. I was merely pointing out that what Alex has done was to document something like a design pattern on hype and misuse, and that this pattern can be applied to any area where hype and misuse is rampant. I saw that as a useful contribution - beyond the specific Agile issue.

  • Re: Yes it is...

    by Leung Michael,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I am confused. Is it the Agilist (people) that is causing the Fevers and not Agile in the original post?

  • Re: Yet another

    by Curt Hibbs,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Agile claims absolute universality...
    Agile claims infallibility...
    Agile requires meetings that involve ritual activity...
    Agile requires system-specific jargon for comprehension...
    etc.
    PA


    You're speaking of Agile as if there is a single voice and only one point of view. You also imply that certain things just plain bad (like the use of jargon), which I believe is debatable.

    Believe it or not, there are many people in Agile community who just want to know what works (and in what context), and what are the general principles involved so that have some idea how to apply this things in different contexts.

    This means being open to ideas no matter what their origin.

  • Re: Yet another

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That list was from Wikipedia.

    As per jargon, I do think there is a problem with jargon the way it is frequently used in agile...

    I cover that in this post postagilist.wordpress.com/2012/06/12/orwell-on-...

    I do believe that everyone should be open to ideas no matter their origin so agree with you on that

    PA

  • Re: misguided?

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That's all true and I look forward to a good discussion.

    However I also list as an antipattern (#7) asking for proof of others without supplying your own first.

    If you supply your own evidence in that area, then it's fair to ask the same of others.

    Agilists constantly demand proof of this or that, from others, but supply no proof that agile itself works. The recent Voke report surverying 200 companies strongly suggests that it doesn't.

    PA

  • Re: misguided?

    by Terry Bunio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for the reply PA.

    I would be happy to share my own personal experiences with Agile and Traditional. I find surveys for both the pro and anti Agile perspective less valuable as they don't allow people to provide context or examples with their answers.

    As to what is fair to ask in the way of proof, I would like to point towards the book 'Candle in the Dark' by late, great Carl Sagan. Carl Sagan pointed out correctly that it is the reponsibility of the person promoting the idea to provide the facts. It is not the responsibility of the opponent to provide facts to disprove the idea. Typically people in pseudo-science would state that if their proposed idea is untrue, then science should be able to provide facts to clearly disprove the proposed idea. This principle is core to the objective scientific method. (It is no surprise that people propose these positions, one can look at Euler's last theorem as an example of how much harder it is to prove negative postulation than positive postulation)

    This article proposed that these fevers are more predominant in the Agile methodology than other methodologies. The primary responsibility is not mine to prove that this statement is untrue.

    I also agree that Agile purists also propose statements which are untrue of waterfall without any facts as well. I would be equally critical of a pro-Agile article.

    Terry

  • Re: misguided?

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    First of all, I think the issues that Bell raises are self evident.

    It doesn't take a lot to find the parrotism, etc, found in agile.

    But more importantly, Bell is rejecting Agile, in many ways, because there is NO PROOF that agile is effective.

    Since you feel that, someone proposing something should prove it, then, the agile field should have been proving things all along.

    They haven't.

    So if Bell comes out and says, oh, there is no proof that Agile works, there is no proof that Scientology works, then, it would be unrealistic to say that he should then have to prove that Scientology does not work.

    In any case Bell is listing fevers, not listing the amounts that they occur in the population.

    Clearly the fevers exist, to what extent is not a topic of this article, and that is the data you are asking him to provide.

    It seems nonsensical.

    I think there is agreement, from Curt, at least, that these fevers DO exist in the agile community, so let's get on subject here and talk about how to eradicate the fevers from the agile community, not get into red herring distractions as to whether other communities also have a few of these fevers, or what the exact population of agilists that suffer from them are.

    PA

  • Re: misguided?

    by Curt Hibbs,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Agilists constantly demand proof of this or that, from others, but supply no proof that agile itself works. The recent Voke report surverying 200 companies strongly suggests that it doesn't.


    Wow, are you aware of how seriously flawed that survey was?
    Here's one of the many analysis:
    continuousdelivery.com/2012/07/voke-report-agil...

    For me the "Agile works" or "Agile does not work" is way too binary. The real question is what are the level of benefits seen. The answers are all over the map, which just illustrates that there are way too many uncontrolled variables.

    However, statistical analysis can still make sense of that kind of data. This was done for the book "The Business Value of Agile Software Methods" which analyzed and aggregated the reported results from a large number of separate studies. The result clearly shows substantial benefits, on average:
    www.amazon.com/Business-Value-Agile-Software-Me...

  • Re: misguided?

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    No, I'm not aware of how seriously flawed that survey was... I would post links but I keep getting mod Q'd for posting links.

    I am aware that the blog of the person you posted to, is heavily biased in favor of agile, and went on a rant against Voke's conclusions.

    Voke's sampling of 200 companies is the largest independent analysis that I'm aware of, and they report that only 2% of the companies could identify identifiable success with agile.

    Naturally the Fragilistas were up in arms about it and wrote articles like you linked to, but that doesn't change the conclusions of Voke in that regard.

    Since you are making an (unsupported) assertion, that, the Voke report, is somehow stastically flawed, can you support your assertion in that area ?

    How specifically was it flawed?

    Agilists always claim that it's an "empirical" process yet when the empiracal data is not in their favor they automatically say that the empiracal data is not valid.

    No surprise there -- I think that's part of Cook the Books Fever right?


    PA

  • voke report

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Since I couldn't include this much text in my previous response:


    In any case here is a summary of the Voke report (google adtmag voke to find it)

    ---

    The survey results include the following (verbatim from the report):

    Out of over 200 survey participants, we received only four detailed comments describing success with Agile.

    40% of participants that use Agile did not identify a benefit.


    Some participants (7%) also noted that Agile developers were happy due to less future planning and less documentation.

    Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance.

    Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.

    ---
    PA

  • Not A Cult

    by Robert Barth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The fact that there are a number of defined Agile "processes" (Scrum, Kanban, XP, etc.) pretty much shows that there's no "one way to do it" by those who think Agile is worthwhile.

    The manifesto sets out a few simple statements that the people who created it believe lead to a better software engineering experience and believe will lead to better crafted, more maintainable software products that actually deliver value to their customer in a timely manner. It's hardly a cult.

  • Re: Not A Cult

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Really? XP was the original Cult, and the one that laid out the path of taking things on faith -- though it is mostly dead, it's roots live on in the marketing efforts of Scrum.

    Scrum is the most cult like with the rituals, the scrum masters, the certifications, the do it by the book mentality and all the rest.

    Kanban is the least populated of the agile space, however, David Anderson has made some pretty outlandish statements, and, Kanban was taken from manufacturing and has little to do with software. Whether it's a cult or not is too early to say for Kanban, but certainly the other two have proven their cult nature.

    Merely saying that something is not a cult doesn't make it not a cult.

    I know that Agilists give the same credence to mere statements and opinions as they do facts, but that is a dysfunction that we don't all share.

    I'm sure Scientologists believe that it isn't a cult. Most everyone else thinks that it is.

    PA

  • Re: misguided?

    by Curt Hibbs,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    I am aware that the blog of the person you posted to, is heavily biased in favor of agile, and went on a rant against Voke's conclusions.

    Voke's sampling of 200 companies is the largest independent analysis that I'm aware of, and they report that only 2% of the companies could identify identifiable success with agile.


    Just because someone is a fervent supporter of Agile doesn't mean they are incapable of doing a fair analysis.

    Using that logic I could say that because you are a fervent detractor of Agile means you're incapable of recognizing the flawed nature of the survey. But that would not be a valid assertion.

    The 2% success rate id highly suspect -- that would be 4 companies. I personally know of an order of magnitude more than that.

    So what exactly is the criteria for success? Is it less than 10% improvement? less than 50% improvement? less than 100% improvement? Was the criteria they picked reasonable?

    And who, specifically, did they survey? Alex (the author of this article) and I work for the same company. If you surveyed Alex on whether Agile was successful, he'd probably say no because he had a bad experience. If you surveyed me I would say its been very successful.

    Anyway, I'm going to let you have the last word. I've got too much work piling up to continue being distracted. As I've said over and over, my only intention was to say that I thought Alex had identified a new pattern for hype and misuse.

  • Re: misguided?

    by Terry Bunio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for the reply PA.

    There is nothing in the world self-evident except for taxes and death. Self-evidence is a prop when proof cannot be provided.

    I agree that the Agile group should have been providing proof all along and they are equally if not more in wrong as far as providing proof. But that unprofessionalism does not excuse others from being professional. The 'he started it' argument between sibling adolescents should remain there. Each proposal must stand on its own with its own facts.

    How did we get to the question of whether Agile works? (this is another chapter in Sagan's book that once the proposal's facts are under question, the proponents change the question)

    And no it isn't non-sensical and Bell is not just listing fevers that occur in the population. If he called it Software Development or methodlogy fevers I would have no issue.

    He called it Agile fevers without any facts to back up that the fevers afflict Agile projects more than other projects. The title of the article implies the distribution he feels they occur in the population.

    I agree that the fevers absolutely exist and that they absolutely exist in the Agile community. No question.

    What is unproven if whether they exist to a greater extent in Agile than in other methodologies. That is the current question that bears supporting evidence.

    So far I hear crickets.

  • Re: misguided?

    by Terry Bunio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Agree 100% Curt. I also classify myself of a hybrid-methodologist. I take part of all different methodologies that support each specific project and team I currently have.

    I like to describe my Agile style as just finding better ways...

  • Re: misguided?

    by Post Agilist,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is just the kind of Fragilista response that Alex anticipated when he wrote the article.

    Your arguments, such as they are, are illuminating and illustrative.

    You don't care about eradicating dysfunction in the agile community, you only care if it's greater somewhere else, so you can conveniently sweep it under the rug.

    Hey forget about the crime rate in Boston, it's worse in Zimbabwe! Whew, I'm relieved.

    On a side note I was discussing with a friend how people who are engaged in the practice of monetizing agile should state so in their responses on the internet, just like stock advisers who talk about stocks disclose whether they have an open position on it.

    Regards,
    PA

  • Re: misguided?

    by Terry Bunio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It is unfortunate that we are back to the name-calling stage. Really? After all we have discussed on the importance of professional discourse without demonizing the opposition. (Your words, not mine)

    I care about eradicating dysfunctions in all communities. I have already stated that I acknowledge these Methodology fevers do exist in the Agile communities as well. I'm not sure how you interpret this as sweeping it under the rug? I'm not stating that they exist more elsewhere and I'm not trying to sweep them under the rug.

    We in the Agile community will continue to work to address these and eradicate them. My comments were intended to ensure you don't have a false sense of security and sweep them under the Waterfall rug. They exist in that methodology too, I suggest you work on eradicating them on your projects as well.

    Not sure what to make about your comment on monetizing Agile. This comment can be made on any speciality by consultants. I monetize Data Architecture as well. You and Alex monetize traditional project management approaches.

    So in the absence of addtional facts or context, I'll continue to take this excellent advice from Alex and address methodology fevers on all my projects, I encourage you to do the same.

  • Thanks for the article on agile fever - fun, but educational too

    by Diane Strode,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for this article. It's a breath of fresh air.
    I have both a Masters degree and a PhD - both studying aspects of agile. I personally think it is a good set of tools and ideas for developing software, however I have never been an evangelist (perhaps because I have too much objective science in my blood). I have nothing against agile practices, tools, techniques, practices, principles, theories, or philosophies. I too find some of the pro-brigade to be rather tiresome. I also felt this during the UML fever phase. Keep up the good work on providing some balance!

  • Re: misguided?

    by Alex Bell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    First....and foremost, I would like to publically apologize to Terry for not being nice. He is right on the money in his criticism of me. Those who know me will attest to this being uncharacteristic of me, and I was at the end of a not so good day when I replied. But, this is no excuse. As far as debating this issue, I would prefer discussing it on the phone or privately via email if you are interested.

  • Response to some previous commentary

    by Alex Bell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I was just going to let this die, but a few anonymous emails came my way suggesting that I owed Terry a response. So, here is what I hope to be a very structured, logical, and nice response to what I interpret his question/comment/point to be.

    1) First, I do not know the PostAgilist, but he has already provided this forum with all of the information necessary to address the issues and concerns as I have understood them to be. He understood the deeper message of “Death by Agile Fever” far beyond the tongue in cheek Fevers which are only indicative of a larger problem.

    2) I am not anti-Agile, I am anti-waste.

    3) I have seen all of the documented Fevers with my own eyes and had to trim out about five others for the sake of article brevity.

    4) The article is not anti-Agile as stated in the fourth paragraph:

    Before any Fragilistas who might be reading this article get their knickers in a twist due to a belief that it is an attack on Agile and must be avenged with flaming commentary against its author, fear not.

    5) I do not blame Agile itself for any of the madness that is the subject of the article as stated in the first sentence of “The Andidote”:

    Agile doesn’t cause the Fevers previously described, people do. Whether these people are well intended, have studied at the finest schools, or have high IQs, they are typically ignorant of Agile in many dimensions.

    6) I would like to think that we are all on the same page at this point and that the issue to debate is whether it is legitimate to replace the word “Agile” with Waterfall, for example, in “Death by Agile Fever”. Yes, one could do a global substitution in the article and some of the fevers might ring true, but that is not really the point of all this.

    7) As the PostAgilist clearly understands, there is much more to this than word substitution in an article and claiming that Agile is just like the crazes or fads that might have preceded it. Agile has become religious, cultish, and has spread throughout software organizations without precedent as I have observed in my 30+ year career. Since Terry used Waterfall as a comparison, let me do the same in real life situations where I have replaced Agile with Waterfall:

    - How many times have any of you ever seen or heard of senior management’s performance criteria being measured by the number of their programs that adopt Waterfall (without considering that the benefits of Agile are variable and based on specific context)?

    - Let’s say we have a multi-million dollar program that has been under development for over 5 years. This program is fixed price, the requirements are static, the customer is on the other side of the world, and is not integrated with the development team. Let’s say that this program is working on its last software delivery. How many times have you heard of a program like this adopting Waterfall on the last build to “get done faster”?

    - How many times have you heard of people making concocted claims that they have saved programs tens of millions of dollars by adopting Waterfall in favor of methodologies or tools that were previously being used, and people actually believing it?

    - How many times have you been working a fixed price software development proposal with static requirements, an inflexible schedule, the cost of software is deemed to be too high, and a non-technical person proposes that usage of Waterfall could help reduce the cost (without understanding anything about the development context)?

    I could go on and on with Agile misconceptions, ignorance, and hype examples that are the fault of people, their self-interests, their ignorance, and not Agile itself. Anyway, if you believe that the examples above have never been heard of in a Waterfall context because only an Agile context is worthy of them, well, I guess we are done.

    So, for many of the reasons already stated by the PostAgilist, and based on the few examples of Agile brainwashing I have provided above, I do not believe that it is legitimate to replace Agile with any other word in my article. But as I already suggested, this position is hardly worth debate or expenditure of energy, and is just a distraction from the real problem.

    From my knothole, the Agile movement has brainwashed people like nothing else like we have seen in the history of the software industry. That brainwashing does not confine itself to the technical ranks like UML Fever largely does, but transcends into the management ranks with negative consequences as I have never seen before. The result of this brainwashing causes bad decisions, wastes money, and makes my job much more difficult…all the while that the people fueling the brainwashing fail to acknowledge it or take responsibility for it (Yes, I gave that small child scissors, but I did not tell him to run with them). So, there you have it…I hope I answered the comment/question/issue.

  • Hope not a stupid question

    by Leung Michael,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Your explanation is clear and helpful. May be, I should start examining if any of our colleagues has caught such a fever.

    You referred to PA’s postings but on 13/09/2012 06:11, PA said that you are “rejecting Agile, in many ways, because there is NO PROOF that agile is effective” and works.

    If it is not effective and not working at all, we should abandon it altogether instead of just eradicating the fever. Which path should I suppose to take?

  • Re: Response to some previous commentary

    by Horia Slusanschi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One key fever that I think Alex has only just started to characterize in this last comment is what I'd call "System Blindness" fever. The afflicted believe that "Agile" is just another "method" to "deploy" (in the "pants down, bend over, here comes the new method" kind of way ;), without much consideration at all, if any, of the systemic context in which it might be applied. They care far more about the "label" being applied to Projects (which is fairly easy) rather than perfecting an Agile mindset and practicing continuous improvement throughout the organization and across divisional boundaries (which is fiendishly hard).

    We need a system for transforming mediocre teams into outstanding teams. Agile concepts and habits show great promise in helping organizations to achieve this nearly magical feat - provided people consider the objective of the exercise to be creating more delight for customers, with more joy in work for people. We need to figure out how to inspire more people to develop a more balanced and nuanced understanding of agility, its values, principles and habits - rather than just ending up with lots of religious fervor and zeal.

  • Re: Hope not a stupid question

    by Alex Bell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Leung,


    The answer to your question is in "The Antidote" section:

    The objective of defining one’s software development process should not be to make it Agile-based, but defining it to be the most efficient and productive it can be given a program’s unique context. The Frog and the Octopus Model [3] proposes nine universal concepts that are relevant in some form to all software development efforts (The Frog) and a set of program unique variability factors (The Octopus) influencing those universal concepts. The Frog and the Octopus can be used to help guide the definition of a program’s software development process without the clutter of whichever silver bullet might currently be in fashion.

    "Death by Agile Fever" is not about Agile being good or bad, valuable or not valuable. It is all about Agile based development processes being misapplied by the ignorant, the misinformed, and those with self interests. So, you need to do an inventory of your specific context and decide what tactics are the best for developing software to meet your customer's needs, your customer's schedule, your budget, etc, etc.

  • Re: Response to some previous commentary

    by Terry Bunio,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Alex, thanks for the response. I only checked back today into this discussion after a while away.

    I do agree that these situations/fevers exist perhaps more in the Agile arena than others. (Although all methodologies can suffer to them to a degree)

    In many ways I think we all manage projects in the same manner, but are disagreeing on language and semantics.

    Terry

  • Re: Its not really about Agile

    by Taunting French Guard,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think you just demonstrated Simon Said perfectly

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT