How do you Convince an Agile Skeptic?

| by Jean-Jacques Dubray on Sep 13, 2010. Estimated reading time: 3 minutes |

Daniel Markham, a hands-on technologist, and agile coach wrote a post last week trying to answer the question why some people are seriously pissed off at Agile? He regularly receives negative emails rebuffing Agile claims. After well over a decade of Agile practice and a wide adoption across the industry, it might be a good time to pause for a second and ask some questions like Amr Elssamadisy did earlier this year. There is often one small step between success or failure, not to mention that it is often difficult to measure success.

Here are the problems he sees and hear about:


  • Fake success stories
  • Trainers who can't do the work
  • Inflexibility on the part of adherents
  • "Feel good" agile
  • Magic Bullet Syndrome
  • Reversal of team dominance
  • Cargo Cult Agile
  • Non-answers to questions
  • Conflicting Advice
  • Scamsters
  • It's the same, only different
  • Little Gold Star Syndrome


This set of remarks reflect a fairly general pattern in our industry and the same things could possibly said just by replacing Agile by the buzzword du jour.  As it is often the root cause of skepticism, Daniel explains:

Agile has no definition. There's no standards board, there's no test, there's no approved workbook, there's no checklist. Agile is nothing like Scrum. Personally, I think that's a good thing. Agile is a set of best practices around running iterative and incremental development teams. [Agile itself is just] a marketing term.

Yet, there is ample evidence that Agile teams are generally happier an have a higher productivityAs the debate on the ingredients of success is still active, for Daniel, the keys towards becoming a successful Agile team is about doing, reflecting and adapting:

It IS an art, not a science. You don't just read a book or take a class and suddenly you are agile. You don't learn to play the piano by watching a film of somebody else playing, reading a book about it, or going to a conference.

Not surprisingly, lots of comments followed: 

[Techneilogy] One thing that makes things with some good (like agile programming) go so bad, is the "secret formula" mindset endemic in middle management.
[Alan Franzoni] Agile should be agile in adoption as well - it's very hard to start from scratch and adopt each and every "agile technique" at once, and it should be a developer's demand beyond the manager's will - if something works well, there may be no reason to change its.
[Rui Curado] Pragmatic model-driven development (hence not UML/MDA) coupled with code generation is one step forward to a better development future. It does require some mindset shift but pragmatic approaches are within reach of the mere developer mortal.
[Ben] I can relate to the people who don't like the nerf ball, the haikus or whatever other "far-out" ideas the "Agile people" can come up with, and I can tell why I don't like it either with one simple sentence: what the hell does that have to do with software development?! I think that the Agile community would gain a lot by realizing that what me and a lot of people like me need are not "anecdotes", "coaches" and "stories" but techniques, clear structures and measurements.
[Anonymous] We've recently switched over to scrum at my company, and for the second time in my career I've been stuck doing this. It's so tiring on developers, all these iterations. Two week cycles, over and over, on mini tasks, makes you feel more like a code monkey than an actual developer. [To which Daniel responded] So if I were you (or your team) and I found this agile stuff just grinding the hell out of me? I'd be bringing that up every stand-up. It's an obstacle, an impediment to team performance. It needs to be fixed.

If you think that Agile is here to stay, how would convince a skeptic? Is it mature enough? or is it still going through the troth of disillusionment? Is it still suited for a world dominated by mobile applications and Cloud Computing? Or does our industry need to look beyond its processes to find new productivity gains?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Agile has no definition by alireza haghighatkhah

I’m totally agree with Daniel, I think Going to agile is not just applying some practices & principles in your team like pair programming and iterative process model, before going to agile we should study about target organization deeply, we should know organization culture. As mentioned agile is not defined process or set of practices, instead agile is set of mindset that should be adjust and adopt in your organization. Playing agile in your organization is more art than science.

I think the problem with adopting agile is that there is no defined process, step and rules. In the other hand these factors are most notable feature of agile. There is no definition; you should learn how to play and improve your process in continuous manner.

Re: Agile has no definition by Martijn Verburg

+1 - Nuff said :)

time and materials by Konstantin Ignatyev

Of course Agile is here to stay: it is ‘time and materials’ thus it is very profitable to the people doing the work;
It is double profitable because it is easy to portray ‘activity’ as real progress;
Focus on short term deliverables easily leads to hacks and lack of thoughtfulness causing a lot of rework. That can to be mitigated when there is somebody why really understand what needs to be done, but often is not because reward for ‘not understanding’ is quite substantial.

Re: Agile has no definition by Vladyslav Yatsenko

That's why Agile is rubbish, just a general term (used as marketing term mostly), there is nothing special about it... most of companies/teams have always been forging their own processes. To me, "Agile" term fits better as a name of the current era of software industry evolution, a name only.

Abject surrender by David Poole

I saw a comment that agile was abject surrender on the part of IT. In general terms I don't agree but I do know what the author meant. In theory you can constantly refactor and react to change demanded by the business but in reality the amount of change demanded by the business increases beyond the resources available to enact that change.
I'm still not sure that the agile development copes well with processes where a good look ahead is essential.
In some respects agile strikes me as driving a high speed in foggy conditions and no map.

Why try to convince a skeptic? by Dave Nicolette

Whether it's "agile" or anything else, what's the "return on investment" on trying to convince someone of something when their mind is already made up? It may be a better use of your time to help someone else who is actually interested; a better use of their time, too.

agile fall from grace by phloid domino

the problem with 'agile' is that it has been co-opted by managers who only want the short deadlines and nothing else

abraham lincoln once asked "how many legs would a dog have if you called his tail a leg?"

the correct answer is 4, because calling the tail a leg doesn't make it a leg

calling a dysfunctional scheduling obsession 'agile' by having daily stand-up meetings does not an agile process make

a candle on a raft in the ocean by Jason Little

I've often thought the agile community isn't selling what our customers want. We talk about values and principles that are so abstract they don't resonate at all. 'Customers' (AKA organizations that bring in coaches) want tools and processes to help them work better.

They often don't realize how difficult change is and expect Agile is a function of engineering/IT and has no effect on the rest of the organization. There are many factors contributing to the perception that Agile is broken.

There are tons of posts of "I've been using Scrum successfully for years..." all over linked in and google groups, there are people that just don't get it, there are coaches who aren't considering the culture and pace the organization transforming can support and the list goes on and on.

What Agile is all about is taking data that is made visible and giving the business an opportunity to make better decisions. That's it. Whether Scrum/XP/Kanban/Scrum-but/Butt-ban/<fancy method name here> fit the bill, that's fine. Pick what works to help you solve your organizational problems and more often than not I find that management simply ignores this data because they don't like what they hear.

To the point Daniel made, getting burned out using Scrum shows there is a problem of too much work being pushed through the team. This is common. It's expected that 'agile' is for the team and the business does not change their bad habits. With that attitude and ignorance to analyzing the whole system, any methodology isn't going to work.</fancy>

Not enough good guys by Lionel Orellana

The problem is not Agile, Lean or Waterfall. The problem is the general lack of skills, knowledge and professionalism. Anyone with a 3 month programming course calls herself a software engineer. Don't get me wrong there's a lot of talented people out there but not enough. It's a lost battle from the start if you don't have the right people. And chances are you don't.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss