Elephants in the Room of Agile

March 26, 2011 — Posted by Al Shalloway

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?

Alan Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


I came up with another one.

10) If your method merely says you trust and respect people then it doesn't really trust and respect people.  In other words, the method must do something that fosters trust and respect.  I remember at a Scrum gathering years ago (2003-5) everyone was bemoaning the lack of trust between teams and management.  The general sense was that you couldn't do Scrum without it.  My own take was that one needed to look at things you could do where you were (e.g., build incrementally and give demos) that would build trust.  Of course, that's an Agile thing - build incrementally. But it occurred to me that there were many more things that Lean flow told us that we could also do that would be useful.  Furthermore, shared understanding that could be achieved from discussing principles (instead of practices) also looked like it could foster trust. I discuss this a bit in an earlier blog called Why Not to Focus on a Company's Culture .

One of the big differences between Lean/Kanban and other Agile methods is that Lean/Kanban discusses how explicit policies and systems thinking can support the teams in learning.   This was not apparent to me until the inaugural Lean SSC conference in Miami in 2009.  I discuss this a bit in The Difference Between "Inspect and Adapt" and Plan-Do-Check-Act (PDCA) .

The bottom line is that saying it is important to trust and respect people doesn't mean anything on its own.  We need to discuss methods that assist us in this.

Alan Shalloway, CEO Net Objectives

What a great post Alan! I've been thinking of the same topic title (Elephants in the Room) and am thrilled to see that you wrote about it first.

Isn't it amazing that we (systems professionals) can spend so much time working around and pretending that there are no elephants in the room that we can almost render ourselves in a corner with seemingly no space left to go...

Unless we really address the elephants taking up all the space in the room.

If we (and the business) can find more ways to work together on common ground (setting aside the internal turf wars between our own agile/kanban/lean/six sigma methodology factions and the master/slave mentality between stakeholders) - I believe we would so much more progress and gain.

Somehow there's got to be forward movement (and slack) when the elephants are removed (or eaten as some might like to say) - and we get down to the real business of building solutions that support the business.

But, let me get off my "soapbox" and back to the topic - great post!

Unfortunately the dogmatic ones are not segregated to just the Agile community...and it is so true that if you dare to offer an alternative view or take, they attack you as a heretic. At times it goes from the ridiculous to the sublime.

Fantastic post!


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban