Responding to the Skeptics

As an Agile Coach, I am predominately focusing on introducing Agile to organizations and teams for the first time.  As such, I am constantly confronted with the skeptics who say things like,

“Agile won’t work here”
“We can’t ‘do’ Agile for this project”
“We will never be ‘totally Agile’, we just want to use it for certain projects”… 

While I appreciate a fair skeptic, it’s important to understand the basis of their pushback, so that I can coach them in the proper way:

Is it Ignorance?  They simply don’t know any better and/or haven’t been trained
Is it Fear?  They’re afraid of change, or accountability, or both.
Is it a previous, “bad experience”?  They’ve tried it before and failed.

First off, Agile is not something we “do”.  It is not a methodology.  It is a mind-set, a way of thinking and behaving.  It is a set of values and principles that guide us in our work.

So, my response is often to simply recite the Core Values from the Agile Manifesto and ask, “Which of these Values can we NOT try to adhere to?”  That may be enough to shift the conversation from “We can’t…” to “How can we…”, but not always.

If that’s not enough to pivot the discussion, I will then go over the 12 Agile Principles and ask the same question “Which of these Principles can we NOT follow?” That usually gets some of the more stubborn skeptics to at least consider the idea of separating the values and principles from the specific methods and/or mechanics of a particular approach, like Scrum or XP.

That’s not the end of the conversation.  As the team or organization start actually trying to execute, there will be inevitable roadblocks and even some failures.   This may cause some to panic and others will be quick to say, “I told you so!”.

In my experience, a common problem is that as soon as the organization or team hits those impediments or thinks they can’t do something ‘100% perfect’ or ‘by the book’, they start to deviate in really bad ways or just retreat all together. This may be due in part, to having poor coaching or training, but it’s usually just a cultural condition or reflex. What they should do instead is seek opportunities to optimize what they can do well and eliminate the waste and reduce the risk of those things that they can’t, or don’t, do well.  Most organizations won’t become ‘perfect’ agile/lean environments right out of the gate.  For many it can take a few years.

A pragmatic agilist will keep their teams/organization moving forward, being realistic about what is working and what is not working (for the moment or situation) and seek continuous improvement rather than seeking “perfection”.

That’s the beauty of Agile and Lean:  “We do a little, we learn a little, and we improve a little.” – Me.

2 Responses to “Responding to the Skeptics”
  1. Manny Segarra 3 says:

    Well written Richard ! I appreciate the tactic of walking down the 12 Agile Principles and getting consensus around these values as having merit. In dealing with my own share of skeptics, I use two approaches to getting skeptics to see a different perspective and how agile can help…

    One, Accountability…have you ever heard the term “That diet failed me, it didn’t work…!” Perhaps that’s true, but what’s more likely to have failed, is your commitment to the diet and your accountability to yourself. When you try anything , with a half baked effort and an eye on failure, you will get half baked results ! That’s not agile, that’s Life ! Was your agile transition/transformation a real effort, or just lip service to the latest ‘cool thing’ ? I challenge every skeptic with a question that does not even need an answer…”Did you really give agile your best effort ?”. The hesitation in answering, the body language, the lack of conviction in the verbal response, will tell you everything you need to know !

    The second, Defend the Status Quo, is a little more direct and assertive and should be applied gently and with Respect (see 5 Scrum Values). When a discussion gets heated and/or pointed, I ask the Skeptics, usually more than one, to grab a marker and find a whiteboard. I then ask the group of Skeptics “Defend the Status Quo”, tell me all the good things and benefits about the way we are working today ! Who will stand up and say “Low quality products are good”, “Missing deadlines is acceptable”, “Upsetting the client is OK”…Once the Skeptics are forced, in public, to defend the Status Quo, the resistance wavers….

    BUT Beware ! This method may drive Resistance underground, so use this method with caution…

    We will never have all the answers to all the questions/resistance/skeptics but dealing with the resistance/ignorance/past failings, in the open is the first step in turning skeptics into advocates !

    Manny Segarra 3
    Agile Knight

    • rdn32 says:

      I used to think that Agile was an obviously good thing, since I thought it boiled down to “Do what works. Don’t do what doesn’t work. Put more faith in observations of how things pan out in practice than up-front ideas of how things are ‘supposed’ to work. ”

      I did used to get the occasional twinge of scepticism, when the resemblance to a management fad seemed too close for comfort, but overall I’d say that I wanted to believe (and still do).

      My experiences, however, have been rather disappointing. I’m not going to go into details, as it’s going to be too easy for anyone to say “oh, but that’s not _real_ agile” – at which point we’d clearly be stuck in he middle of a “no true Scotsman” argument.

      I would make one observation, though: the most vocal Agile advocates I’ve encountered haven’t been the best programmers I’ve known, and the one’s I’ve had as colleagues haven’t particularly impressed me with the quality of their work.

      I have a theory about the reason for this. If, like Manny, you regard the choice of approach to software development being a battle, where anyone who disagrees with you is an opponent who’s resistance must be overcome, then it’s unlikely you’re going to learn much from people with ideas different to your own. Whereas if you take the trouble to understand what people think and why, then you learn all sorts of interesting things. The best programmers I’ve worked with have generally been more interested in learning things than in demonstrating how right they are.

      With regard to half-baked efforts: one can make an effort with a particular practice, but it makes absolutely no sense to talk about making an effort with a principle. (Effort itself can be dangerous in some circumstances. See )

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: