Definitely a [code smell](http://martinfowler.com/bliki/CodeSmell.html). If it doesn't violate [Single Responsibility Principle](http://en.wikipedia.org/wiki/Single_responsibility_principle) then it probably violates [Tell, Don't Ask](http://pragprog.com/articles/tell-dont-ask). Consider:

 - Can you summarize what your method does without using conjunctions (and, but, etc.)?
 - Are there subparts of your method that could easily [be grouped into another smaller method](http://brianwill.net/blog/2007/03/28/howto-decompose-your-code-into-functions/)? (This includes [complex creation of a local variable](http://sourcemaking.com/refactoring/replace-temp-with-query).)
 - If your flag determines which method to call on a parameter, is your parameter [doing too much](http://en.wikipedia.org/wiki/Separation_of_concerns)?
 - Does this method belong in one of your parameters? (You might notice if it [picks apart instance variables](http://www.idinews.com/quasiClass.pdf) in your parameter using [getters/setters](http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1).)

If it turns out not to violate one of those two principles, you should still use an enum. Boolean flags are the boolean equivalent of [magic numbers](http://stackoverflow.com/questions/47882/what-is-a-magic-number-and-why-is-it-bad). `foo(false)` makes as much sense as `bar(42)`. Enums can be useful for [Strategy Pattern](http://sourcemaking.com/design_patterns/strategy) and have the flexibility of letting you add another strategy. (Just remember to [name them appropriately](http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx).)

Your particular example especially bothers me. Why is this flag passed through so many methods? This sounds like you need to [split your parameter into subclasses](http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism).