Wheaties Syndrome

Every group of decent enough size always seems to have at least one person who looks at all the great tools out there, especially those used or pushed by the thought leaders, and will scream to anyone who will listen that if you only start to use these tools, it will solve all the problems being encountered. They probably ate Wheaties as a child thinking they would grow up to be a great baseball player, too. This applies to methodologies, too. If you makes big mistakes because you didn't understand how to implement a practice well, how could you have known that this practice would solve your problems? Coming up with new rules that make the practice or tool "work well" simply smells of the tool or practice being flawed of incomplete and your own talents making it work.

One may think that the unasked question is "Why would this be beneficial?" or "How does this solve our problem?", but I've started to hit on the big one being "Why did this work for them and how are we different?" This helps to highlight that tools are specific things...that the hammer won't get the brick secured to the other brick very well. Too often, as well, methodologies and tools are mashed-up, with one become tightly linked with the other. Agile needs Fitnesse or TDD, for example. (No! Automated testing allows for more complicated code to be developed and increases productivity. Any productivity gains Agile gets credited with is an industry glow effect from TDD)

I've found that the best way to minimize the flare-ups of Wheaties Syndrome is to ask for separation of tools and methodologies. Explain why this method would work for us with out the tool. Explain why this tool will work for us without the method. More often than not, it's the right tool used correctly that will provide the most benefit. Methodologies are the way that consultants and book writers latch onto the tool and try to steal the benefits (see also: Linux).