Agile Anti-Patterns - Agile Malpractice
Many of the XP ‘mantras’, when viewed out of their historical context, appear absurd. However, lack of understanding about the context also makes teams and individuals act in absurd ways when they cling too tightly to the letter of the practice.
This is the third article in a series on ‘failure modes in the implementation of Agile Methods’.
One of the reasons for the success of EXtreme Programming (XP) is that its authors gave pithy names to its practices: Unit Test First, Refactor Mercilessly, Do The Simplest Thing That Could Possibly Work, etc. This allows individuals to quickly develop an understanding and practitioners to share a common language for the things that they do.
Interestingly, many of the phrases, when viewed out of their historical context, become absurd. ‘Test Everything That Could Possibly Break’[1], for example, has at least these four converses:
- Test nothing that could possibly break – this will keep some stakeholders blissfully ignorant for a while. It also requires no effort in order to conform, since not doing any testing at all would satisfy this edict
- Test everything that could not possibly break – similar to the point above but does require effort to decide what could not break and then some testing effort
- Test everything that could possibly not break – a less restrictive form of the point above
- Test some things that could possibly break – but which ones? How do you choose?
These formulations are, to varying degrees, pointless, aimless, devious and doomed. It is unlikely that anyone of sound mind would propose them as a software development principle.
When presented in these terms, ‘Test Everything That Could Possibly Break’ can be seen as obvious to the point that someone without the historical context might wonder why anybody felt the need to state it2. The same is true for most of the other XP practices.
However, the lack of understanding about the context of these phrases also makes teams and individuals act in absurd ways when they cling too tightly to the letter of the practice, rather than perceiving them as studies towards greater skill or team effectiveness and as a means of structuring the unlearning of inappropriate habits.
Just as a student of the classical piano is taught various fingering rules, such as ‘avoid using the thumb on black notes’ and ‘avoid crossing the fourth finger over the fifth’ but is then required to put these rules aside when playing a great deal of the music of the masters – even finding pieces that are written to force precisely the proscribed behaviour – so too can the ‘classical XP rules’ be ‘broken’ (gasp!) as the practitioner understands and internalises them.
To adhere religiously to practices without taking the time to understand their effects and interactions is much like an amateur musician ‘practicing’ a piece at full speed, faithfully reproducing the same mistakes over and over again. In order to eliminate the mistake and improve the performance, they must consider the point of error, play the problematic section through slowly and thoughtfully until the problem can no longer happen, and then join it cleanly to the preceeding and succeeding sections.
Similarly, the experienced agile methods practitioner will be sensitive to a practice going awry or simple being inappropriately operationalized, will make the effort to understand why and will adapt the practice and it’s supporting / supported practices in order to recuperate effectiveness.
1 This phrase refers to the production of automated unit tests which operate at the level of a method / function or class / module.
2 It should be borne in mind that although few would advocate no testing at all, the production of automated unit tests still sadly appears to be eschewed by a significant fraction, if not the majority, of those involved in software development.