Shark Jumpin' - II

Ben Edwards commented yesterday that in TV Shows, the characters age and the writers need to introduce new characters or plotlines to keep things interesting. Those things may make the show jump the Shark, argues Ben, but Agile has "just been around for a while and is gaining followers ad people, tired of the old ways of doing things, are looking for something that works better."

There's nothing wrong with that, and I applaud it, but I'd like to take a few moments to talk about the system effects of a mass movement.

First of all, it's now much less of a career risk to pursue agile development. Lots of companies are doing it, and "Agile RUP" or "Agile CMMI" is far less threatening than Extreme Programming. Automated Unit Tests, TDD, and xUnit frameworks are hitting the early mainstream, and vendors are adding refactoring tools to IDE's like Visual Studio.

Second, the original Agile movement was a re-action to the heavyweight, documentation-centric processes and methods of the 1980's and 1990's. More than a few people noticed that it's really hard to move a heavy boat, and that extra documentation adds mass. They also noticed that the "Crystal Ball" of a project beyond 90 days doesn't work. So a bunch of guys got together at the snowbird conference and suggested lean artifacts, planning in short increments, and adjustment.

There are several problems that the agile manifesto just plain punts on: For example, the idea that you can be on-time, on-budget, high-quality, feature complete. Forget about it - at the beginning of a large project, the customer doesn't even know what features he wants - who are we kidding?

But ... there's a problem. Lots of companies want to be able to predict all that stuff, to the point that it is better to be certain and wrong than to be uncertain. I have experienced this first-hand, and DeMarco and Lister comment on this in "Waltzing With Bears." Another Example: Extreme Programming doesn't have a concept of "architecture" or a role of Architect. It simply doesn't address the whole, er, problem space, that, um ... Enterprisy-Architecty-Modelling-y things address. (Whatever)

By "punting" on problems that it can't solve, the agile manifesto makes it possible to deliver great software regularly with considerably less waste.

The problem is that by saying "Embrace Change", we are also saying "Get over your fear of loss of control", and there are a whole lot of people in this world who don't want to. They want to be told that they can have their pie and eat it too. And they have titles like VP of Development, CIO, CEO, or CTO.

This means there is a market, with money, who want to be told how they can have all this agile stuff and also have CMMI, or Architecture, or Portfolio Management, Long Range Planning, or a Crystal Ball.

In fact, one of the consistent things I hear on software discussion lists is "We want to be agile but how do we solve problem X." Where problem X is something that is addressed by one of the technologies above.

For the first couple of years, the answers I saw on the lists were consistenly something like "Gee, we've been doing agile for two years and never had a problem with issue tracking. We talk about it at the standup, and we fix it." Eventually, though, I started to see answers more like this:

"Yes, my company thought of the same problem before we switched to Agile, so we use AgileBugTracker, by SuperAgileSoftware. It's great!"

It shouldn't be surprise; Adam Smith tells us that someone will start a business to exploit that opportunity.

So we get Agile RUP and Agile CMMI and Agile Portfolio Management, Agile Issue Tracking and Resolution, Agile Systems Architecture, and get slowly pulled back into the world we were trying to escape from.

The tent is too big and we've given credence to ideas and concepts that we should not have, to the point that it is very hard to tell "good Agile" from a bunch of consultants that can't ship software but know the right buzzwords.

Personally, I am a member of the American Society for Quality, and I have read Crosby, Drucker, Juran, and Deming: I went through the 600-page books and know the difference between "Getting It" and using the buzzwords. And I have real concern that Agile is in danger of becoming TQM or Six Sigma: Inherently good but misunderstood more often than not. That is what I mean by jumping the shark.

Next time: Agile CMMI, Jim Brosseau's comments, and more ...