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.