The Elephants in the Agile Room
An “elephant in the room” is a metaphor for the behaviour of people who deliberately ignore an impending issue. They are fully aware of some major issue that really must be tackled or decided upon, but everyone keeps busy tackling other, often small items, ignoring the big issue, pretending it does not exist, hoping maybe that it will vanish by magic or that someone else will take care of it; that one day the elephant will have left the room.
During the 10 years agile celebration meeting in Snowbird, UT, organized by Alistair Cockburn on February 12, after covering the walls with a couple of hundred issues cards, David Anderson noted that there was “an elephant in the room”, a topic that few are willing to debate in the pen, namely the Agile Alliance (its role, mission, accomplishments, etc.). After the lunch, a small group gathered and identified a few other such elephants in the room, other topics that the agile community is not really willing to tackle for a variety of reasons. We ended up with a long list of about 12 such “undiscussable” topics (or at least not discussable in the open).
Here they are, with an additional sentence to explain what the title is about, based on the best of my recollection (see photograph at bottom):
1. Commercial interests censoring failures
The key players in this community have a direct financial interest and have fear that any negative info would be amplified, distorted, and turned against them
2. Pretending agile is not a business
3. Failure to dampen negative behaviours
We do not face, analyse failures and limitations of our assertions, claims, practices (see above)
4. Context and Contextual applicability (of practices)
We fail to describe the context in which some practice works, or does not work.
5. Context gets in the way of dogma
By evacuating context, we constantly return to dogmas, bigotry, claims of universality
… is a bit at the root of “elephant in the room” (we actually know all this).
A more systematic and thorough acknowledgment that organizational politics play a big role
… in the community itself, preventing a more systematic organization of the body of knowledge
… as a defense (against failure) we limit our message to the best… and blame failure on the “unenlightened” others…
10. Agile alliance
Divergence of views as to what it role has been, was supposed to be, will be…
11. Certification (the “zombie elephant”)
This massive elephant was reported dead a few times, but seems to reappear…
12. Abdicating responsibility for product success (to others, e.g.,product owners)
13. Business value
… mentioned everywhere, but not clearly defined, or pushed onto others to resolve
14. Managers and management are bad
… as an instance of pushing any failure to others?
… better understanding of the concept of culture, at the organization level and at the national level, and its subtle interaction with practices, an integral part of context.
16. Role of architecture and design
… depending on context
17. Self-organizing teams
18. Scaling naïveté (e.g., scrum of scrum)
19. Technical debt
20. Effective ways of discovering info without writing source code
… these last few (16-20) are practices where a large level of variability exists, and little in-depth analysis has occurred.
This is quite a large herd of elephants. So after a night to sober up, here is my view on the elephants we have in the agile community room.
1. The agile alliance elephant
I’ll put aside this one, since I have nothing to say about it. I noted a small group of former AA board members tackled this elephant late in the day. Maybe it is just one instance of the “Community leadership” elephant which would include other organizations…
2. Failures and limitations of agile practices, & context
While the community has been god at amplifying what works, it often has not been good at dampening what did not work, analyzing why it did not work, or under which conditions it did not work (context!). There is in some cases a certain level of hypocrisy (many interested parties know this, but… pretend it does not exist or return to the official dogma).
This elephant has several causes, themselves elephants (i.e., “undiscussables”):
A) Commercial interests
Many of the key players in this community have a direct financial interest in selling something agile (tool, consulting, training, new idea), and there is this latent fear that potential buyers would be detracted by any hint of negativity, that any bad news would get unduly amplified, that it would in the end turn against them or again a whole community.
In most instance, when practices are described, too little of the actual context is described, leaving an impression of very wide applicability, if this wide applicability is not actually claimed. Sometimes this is just pure dogmatism, or bigotry (see ).
C) No obvious way to make progress
Unlike other disciplines, like medicine, there is very little reporting of failures or limitations in software, and no clear venue or even templates or examplars of such reporting. And again the fear that this would reflect badly on the person reporting, or the “victim” or “culprit” organization. A good template for such report would include a detailed description of the context.
D) Limited objective evidence
There are too few people gathering objective, significative, scientific evidence on our practices, except for a very few that are easy to instrument (pair programming, for example).
E) Reasoning fallacies
such as undue generalization (it worked in two cases, therefore it will in all cases), and cognitive biases: anchoring, golden hammer, cargo cult, etc. Others reasoning fallacies include: non sequitur, and Post ergo propter ergo (correlation implies causation, or “guilt by association”), etc.
The two smaller elephants: elitism and hypocrisy are probably in the shadow of this main one, and the anarchism of our community does not help to organize a body of knowledge.
The practices in question for which there is little evidence or understanding of the role in various contexts are also some of the smaller elephants in the list above, often undiscussable (beyond loud rhetoric and posturing):
- thorough articulation of the concept of business value,
- the role of architecture and design, technical debt,
- self-organizing teams,
- writing code as a priority, etc.
3. Politics and culture elephants
These two elephants would require more investigation. I do have some personal opinions on the impact of both national and organizational culture on agile practices, and some investigation has taken place in the Global Software development community. But I know nothing about politics, neither inside the community or as an impediment in organizational change that could be addressed explicitly by our community.