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.
One of the areas where I don’t have a good rule about when to believe and when to question is in customer development. While the model is very iterative, the amount of effort spent per iteration and the estimation of the quality of data coming back is something I need to learn more about. I’ll ask that question of Bob Dorf, the guest speaker of a free customer development event I’m putting together with General Catalyst in two weeks as part of FutureM. Bob is a long-time partner of Steve Blank, the father of customer development, and a co-author of Customer Development: The Second Decade—a dramatically-updated Four Steps to the Epiphany. This is going to be the first “under the covers” look at the latest in customer development.
I hope those of you near Boston can come to the event. Even if you can’t, please share the details with your startup friends from the main event page so that they can benefit from Bob’s perspective and the discussion.
Interesting distinction that you’re making between ideologies and methodologies.
At a more meta level (including, but not limited to business processes) it seems like your post points to a situation where if something is considered “general knowledge” or accepted as “a best practice” and therefore isn’t questioned, than it’s a candidate for potential disruption.
Whether it’s applied to the case of a new development methodology challenging the generally accepted process, or a startup challenging the way all the major players in the market operate, it seems like the same lesson… The best opportunities to create a lot of value begin with questioning why something is done the way it is, coming up with a hypothesis for an alternative way to do it, and having both the courage and resources to test your hypothesis until you come up with an answer, one way or the other.
Josh, the twist here is that sometimes it take a level of familiarity with a topic to be able to question it successfully.
And yet… we have the case of (youthful) ignorance as a factor in coming up with successful disruptive ideas, practices, and products.
Pingback: Technology By Day » Agile ideology in startups « HighContrast
Pingback: The Startup Holy Trinity « HighContrast
Pingback: The Zen of fundraising « HighContrast
Mr. Simeonov, do your thoughts on methodology over ideology apply to political thinking too?
They substantially do.
I have roots in the former Soviet Union … hence I am very wary of ideologies. As a practicing software developer, I am deeply suspicious of Agile Programming. If I or my colleagues come out and express out doubts on Agile Programming, we are afraid of the consequences. What is this all all about? I seriously don’t think the size of the organization means anything. My colleagues all make jokes about AG but we know that we need a paycheck. Managers are all “true believers”. Testers are “polytruki”!! ( I see Agile Programming like central planning in the Soviet Union ….. http://en.wikipedia.org/wiki/Gosplan / http://ru.wikipedia.org/wiki/%D0%93%D0%BE%D1%81%D0%BF%D0%BB%D0%B0%D0%BD_%D0%A1%D0%A1%D0%A1%D0%A0) What can I say! I despair. Instead I would suggest that we are seeking a theory of knowledge, i.e. epistemology. . Ironically Michael Polyani struggled with these issues … http://en.wikipedia.org/wiki/Michael_Polanyi …. his classic book on epistemology is “Personal Knowledge” by U. of Chicago Press (a decidedly press for the doubting) => http://www.amazon.com/Personal-Knowledge-Towards-Post-Critical-Philosophy/dp/0226672883 …. on how we acquire knowledge! ….
Very Kind Regards,