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 - We Know Absolutely Nothing::journal

Agile Anti-Patterns - We Know Absolutely Nothing

Lance Walton - Monday February 19, 2007

One of the premises of Agile Methods is that much of the knowledge gained from a project is specific to that project and team, and therefore does not necessarily apply to other projects and teams. This article examines a pernicious over-generalisation of this, that is unfortunately often presented as superior thinking.

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


Alistair Cockburn, in his excellent article Characterizing people as non-linear, first-order components in software development argues that methodology generally cannot be exported from a successful project to other projects with any hope of achieving the same success. His conclusion is that the team has a first-order effect on the success of the methodology. Much of the Agile Methods literature is concerned with this same notion.


An unfortunate side-effect of the interest in this idea is that it has been hyped and generalised. The notion, clearly expressed by Cockburn and others, has been extended to the degree that nothing learned on a project is worth much on any other project.

The extent of this thinking is staggering in some individuals and teams.

Not only are initial estimates given with great trepidation but estimates given several months or years after the start of the project are given extremely cautiously, if at all. The argument given is that none of the work being done now is the same as the work already done (otherwise that work would be reused), so by definition it is something we have not done before on this project with this team. Hence the estimates are not based on any experience gained by this team on this project and are therefore not based on anything. Nonsense!

The foolishness can go even deeper than that, however. On two different teams (thankfully I was not working on either of them), I have seen a team member argue with great force that because they had not used a particular standard Java API before, any estimate given by the team would be a complete guess and so the estimate should be large to take account of the risk1. This was despite the fact that the API was extremely well used in general and that several other team members were very familiar with the API in question and they made this well known. Ridiculous!

Although this is a rather extreme example, a less excessive one is where a technique is suggested that is of more than average sophistication2. If some of the developers on the team have used the technique successfully before and can soberly see its applicability on the current project, it would seem incomprehensible to stay away from it because the experience was gained on another project with another team. Taken to its limit, this approach would mean that nothing (not even the chosen implementation language) should be relied on to work in the same way as it did on any previous project. Ludicrous!

The problem is not simply one of an inappropriate generalisation of good research (such as Cockburn’s). The real issue is the arrogant way in which the position of ignorance is maintained; when someone argues for their own bewilderment from an apparent position of superior knowledge, very little space for reason remains.


Their is a great deal of truth in the notion, generally held in the Agile Methods community, that certain kinds of experience gained on a project with a team may not transfer to another project or another team with anything approaching perfect fidelity.

However, this notion has limits. There is a large amount of knowledge3 which individuals can take from one or many projects and successfully apply on other projects with different teams. To maintain a position of ignorance because of a few circumstantial differences that are irrelevant in this regard does not demonstrate more profound understanding; it merely demonstrates genuine ignorance.

1 I can’t quite bring myself to tacitly ignore the confusion about the size of an estimate and the risk associated with it. Having now acknowledged it, I feel much better.

2 For example, the use of design patterns or techniques such as data-driven programming.

3 Some may call it ‘experience’, a neglected concept in software development where ‘bright, young graduates’ are often assumed to have as much skill as someone with a decade or two of well wrought experience.