On a user group someone asked what the Agile elephants in the room were. As I was beginning to respond, I was thinking there were two or three. However, as I started writing, I came up with nine! I suspect I could have come up with more. Here were my first thoughts:
1) One must attend to the entire business development cycle, not merely the software development cycle. This is perhaps the biggest one. Not surprising since most software consultants would be laughed out of a business boardroom. As you go through these elephants I believe you will see that many of them are not talked about either because, if you're a consultant/trainer, it'd work against your livelihood to do so, or if you are a practitioner, it'd force you to do something you don't want to.
2) Even in the software development cycle, the development team is not usually the biggest challenge in organizations with more than 100 developers. We preach what we know. Again, most of the Agile community is currently comprised of people who started out on the team (e.g., PMs, developers).
3) Developers are not more committed to agile than management. You see this particularly in the Scrum world where many people talk about protecting the team from management (which, btw, seems to represent a split in the Scrum community because about half of it embraces management while the other half talks about them as if they are an impediment in and of themselves). Personally, I find it self-serving. As someone who works with all levels – from C-level to first line management to developers to testers to … - I wouldn't say any one role or level is any more or less committed to effectiveness.
4) The idea of a minimalist approach is not necessarily correct. This sort of started with XP and seems to have stuck. I wrote a blog on this one – The Case Against Minimalism. I sometimes hear about how too many rules stifle creation. However, not attending to rules that affect cause problems of equal magnitude. My best example is to remember how the NASA scientists of the 60s were considered very successful innovators. Yet, and I'll admit I wasn't there, I'm pretty sure they paid attention to the laws of gravity. We need to pay attention to the laws of software development if we intend to get our job done.
5) Many people use agile as an excuse to justify not doing what they don't want to do. This has been rampant from day one and is related to the minimalist elephant. I remember around 2001 working with a company whose claim to doing XP was that they didn't do anything XP said not to do. They also, by the way, didn't do anything that XP did say to do. They, of course, weren't doing XP.
6) There is an incredible amount of dogma in the agile community. When your livelihood depends upon what you do, you can bet there will be strong justification for it. There will also be people who rail against anyone who challenges them. And, of course, there will be justifications given for the railing. The thing to look for is do people talk about the issues (not dogma) or just rail against the people (dogma).
7) There really isn't an agile community as there are many groups that have somewhat incompatible mindsets. Most of the Lean/Kanban community are very systems-type thinkers while most of the Scrum community are not (see The Real Difference Between Kanban and Scrum). I'm not saying this is bad. I'm just saying let's not pretend we're all in this together. We're not. I think many people in the Agile community are doing serious damage to their clients. I do not consider them my compatriots.
8) There are lots of people who don't seem to want to talk about what things you really better know if you are going to do agile. Fortunately, this elephant is starting to be talked about. Both by the craftsmanship movement and the Lean/Kanban community.
9) it is really hard to tell if someone has any experience with the methods they claim or if they are just jumping on the bandwagon. I'll admit this one is near to my heart. I have been thrown off the Scrum Development (twice) for talking about things that many Scrum trainers now say they've been doing for years. I've somewhat accepted that leading edge thinkers are going to be railed against. But I am disturbed by the number of people who've been claiming to have been doing Lean for years when the most they might have done was arranged for a true lean expert to do a course or a seminar. Here are Questions to Ask in Selecting a Trainer for Your CSM Training to help out.
I'm sure there are others. Why don't you add some in the comments?
CEO, Net Objectives