Forgive me for bringing up show tunes.  I love the old musicals. One of the true classics of American all or nothingtheater is the show Oklahoma.  I got to thinking about this in a very roundabout way the other day.  The song, called “With Me It’s All or Nothing” got stuck in my head.  Let me tell you why…

If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?”  These questions are fun to argue about.  They are mental candy.  But the bottom line is, just like candy, they can also be bad for you.  If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development?  Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts?  I don’t think it does.

The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief frustrated-programmerthat we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work.  If you have  an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”.  I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.

I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal.  The real power of Agile software development is not the fact that you do things in smaller increments, orpepperoni and mushroom pizza that you write your code test first, but in the supporting power of each of these elements.  The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing.  Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms.  If you didn’t want mushrooms, why did you order the pepperoni and mushroom?

This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development.  The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required.  After a while I couldn’t help but ask “why are we arguing about this?”  The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming.  You see, with me it really is All or Nothing.


Join the Discussion

    There are currently no comments.

    − 1 = 6