Deprecated: Function set_magic_quotes_runtime() is deprecated in /home/raedan/public_html/textpattern/lib/txplib_db.php on line 14
State of Flow: Agile Anti-Patterns - Agile Malpractice::journal

Agile Anti-Patterns - Agile Malpractice

Lance Walton - Thursday May 4, 2006

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:

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.