I am not a fan of ideologies. Inflexibility of thinking or the ability to take reality into account rarely leads to great outcomes. Just look at history. Methodologies, on the other hand, I like. The difference between the two is in the level of critical thinking. A good methodology isn’t just a set template. It is an evolving, data- and introspection-driven process that’s very much reality-based.

There two big problems with methodologies, or rather, with the way we adopt them that lead to failure. The first is lack of commitment. The second is premature optimization.

Many methodologies require a significant investment of time and effort, not just of an individual but of entire teams and organizations, before the benefits start showing up. The animal brain inside us doesn’t like delayed gratification. We invest half-heartedly into a methodology and then back out. It’s like quitting karate training after a year because we can’t split bricks with our bare hands. Early data can be too random due to poor selection of data sources and small sample sizes, as in the case of a startup’s first customers. We have to give the new thing a chance.

At times we start tinkering with a methodology too soon, before knowing enough or having enough experience to understand the trade-offs we are making. We call it “adapting the process to our special circumstances.” (Funny how every one has special circumstances.) This is premature optimization–which is “the root of all evil” according to the venerable Donald Knuth. In agile development, for example, Jeff Sutherland, one of the creators of Scrum, calls this practice of the methodology “Scrum But” as in, “we do Scrum but in our case we don’t do A and B and we’ve started doing C.” Jeff and other agile practitioners have overwhelming evidence that organizations with little agile development experience are much more likely to lose than gain when they customize a methodology before having developed the experience and judgment to understand the impact of the changes.

I see many examples of useful methodologies failing inside startups because of the of the above reasons. Time pressure makes delayed gratification difficult. Resource and team constraints as well as passion, vision and arrogance make premature optimization seem like a very smart thing at the time.

Startups have to be “all in” for a good length of time in order to be able to get quality data about the performance of a methodology. They have to practice “suspension of disbelief”, a phrase I learned from my friend Charles Teague who now runs FitNow, maker of Lose It.

If the difference between practicing a methodology and practicing an ideology is in the level of critical thinking then how does suspending disbelief fit in? Let’s call it the practice of agile ideology. The idea is that before committing to suspend disbelief, a team needs to make an explicit decision about when it will bring full-strength, data-driven critical thinking back in. The goal of the “ideological period” is to protect us from our own worst instincts. The goal of the precisely-defined condition for allowing disbelief back in is to protect us from going native. Here are some practical examples:

• Agile development practitioners recommend that inexperienced teams go through at least 2-3 full iterations before they start tuning their practice of a methodology.
• In A/B testing you can use the convergence method to get a better sense of when to discontinue a test.