“Agile” and “agile”
As I work on Implementing Agile Values and Principles, the follow-up book to Understanding Agile Values and Principles (UAVP) (https://www.infoq.com/minibooks/agile-values-principles/), I have been editing out material that, while of some interest, does not really advance the point of this new book. I’ve decided to post this material, bit by bit, here on Medium. This is the second of these.
— — — — — — — — — — — — — — — — — — — — — —
Little “a”
The word “agile” has definite meaning outside of its Manifesto application. It seems reasonable to look a bit into its generic definitions since they are, of course, related to its specific application to software development. Among the definitions and synonyms used in dictionaries for the word “agile” (and “agility”) are “nimbleness,” “lightness,” “start, stop and move quickly in different directions,” “quickness of motion,” “alertness,” and “spry.” Wikipedia says “agility” “requires a combination of balance, coordination, speed, reflexes, and strength.”
I rather like what Wikipedia says since it goes beyond what synonyms convey. For example, being quick or fast without “balance” is going to get you in trouble regardless of what you are trying to do. Stability is required to allow that quickness to be more than ad hoc motion. Likewise, you can think of “coordination” in a few ways, but, basically, being quick or fast without appropriate relationship and coordination between the things that are moving will eventually lead to instability.
I see “strength” as an interesting and perhaps often not considered dimension of agility. Agility, both physically and mentally, seems to require strength of some sort to maintain balance which, as already noted, maintains stability. For example, climbers and gymnasts are people I consider to be very agile physically, yet their sports require considerable strength, though applied in small, focused ways rather than the raw strength of weight-lifters. Mentally, I might use the word “discipline” to describe the kind of “strength” required, but, again, small and focused as opposed to raw power.
Big “A”
Periodically, I hear people say that there is no real definition of “Agile.” The position in this book — as in the prior one — is that such a definition exists in the form of the Manifesto’s values and principles (V&P). Since the Manifesto’s creation, what makes an approach “Agile” is that its behaviors and practices embody the V&P. Therefore, understanding the V&P is fundamental in using or implementing any method or practice. A lack of understanding of (and commitment to implement) the V&P will result in a far less satisfying Agile experience than would otherwise have been possible.
However, just saying that “Agile” means committing to the V&P may not be viewed as an adequate “definition” in the sense of a sentence or two which highlights the key features of taking an Agile approach to product development. During some work on an attempted IEEE standard for defining the relationship between stakeholder and supplier under an Agile approach, the following definitions were proposed:
“A software engineering method that employs iteration of analysis, design, construction, testing and delivery and that depends on continuous, operational feedback to determine and adjust the requirements to be met by the software. Caused by feedback and enabled by iteration, the capability to deal with continuous change in requirements and plans is a key characteristic throughout a project that uses an agile method.”
“An incremental and iterative (evolutionary) approach to software development, which is performed in a highly collaborative manner, with ‘just enough’ ceremony to produce high quality software which meets the changing needs of its stakeholders.”
As helpful as these statements may be, I believe that the “definition” of Agile is represented best by those V&P as inconvenient as that may be from the line-or-two approach of a dictionary definition.
Yet, even with this broad “definition,” there has been some debate about defining “Agile”. The argument is that there cannot be any “true” anything since any definition though useful, is still wrong at least in the connotative sense. The statement “All models are wrong; some models are useful” is attributed to George Box (https://en.wikipedia.org/wiki/All_models_are_wrong). How people use a term and what they think it means will carry more weight than what any formal “definition” says. Ideas associated with terms change to suit needs and purposes which, after a while, amount to enough variations that it is hard to tell which is “right.” But, as Box suggests, there is usefulness in (some) models even if none are “right.” The problem remains, however, to determine which are then “useful.” In this regard, what may be most effective is to see what (aspects of) definitions are used most frequently.
Because it is the central reference for (almost) every proponent of an Agile approach, the Agile Manifesto, then, can be viewed as the primary source. But the Manifesto is not the only source since, beyond the Principles, a large variety of practices have become commonly associated with “doing Agile.” The original group of people at the Snowbird meeting had a variety of techniques associated with their individual approaches. Many, in one way or another, have become part of what people view as “doing Agile” since many people support and practice them.
There is, however, a hierarchy from Values to Principles to practices/techniques. Without the V&P, individual or sets of practices, while useful on their own, can be too easily transformed into something that misses the overall point. Indeed, this seems to be what many organizations tend to do, i.e., pick and choose practices, as if from a list of ingredients, but without an understanding of the recipe for effectively combining them or what alternate ingredients will work.
Similarly, the Principles alone without the Values, while more broadly guiding than just practices, can still fall prey to modification and menu selection. That is, if one removes, or strongly modifies, a few Principles, how much does it hurt what it means to be effective in pursuit of an Agile approach? (I have often heard the term “stealth Agile” applied to situations where practices are dropped or radically “tailored.”)
