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
see above
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
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 play a big role
8. Anarchism
… in the 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…
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?
15. Culture
… 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.
B) Decontextualization
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.
Elephants in the agile room: cards in Snowbird
Trackbacks
- Tweets that mention The Elephants in the Agile Room « Philippe Kruchten -- Topsy.com
- The Elephants in the Agile Room « Interesting Tech
- Top Posts — WordPress.com
- diffusion of innovations and logical fallacies | Bill's Journal
- Talking Work » Blog Archive » Zombie Elephant
- Software Linkopedia February 2011 | Software Development Musings from the Editor of Methods & Tools
- 10 Years Agile – a perspective from outside the room
- Picking Agile vs. Waterfall “Projects”: a Ten Point Quiz. « Scaling Software Agility
- The Agile Manifesto is 10 years old! « iPROFS Technology Blog
- A Roundup of Popular Agile Articles - WebsitesMadeRight.com
- Post-Chasm Agile Blues
- Agile’s perspective on failure « Protegra
- Philippe Kruchten : Agilité et Architecture | Laurent Bristiel
- Philippe Kruchten, Agility and Architecture | Laurent Bristiel
Philippe Kruchten 
Every organization has it politics and dysfunction. Not interested in dogma or counting how many angels fit on the head of a pin. I am interested in what works in the enterprise. We are having great success. Decided to log what we have accomplished. See http://www.agileandleanatscale.com. Just getting started and have much to say. Hope you find it useful. We need to share what works.
One phobia we have in the community is metrics. Why? Because metrics have been misused. They have left a bad taste in our mouth. Executives want to use them for performance review, not continuous improvement.
However, we are missing a critical tool. A tool that helps us determine what works, and identify when we are on the wrong path. Metrics will enable us to use data to tell our story. To share the good news, and to identify what is broken and perhaps why.
We have much to share. Measures help us be transparent. No only to our business partners and users but to ourselves and to each other. Come on community, time to stop our phobia over data. It is time to take true measure of ourselves. It is time to grow up.
What a shame. We wait ten years for the second iteration of the ‘Agile Manifesto’ and the only consensus is that the ‘Agile Alliance’ has been corrupted by business concerns (aka ‘monetary interests’) and the goal of assembling 35 unnamed individuals at Snowbird was *NOT* to iterate the Manifesto.
Oh well, from the photos it looks like everyone had fun! See you in 2021 for a serious exercise.
Marvin, you wrote:
What a shame. We wait ten years for the second iteration of the ‘Agile Manifesto’
I do not know why we have to have a second iteration of the agile manifesto. This is not the reason we gathered. (and I am not sure why you waited 10 years …)
and the only consensus is that the ‘Agile Alliance’ has been corrupted by business concerns (aka ‘monetary interests’)
What I am reporting here is the result of a small side meeting, not the consensus,
and not the one and only consensus. see some initial report of the main event here:
http://www.dennisstevens.com/2011/02/13/whats-next-for-the-agile-manifesto/
and the goal of assembling 35 unnamed individuals at Snowbird was *NOT* to iterate the Manifesto.
Again, sorry, our goal was to reflect on some issues, not to revise the manifesto.
see some initial report of the main event here:
http://www.dennisstevens.com/2011/02/13/whats-next-for-the-agile-manifesto/
The individuals who participated at Alistair’s invitation are named, here:
http://www.dennisstevens.com/2011/02/12/10-years-agilefriday-night/
See you in 2021 for a serious exercise.
Are you organizing something, Marvin?
Philippe,
The reason the Agile Manifesto needs to be iterated is that it does not scale.
We have ten years of evidence suggesting that the most capable 25 companies in the world, despite isolated pockets of success, have been unable to realize the 12 Principles on a distributed global scale.
_Marvin
——————————————
| USA Cell: 248.866.4897
| Email: MarvinToll@gtcGroup.com
| Web: http://MarvinToll.com
——————————————
Join the LinkedIn ELIGA Group:
“Proven enterprise Architecture/Design/Implementation patterns are effectively communicated when including working software examples derived from a reference implementation.”
Phillipe,
I think that it’s a great idea to discuss elephants, as long as you’re feeding the elephant the same dog-food that you’re selling to pet owners, and hopefully consuming personally.
Here’s the dogfood I’m referring to: At least 1 actionable item to improve the way that you work. It’s a deliverable from the Retrospective. If what you did in Snowbird was a Retrospective, and you’ve been facilitating lots of retrospectives with your teams, then you know that it produces a deliverable: at least 1 actionable item. -Probably, it’s going to be an experiment to see what kind of change will get better results for your group/team.
Since I didn’t see that mentioned at the end of the list, or after each item, I think you probably didn’t frame your gathering’s objective that way. Is that the case?
Is it also the case that your attendees are not in the habit of framing such exercises to have deliverables be take the form of an action/experiment toward improvement?
From the outside looking in, it resembles “a meeting” which most people in the working world despise more than sickness and death itself: a Complain-fest or Worry-fest.
In particular Elephant D) seems illustrative: If empirical evidence of the efficaciousness or applicability of agile practices is still in question, why would you not create an action item to find a sponsor for a study that would produce evidence or counter-evidence of the validity of agile practices?
Could it be that such sponsors don’t exist? Academic interest in proving or disproving Agile project management vis. a vis. sequential non-iterative project management may not have the resources required to execute such a study. If the positive externalities of owning such evidence are what precludes some entity from finding the evidence, then maybe some unbiased entity (national governments, agencies, etc.) with the power of coercing the beneficiaries of such evidence (via. taxes, etc.) to help fund such studies should be driving and funding such studies. Why does that not happen?
Depending on the way that your group answers that last question, you may find your answer to the original question of why 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)”
So, if you’re gathering of people are not just inexperienced skeptics, then I suggest that you practice what you’ve presumably preached, or done before with your agile teams and ask the 5 Why’s.
If it were clear that you were not on a soul-sucking, interminable Groan-fest, or in Drew Jimelo’s words: “ran off to Pity City never to return” you could possibly enlist the cooperation and assistance of others less skeptical. But, by categorically throwing down chicken/egg paradoxes such as elephant D), and citing reasoning fallacies such as elephant E) which come across as some kind of strawman fallacy itself, you put people (like me) off.
What do I specifically mean?
Your group lists “self-organizing teams” under topics “often undiscussable (beyond loud rhetoric and posturing)”
Within the last 2 weeks, I’ve randomly come across and read an article by either Boss Vode or Craig Larman about their first-hand experience facilitating a large group of people in self-organizing into teams over the course of about 3 to 5 hours. (I won’t go back and find the URL, unless I believe you want it, and that you’ll accept it as evidence.)
Based on the non-action oriented portrayal of said gathering, I would surmise that perhaps my citation would result in your removing “self-organizing teams” from the list of elephant E), only to have it placed under elephant D) because you might say that 1 isolated case does not a preponderance of evidence make.
If I’m mistaken, please point out to me the amounts of research effort your gathering participants have made to identify instances of agile practices. Maybe then we can see where the disconnect is happening.
You see, I just randomly stumble onto this “evidence” with minimal effort, commensurate with my level of interest in the topic in general. (Of course, it may not withstand the scrutiny of a very skeptical examiner, as I don’t recall any independent 3rd party attestations to the voracity of the blog I read. Additionally, internet posting such as yours and mine, will be taken with a generous grain of salt due to the laissez fair nature of the internet as a medium.)
It could be possible that project management is some combination of art and science. In fact, there could many business practices that are a combination of the too. Therefore, the Snowbird group may be applying an undue level of rigor in scrutinizing something like agile. I’ve directly witnessed Tuckman’s model of teams “Forming, Storming, Norming, Performing” called into question by a team member of mine, about 1 month ago. I can’t point to any clinical evidence that scientifically supports such a model. Ironically, the team member noted that Tuckman was a contemporary of Milgram, and therefore a dubious source, by his reasoning. -Yeah, that’s ad hominem, BTW.
Furthermore, look at how long it took the court cases to support the causality of cigarette smoke with lung cancer in the United States. Something on the order of decades, right? Are you really going to wait around for some company to sue a consulting firm for millions or billions of dollars, justifying a study that would settle the issue of causality of project management practices or frameworks to your satisfaction or the scientific community’s?
I’m hoping there’s enough interest in this topic that you monitor this blog and request the URL I mention above. But if not, sobeit. I’ll keep doing my agile thing.
Jon,
I was reporting (3+ years ago) on part of a gathering I was part of in Snowbird a few hours earlier. Others did too.
See http://www.rallydev.com/community/agile-blog/10yearsagile-and-snowbird-2011 for a list of various pointers. Or this http://www.drdobbs.com/architecture-and-design/agile-at-10-what-we-believe-scott-ambler/229301128?pgno=2
This specific session was not an organized retrospective, and I was not organizing it: it was actually pretty impromptu, as far as I remember.
There was no action items. I see not reason to start editing this blog entry. (Would you go back to edit minutes of some meeting 3 years later.)
I am sorry you feel so offended by it. Or that you feel personally attacked.
As for evidence of various practices, yes, progress is being made. On the specific topic of self-organizing teams,
I am well aware of the thesis and other writings of Rashina Hoda, and others. My thinking and investigation did not stop
abruptly that day.
(Just as an example I still have doubt about principle #11 in the manifesto.
I’d be happy to read whatever evidence you have about “the best architectures … coming from self organizing teams”. See the paper by Norman Séguin presented at the XP2012 conference:
N. Séguin, G. Tremblay, and H. Bagane, “Agile Principles as Software Engineering Principles: An Analysis,” in Claes Wohlin, ed., Vol. 111, Lecture Notes in Business Information Processing, Berlin Heidelberg: Springer, 2012, pp. 1-15.)
I am not sure what group you are referring to? The group who met in snowbird? It was gathered by
Alistair Cockburn, and had maybe 70% of the original signatories of the manifesto, and another 20
like David Anderson, or Ryan Martens (Rally).
I would not really qualify them all as “… just inexperienced skeptics.”
Cheers,
Philippe (from XP2014, an agile conference with a scientific track….)
An important and enlightening post – thank you for writing it, Phillipe. And thanks to Alistair Cockburn and all of the participants in SLC for the courage and sense to bring these “undiscussibles” into the light where they can be addressed. Those of us on the business side, knowing agile’s promise, are too often thrust into the role of defending agile to our colleagues when these divisive issues emerge. Documenting this “elephant” exercise will be a great help in moving that dialogue forward.
Marvin,
Yes,
Scaling naiveté is elephant #18 in the list. On of the undiscussables.
We need more evidence. Not just someone’s assertion against someone else’s assertion.
Ph.
Philipe,
Nice job capturing our afternoon work! I really appreciated the conversation and your active involvement in that deep afternoon effort. As you stated, this was a small group, deep-dive piece of the whole conference. I believe it was great conference that we will have to keep explaining to everyone. It was not all negative, just a great retrospective with deep understanding of both.
I appreciate your earlier posts in the blog on “Context” too. These will be critical to help agile scale in different contexts.
Ryan
In my personal “room” the Agile Alliance is not even a mouse in the room. But I can appreciate that others expect something more than what ever was reality, and are therefore disappointed.
Thanks so much for being an information radiator, Philippe! I’ve been really interested to hear about the proceedings, and as usual, found it first on Agile India…
Think of all the slide ware that doesn’t have to be updated, since you didn’t rev the manifesto!
On the other hand, 10 years and anything gets a little long in the mouth.
A lot of people have asked “what’s the new, new thing?” after agile (/lean/kanban)… did you end up discussing this question, and if so, any luminary light to shine?
Thanks again for sharing.
Greg
Hi,
This “Elephant in the Room” is very common in our world today — both inside and outside the industry. As people in the industry who are responsible (like it or not) to face these issues, you can see that people are looking for leadership. And this is hard. Always will be.
I wrote about this in a blog entry (and comic strip) a while back, and this is something that I continue to tackle on a daily basis [http://www.implementingscrum.com/2009/02/04/scrum-coach-consultant-mentor-super-hero/].
Time to step up.
Everyone!
Thank you.
– mike vizdos
http://www.michaelvizdos.com
http://www.implementingscrum.com
Really amazing information found here… really thanks very much for sharing this interesting information. Thanks and keep posting….
From: http://econis-labs.com/