Lately I've been hearing feedback from lots of different people that they've "adopted" agile and it's just not working for them.  This always causes me to pause, step back and ask a few questions.  Here's the list that usually runs through my head:  How did your company adopt agile: top down mandate or grown organically?  Was your adoption done in stealth mode or full fledged "Hello world, we're going agile"? Do you have real executive support for your agile adoption? What kind of projects have you implemented agile on: fixed price, fixed scope, fixed schedule? Has your staff received any kind of agile training? How many projects have you run in an agile manner? How long ago did you start doing agile? 

I run through these questions because I think each one represents a potential failure point for agile adoptions.  Let's take a look at each one. 

1. How did your company adopt agile: top down mandate or grown organically?  This is really important.  In the teams I've talked to and worked with, it always seemed that agile was adopted better when it was grown organically not when it was mandated.  The mandate approach assumes command and control and never leads anywhere good.  People need to want to do agile.  So how do you get people to want to do agile?  Show them small successes.  Let a single team or a few small teams start doing agile.  Then, as they show successes and learn some of the lessons, other teams pick up on it and want to do the same.  The teams that went first, help the teams that followed adopt agile and they pass on the lessons they've learned. In other words, you can't just throw the agile switch and voila...everything is good.  Mandated adoptions often fail because there is no magic switch.  People resist change when it's mandated.  They embrace it much better when it's grown out of proven success.
2. Was your adoption done in stealth mode or full fledged "Hello world, we're going agile"?  The CEO or COO stands up and proudly announces "Hello world, we're going agile" and then thinks in the back of his mind "I hope this voodoo works".  And, because there was such a public announcement of the company's intent, there is extreme pressure to "make it work".  This pressure leads again to command and control thinking of "make this stuff work" or we're going to be embarrassed.  On the flip side, if you start in stealth mode, you work projects internally using agile practices but say nothing of it until the project is over.  When you client asks "How were you able to deliver value in a timely manner?" you can answer "With agile practices".  Because there is no external pressure to live up to some expectation, stealth agile teams have an internal commitment to making agile work for their own good without being forced to do so to meet some external expectation.  Once they gain the successes on stealth projects, they'll be more comfortable with announcing that they develop in an agile manner to the world.
3. Do you have real executive support for your agile adoption?  Lot's of executives have "heard" about agile and want to do it because everyone else is.  But, they don't really understand the level and type of commitment an organization must make to truly adopt agile.  If you haven't already noticed, one of the key things an organization needs to let go of when they adopt agile is the command and control structure.  It's a very hard hard thing for most executives to let go of, and many never fully commit to and support a more servant leader approach to management.  Failure in agile adoptions occur when lip service is paid to "supporting" agile practices, but business goes on as usual: The command and control structure remains, long winded requirements documents are requested to support the inevitable scope disagreements we'll have with our clients, deliverables-based contracts and project tracking remain, and percent complete and earned revenue calculations are the only important project metrics.  If organizations can't come around to supporting agile practices and drop their old "bad" management habits, agile adoptions are doomed to failure. 
4. What kind of projects have you implemented agile on: fixed price, fixed scope, fixed schedule?  If you're going to adopt agile, you need to consider the types of projects you're going to run agile on.  That means thinking about contracting in a whole new light.  If you're trying to use agile practices on a fixed scope project, expect to fail outright.  Fixed scope is the antithesis if agility.  If you're running on a fixed-price project, better chance of success, but only if scope is not fixed.  Fix your price and your scope:  FAIL.  And fixed-schedule, another bad option.  So, if you're trying out agile on a project that has not truly been contracted to run agile, expect failure.  The answer is to work with your clients to educate them and develop agile contracts that both you and them can work with and live with.
5. Has your staff received any kind of agile training? "OK, so we're going agile.  Here's the 2-hour overview.  Go out and be agile!".  One month later: Fail.  Why?  Agile is not easy.  It sounds easy and can be explained quickly.  But, there are many subtleties and nuances to agile.  For teams to really grock the whole agile thing, you need to invest some time and money for training.  An agile team needs to learn how to plan in a whole new way, how to develop user stories, how to develop tasks, how to assess themselves and their practices.  And, they need to learn about the heart of agile: commitment.  Unless teams deeply understand what makes agile tick, they're going to have a difficult time being successful at it.  A two-hour "Welcome to Agile" powerpoint ain't gonna do the trick.  Sending teams to something like scrum master training is well worth the time and money you'll spend on it.
6. How many projects have you run in an agile manner and how long ago did you start doing agile? My advice here: give it room to breath.  It takes a few turns around the block to get agile running smoothly.  Teams need time to gel, get to understand agile and learn about themselves (see recent post on this topic).  Like I said before, there is no magic agile switch.  It takes time for agile teams to become successful.  The more time you allow it to run, the more likely it will be successful in the long run.  Too many teams hit the first agile bumps and hurdles and instead of trying to learn from them, they pull the plug and declare their adoption of agile a failure.  There are many stages an agile adoption goes through and some can be painful from many points of view.  Slow down, take a deep breath, and keep trying.

So, what should you do if your agile adoption is "failing"? Here's a hint: Agile is HARD.  Ask yourself some of the questions above and see what might be causing the failure.  I believe that too many organizations only half-heartedly adopt agile and pull the plug far too early before it has a chance to prove itself.  Give agile a try, give it some time, and think hard about the six questions posed above before you pass judgement on your agile adoption.