This article is part of the Agile Manifesto 10th Anniversary series that is being published on InfoQ.
The “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.
Snowbird
Alistair Cockburn organized a celebration of the10 years of the agile manifesto in Snowbird, Utah on February 12, 2011, gathering some 30+ people who’ve been involved with that community at the original meeting and since. It was a very interesting discussion, and I am not purporting to report here the main results or findings of this great event. 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, that is, 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 20 such “undiscussable” topics (or at least not discussable in the open).
A herd of elephants
Here’s the raw herd of elephants, with an additional sentence or two 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
see 1. above
3. Failure to dampen negative behaviours
We do not face, then analyse the 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, and claims of universal applicability.
6. Hypocrisy
… is a bit at the root of “elephant in the room” (we actually know all this).
7. Politics
A more systematic and thorough acknowledgment that organizational politics plays a big role in the adoption of agile practices.
8. Anarchism
… in the agile and lean community itself, preventing a more systematic organization of the body of knowledge
9. Elitism
… 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… Effective tool to assess maturity for individuals and organization, or commercial ploy from trainers and consultants?
12. Abdicating responsibility for product success to others
In particular, much of responsibility seems to be pushed to product owners, business analysts, users, etc.
13. Business value
The notion of value and in particular business value is mentioned everywhere, all the time, but never clearly defined, or confused with (development) cost, or pushed onto others (such as product owner) to resolve.
14. Managers and management are bad
… as an instance of pushing any failure to others?
15. Culture
There is often a tacit understanding that we (software developers) are all the same, and the agile movement has not fully integrated the concept of culture, both 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; they are still often equated to BUFD, and rapidly brushed aside with claims of YAGNI, or “we’ll refactor it later”
17. Self-organizing teams
Maybe as a consequence of the axiom that management is bad, and also pushing aside the concept of software development governance.
18. Scaling naïveté (e.g., scrum of scrum)
With a bit of imagination all agile practices scale up, and if this does not work it is because you have not tried hard enough
19. Technical debt
While agile practices could help control technical debt, they are also often at the root, the cause of massive technical debt.
20. Effective ways of discovering information without writing source code
These last few elephants (#16-20) are practices where a large level of variability exists across software development organizations, and little in-depth analysis has occurred, in particular on how they tie to context.
Grouping the elephants
This is quite a large herd of elephants. So after a few months, here is my view on the elephants we have in the agile community room.
1. The agile alliance elephant
I’ll put this one aside; the first that entered the room in Snowbird, since I have nothing to say about it. I noted a small group of former Agile Alliance 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… Is there a scrum alliance elephant?
2. Failures and limitations of agile practices, & context
While the community has been good 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, some are willing to acknowledge it in private conversations, but then… pretend it does not exist or return to the official dogma in more visible venues).
This elephant has several causes, themselves listed above as 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 against a whole community.
B) Decontextualization
In most instances, when practices are described too little of the actual context is described, leaving an impression of very wide applicability; even if this wide applicability is not actually claimed. Sometimes this is just pure dogmatism, or bigotry.
C) No obvious way to make progress based on failure
Unlike other disciplines, like medicine for instance, there is very little reporting of failures or limitations in software, and no clear venue or even templates or exemplars 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 still too few people gathering objective, significant, scientific evidence on our practices, except for a very few that are easy to instrument (pair programming, for example). This is probably exacerbated by some of the academic imperative to publish: doing extensive qualitative studies on development practices is not an easy route to a journal paper or master’s thesis.
E) Cognitive biases and Reasoning fallacies
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. are rife in the agile world. Others reasoning fallacies I frequently encounter include: non sequitur (no logical implication), 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 way 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 Engineering community over the last 6-7 years. But I know nothing about politics, neither inside our community nor as an impediment in organizational change that could be addressed explicitly by our community. Room for more work.
Agile teenager
The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant. But I have no doubts that it will mature further, become more open to the outside world, more reflective, and also therefore more effective. I got a hint of what’s up for the future at the Snowbird meeting, which produced much more than our side meeting on elephants.
Note: this was originally published on February 13th, 2011 here.
About the Author
Philippe Kruchten is professor of software engineering in the department of Electrical and Computer Engineering of the University of British Columbia, in Vancouver Canada. He holds an NSERC chair in design engineering. He joined UBC in 2004 after a 30-year career in industry, where he worked mostly in with large software-intensive systems design, in the domains of telecommunication, defense, aerospace and transportation. Some of his experience is embodied in the Rational Unified Process (RUP) whose development he directed from 1996 until 2003, when Rational Software was bought by IBM. RUP includes an architectural design method, known as “RUP 4+1 views”. His current research interests still reside mostly with software architecture, and in particular architectural decisions and the decision process, as well as agile software engineering processes. He is a founding member of IFIP WG2.10 Software Architecture. Kruchten received his mechanical engineering diploma from Ecole Centrale de Lyon, and his doctorate degree in Information Systems from Ecole Nationale Supérieure des Télécommunications , Paris. He is a member of IEEE, ACM and AIS, and a Professional Engineer in British Columbia.