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 - Premature Pragmatism::journal

Agile Anti-Patterns - Premature Pragmatism

Lance Walton - Saturday April 8, 2006

It is easy to make superficial sense of XP and difficult to make real sense of it as a whole without actually doing it.

This is the second article in a series on ‘failure modes in the implementation of Agile Methods’.

Practitioners of XP are often faced with individuals or teams who like the general notions and benefits of Agile Methods but who want a ‘more pragmatic approach’. The irony of this is that pragmatism abounds in all well implemented Agile Methods and it is often the non-Agile side of the debate that is most notable for its ideology and dogma.

This is frequently not recognised because of the way that Agile Methods are considered to be interlopers in the ‘conventional’ world of software engineering practice which is so embedded that its basis is not questioned1.

With regard to pragmatism, part of learning something new is constant attention to its detail. Once the thing is learned, we often take a more relaxed approach to it because it has been experienced, understood, internalised and thence becomes unconscious.

The danger is that those who have not practiced the practices, frequently believe that they can short-cut the process and go directly to a ‘more pragmatic approach’. The problem is that no matter how interested they are in improving their situation, their view of a pragmatic compromise is almost certainly rooted in their current, often tacit methods2, rather than in a Thesis-Antithesis-Synthesis dialectic and they therefore usually lack the appropriate experience required to make the judgement.

It is easy to make superficial sense of XP and difficult to make real sense of it as a whole without actually doing it and therefore experiencing it. Agile Methods are for practitioners, not methodologists. The compromised version of XP obtained through premature pragmatism avoids the need to confront the issues – not of XP but of the way we build software in general – thereby removing the sense-making opportunities that ultimately provide the real benefits of a synthesized and not prematurely ‘pragmatic’ approach.

1 Craig Larman has an excellent paper that casts this misapprenhension in a rather different light.

2 This is somewhat reminiscent of the story of the drunkard who is looking for his keys underneath the streetlamp because that is where the light is.