When you shouldn't use Agile

原文：http://blogs.thoughtworks.com/ 作者：Jason Yip

If you've been in the XP/Agile game for a while, I'm sure you've been asked the question,

When shouldn't I use Agile?

, usually with an implication that if you can't find reasons why, then you're just another zealot trying to sell a silver bullet.

Having read Bill Waddell over at Evolving Excellence for a while, I'm imagining how he'd reply to someone asking the question,

When shouldn't I use Lean Manufacturing?

Or better yet, I'm imagining how Toyota would reply if one of their plant managers asked them,

When shouldn't I use the Toyota Production System?

Well, the only answer is you don't go Lean/TPS if you don't mind failing. If you don't mind having other people predict your bankruptcy, just keep doing what you're doing.

But Bill's a little more hardcore than I am, mostly because manufacturing failure ends up with a lot of good people losing their livelihood. In contrast, I've been at several places that suffer a phenomenon where the revenue is so high that any inefficiencies are hidden.

So, when shouldn't you use Agile? And by that I mean, when should you not want to deliver on the order of months or even weeks, not years? When should you not explicitly allocate time for regular forums during the project to reflect on how to improve how you're working? And then actually implement the improvements? When should you not want to modify your work environment to optimise communication (and I mean actually do it, not just talk about it)? When does cycle time not matter? When is it okay to be inflexible about features? When is it okay not to care about internal quality?

Well, if failure doesn't matter, it doesn't matter what you do. If you have no real competition and no variation in requirements, who cares? Just pray that the equivalent of Toyota never enters your domain.

Update: Change how I define "Agile"

SpiderMan From：http://blog.youkuaiyun.com/testwin