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.

Experiential Learning vol 2: Inventing

Regular readers of this blog have probably noticed a reduction in my posting frequency in recent weeks. Perhaps you'll all forgive me when I tell you I've been distracted from blogging by finishing volume 2 of my Experiential Learning series, called Inventing or Invention, I can never remember which. Anyway, it says "invention" on the cover, and can be found here.

Anyway, it's about the part of experiential learning that comes after the experience--the part where we invent the learnings we've found during the experience. It's what converts an ordinary experience into a learning experience. If you're teaching experientially, you'll want to learn how to facilitate invention--but that's not all. The book is full of techniques I personally use to extract learnings from all my experiences, whether in a class or in life.

As we say in life-learning, "First you pay the tuition, then the learning is optional." If you want to take advantage of the learning you've paid for with your life, Experiential Learning: Volume 2, Invention is the book for you.

Shaping a Team

A Correspondent Writes

I have taken over a group of folks that I need to shape into a team. There are many issues including getting developers to write unit tests consistently, training my test engineers and deploying more test automation. More worrisome is that they do not want to change out of a poor pattern of behaviors. I suppose since they hit their delivery schedule they think things are OK. On the plus side, they say they are committed to quality.

What would you look more into? Tackle first? Is there an inspiring story I might share at my upcoming team building event to highlight the need to change?

Any advice is welcome and greatly appreciated.

Jerry Replies

Well, you're certainly experiencing a classical problem, one I've described in a number of places, including my Becoming a Technical Leader (in terms of my pinball expertise). They're stuck on a plateau, and it's going to take some skilled leadership to move them up to the next level.

The first thing you have to do is create a safe environment that will protect them while they are changing to new practices. Although those practices must be designed to improve the quality of their work, there is no doubt that at first they will slow them down and probably hurt quality. That's why they need protection.

Start small, with some step that ideally they will choose from a list you develop together. Choose something that's as sure to succeed as possible, and it will help them in some obvious way. In other words, you want to start with a guaranteed success, and then build up from there.

 Beyond that, I suggest you read my books on change

- BECOMING A CHANGE ARTIST

- CHANGE: Planned & Unplanned

- Change Done Well