Patient: Doctor, it hurts when I do this…
Doctor: Then stop doing it…
A wonderful definition of insanity is “doing the same thing repeatedly, and expecting different results.” Yet, for some strange reason, we persist in using methods that are not working. On several projects at a past employer, I was hearing reports of our corporate-branded custom methodology resulting in late delivery, incorrect delivery, and reduced features, etc. The argument given was always “this extraneous factor happened,” or “the customer kept changing their minds,” or “the customer wasn’t implementing the methodology properly.”
What was the solution? Why, to do the same thing again, only harder! This I hear from many of my colleagues quite frequently. When all is lost, and the methodology is failing, cling more heavily to its rules and structures. Now sometimes this is valid. If, in fact, the methodology is being poorly implemented, and if the methodology is supportive of the environment and culture and circumstance of the project, then by all means, tighten up the implementation. Sadly, however, seldom is a proper analysis done of the fitness of the methodology to the needs of the project.
One of the very nice things about Scrum, for example, is that it is a short-cycle iterative feedback system. It is not a large methodology with lots of process. In a sense, it is a process for uncovering the work that needs doing, and for structuring that work in a highly compartmentalized way. Because of this, it is often quite resilient to external factors. Also, Scrum assumes that outward conditions will change, and assumes further that many of these changes are entirely out of the project’s control. Therefore Scrum is organized to find these externals irrelevant to its measures of success. It’s classic lateral thinking.
Why mention the above? Because the most common failure of a methodology is its inability to handle fundamental change. It requires a certain number of assumptions. If these assumptions change, then the whole project needs to be re-conceived. If you have a project lifecycle that lasts about 2 years, this is a very expensive re-conception. In this context, my above paraphrase could be re-stated to: “Insanity is doing the same thing, in a different context, and expecting the same results.”
With Scrum and other empirical processes, you re-formulate the project on a cyclical basis (say, a month). Thus, all new information can be assumed for the next cycle safely, and everyone is secure in the knowledge that all things can be re-examined next cycle. A problem is turned into a strength.
I’m not saying that Scrum can’t be misapplied, or that people can’t get into trouble there… but the fundamentals of Scrum and empirical processes are such that, if reasonably applied, you shouldn’t need to bang your head into the wall month after month. After all, in the end, if it’s that bad, it’s much cheaper to cancel a scrum project than a traditional plan-based project, because you will tend to know sooner that it needs to be cancelled.
“. The article talks about real-estate agents and motivation to push the price of houses they are selling $10,000 higher. The observation was that the $150 incremental gain for the agents (1.5% of $10,000) doesn’t make it worth their holding out an extra three weeks to get the higher number. Their interest is in closing quickly and moving on. They can often convince (through fear) the poor seller of a price that suits their interest. He wasn’t even sure if it was conscious, but it naturally flowed out of the asymetrical knowledge levels between the agent and the client. (I’m reminded here of the saying “A System’s Purpose Is What It Does”.) This asymmetry of knowledge is highly important in the Agile community’s current situation, in that it gives early practitioners the “expert” status, and lots of power to help or hurt the client.