People like to have a clear, precise instructions for success.  We see this in diet fads, where there are very clear rules and the implication that if you follow the rules, you will succeed in losing weight.

Some people also follow clear, simple rules for other difficult tasks – getting rich, picking winning race horses or becoming a better, happier person.

The catch is this: what works for one person doesn’t necessarily work for another.  You followed the diet, but you didn’t lose the weight.  You joined the network marketing plan, but you didn’t make your fortune.

Software Engineering

The same tendency appears in the IT community.  Methodologies are embraced by developers eager for clear, simple steps that promise success to those who follow them.

Unfortunately, there is no magic formula for building software.   We hear anecdotal evidence from people who say, “I did X, Y and Z, and it worked for me!”.  Indeed it did, but that doesn’t necessarily mean that the same steps will work on your project.  It’s especially risky to follow the steps blindly, without adapting them to your particular situation.

So What Does This Mean?

Software development methodologies are not about coming up with a magic formula for success.  At least they shouldn’t be, and they shouldn’t be interpreted in that way either.

A good methodology gives you ideas and guidance, but it never asks you to switch off your brain.  A really good methodology encourages you to actively involve yourself in tuning the process to fit your team and your project.

Notes About Specific Processes

I believe that Extreme Programming (XP) has a particularly strong appeal to teams seeking a “formula” for success.  Something along the lines of, “If you follow all 12 XP practices, your project will be successful.”  That’s an overly simplistic interpretation, and I doubt it would be encouraged by the original authors of XP.

In reality, XP is like a diet. It can be hard to follow, and your results may not match those advertised.

Remember that there’s a variety of different agile methodologies.  I’d like to draw particular attention to Crystal Clear, because it discourages the “magic formula” approach and it’s designed to be easily followed.

Recommendations

• Don’t interpret any methodology as a formula for guaranteed success
• Do engage your brain when adopting a new process.
• Do familiarise yourself with several agile methodologies.  A broad perspective is safer than a magic formula.
• Do consider the customer’s interests when tailoring your methodology
• Please Don’t be offended if you feel that this page attacks your methodology (or your diet). It works for you, and that’s great.  I’m suggesting that it might not work so well for everyone else.  Perhaps their situation is different, or perhaps some of the reasons for your success lie outside the documented methodology.

Summary

The IT industry has a lot to learn from the agile movement.  It is important that we apply that knowledge effectively, without mistakenly reducing it to a magic formula.

See also:

• Dave Churchville writes about “Rule Followers and Rule Derivers“, with particular reference to XP.
• Phillip Tornroth writes “Extreme Programming is at once the most humble and arrogant idea I’ve ever encountered working in software development” and speaks out against the dogmatic approach.

Footnote:

In the second edition of Extreme Programming Explained (published in 2005), Kent Beck wrote:

Critics of the first edition have complained that it tries to force them to program in a certain way.  Aside from the absurdity of me being able to control anyone else’s behaviour, I’m embarrassed to say that was my intention.  Relinquishing the illusion of control over other people’s behaviour and acknowledging each individual’s responsibility for his or her own choices, in this edition I have tried to phrase my message in a positive, inclusive way.  I present proven practices you can add to your bag of tricks.

“Adding to your bag of tricks” is very different from adopting XP on an all or nothing basis.  The second edition is clearly not a one-size-fits-all formula.