Is it real or is it Agile? (Part 1)

Well, I'm writing my blog again, now that my book, Experiential Learning: Inventing, is now published on LeanPub.com. But after only one week, the feedback has started, and I feel a need to respond.

My friend and colleague, Markus Gaertner was the first to write, all the way from Germany:

"I just started reading your second book on Experiential Learning. One thing that confused me is in the chapter Design and Development Inventions where you make a positive reference to agile processes. This confused me since you usually write in a timeless manner, and I don't consider agile processes to be timeless in--say--20 years or so."

The passage in question read like this:

-----

Sometimes the specification turns on the meaning of a word, such as “support,” or “height.” The trouble is, you don’t know in advance which word it turns on ... that depends on the design possibilities. Therefore, an organization or process that discourages back-and-forth communication will generally do a poorer job of designing things. That’s one of the reasons agile processes can work so well.

-----

My first reaction to Markus's comment was that he was exactly right. My half-century of experience tells me that in 20 years, the "agile" craze will have petered out, just like so many before it--structured programming, HIPO, Nassi-Schneiderman charts, and dozens of others. So most readers in 2030 or so, won't even recognize the word "agile" as a code.

Yet forgetting the code doesn't mean that "agile" principles will have disappeared as good programming practices. I was specifically referring to two sentences from the Agile Manifesto (you know, that document that a dozen of the guys worked out a decade ago, without the help of any women):

1. "Business people and developers must work together daily throughout the project."

2. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

That's what I meant by "back-and-forth communication," and I believe those sentences will still describe effective programming practice a generation from now (as they did a generation ago, and two generations ago).

So Markus is right. There's no reason for me to date my book by using the code word, "agile." I published my Experiential Learning series with LeanPub.com so it could be a dynamic e-book, changing as the world changed and I learned to be smarter. So, I will update the next version with something like Markus's suggested wording:

"That's one of the reasons that software development works so well with bi-directional communication in place."

 (I'll also make a batch of changes suggested by Dani--who didn't even recognize the code word, "agile," in 2012--plus whatever other wisdom arrives from my readers.)

But, as usual, I'm not finished responding to Markus and Dani. In a later blog, I'm going to continue with some thoughts about what is "agile" really.