Sunday, June 14, 2009

Was There Process Before Agile?

Reader June Kim recently wrote:

On p.328 of Volume 4 of your Quality Software Management series, the first line goes:

"Here's another example, mixing incremental development and hacking:"

In this Chapter 18, the process models you mention and describe are Waterfall, Cascade, Iterative Enhancement, and Prototyping (with Hacking and Rapid Prototyping as its variants). There isn't incremental development.

"incremental development" as you wrote on that page, doesn't appear before that line in the chapter.

Is Agile An Example of Incremental Development?

QUESTION: Which process model are you referring to when you wrote "incremental development"?
Is it one among the four process models that you mentioned earlier in the chapter, or Is it something different?

ANSWER: First, you have to remember that when QSM was written, there was no "Agile" development craze. We were doing various development process, some of which were given capital letters, some which were not, and some which were "owned" by certain advocates. I was trying to be descriptive then, not favor anybody's pet process.

There were some "owned" processes (using the hated word, "methodology," and charging tens of thousands of dollars for shelves full of notebooks which nobody read). I suppose some of them are still around, but most of the organizations I work with are now smarter than to fall for that fallacy. For the most part, every organization custom-tailored its own process (or, in most cases, processes, plural).

Of course, that's still true today. I don't find many organizations using some "pure" version of agile.

Where Do You Place Agile?

QUESTION: I am interested where you would put Agile process. I think Agile(XP and Scrum, for example) is closest to Rapid Prototyping as you described.

ANSWER: Historically, the people who first named "Agile" processes were borrowing the best of all these methods. You could also say that any agile process is a cascade (or iterative enhancement if you're actually putting each iteration's output into use). Agile is much more than these processes, making explicit many team practices to support the iterative nature of the development.

What Happens When the Customer Won't Participate?

QUESTION: If so, it has the same danger when the customer isn't willing to be the integral part of the process.

ANSWER: That's always the case, no matter what the method, if the customer is reluctant to participate. (Until the end, when they whine, "But that's not what we wanted.")

QUESTION: What could you do in this case? Drop Agile process?

ANSWER: It's not an Agile process if the customer (or surrogate) isn't participating. In fact, I would drop any customer who doesn't participate. That's the rule I use in all my consulting, too. I don't believe you can help people who aren't willing to help themselves.

QUESTION: Or, make the customer be the part of the process? Then how? This is still a hard question to me, even with 10 years of experience in agile.

ANSWER: It's definitely one of the hardest questions with Agile or any method. Hard for most technical leaders because they lack the training and skills to work with reluctant customers.

So, I train them in these skills (a major goal of the AYE Conference and the PSL workshop), but primarily everything starts by simply pausing the work unless and until the customer has been identified and persuaded to participate.


Brian said...

This is key. June asked whether we should drop the process when the client won't participate.

The answer is No, Never, Not Ever!

What you have offered to do, and the client accepted your offer (and that makes it a contract), if you got this far, is to apply your methodology - your way of doing business - to the client's problem as you understand it. If the client now reneges on the contract, you have no deal. If you can't get them back in the game, pick your favorite exit speech and exit stage left/right and that promptly.

Without being too hard on June, I think she is exhibiting wage-slave-think, assuming the client is the boss and is always right so we must comply with his/her every whim. As opposed to consultant-think, offering defined services (and no others) at a price.

Rick DeNatale said...

"There were some "owned" processes (using the hated word, "methodology," and charging tens of thousands of dollars for shelves full of notebooks which nobody read). "

Ahh, reminds me of the bad old days of AD/Cycle.

Gerald M. Weinberg said...

Brian, FYI, June is "he," not "she."

Otherwise, we're in complete agreement.

Brian said...

Brian, FYI, June is "he," not "she."

Here we go again with that gender thing!

Even though I was named after my mother's favorite uncle, Stephen Brian Manning, Junior (Uncle June), I didn't hesitate to assume your June was a female.

Rick DeNatale said...

Ah but with a name like June Kim, I'd be willing to bet that he is a Korean gentleman.

Gerald M. Weinberg said...

Rick DeNatale said...
Ah but with a name like June Kim, I'd be willing to bet that he is a Korean gentleman.

And you would win your bet, Rick.

June said...

Thank you, Jerry, for answering my question, and putting up here for open discussion. I appreciate it.

Brian, thanks for your comment. Yet, I see you made a couple of assumptions about me, which I can't but disagree.

The gender thing has been discussed already, and the second thing is "wage-slave-think".

I am famous(or infamous) for not being so willing to "comply with client's every whim" in my country.

My question on "whether we should drop the process when the client won't participate" was not my opinion. I was asking Jerry's opinion.

I agree that turning back on non-participatory clients can be a noble and wise choice.

However, I have to acknowledge that I sometimes forget about that principle and compromise, living as a loner in this harsh wage-slave-think market(usually there are other reasons, too, for example, I want to help the people at the bottom).

Channing Walton said...

The lack of customer collaboration is an interesting question. My experience has been that when I talk to real users they are very happy with the agile process.

My difficulties have always been getting past technical management, particular in banking, who believe that they understand everything that the end users need. They almost always don't understand and often add a lot of extra work.

Gerald M. Weinberg said...

Channing: "
My difficulties have always been getting past technical management ..."

You are SO right. My experience exactly. And it's not limited to banking, nor to technical management. Any time you're dealing with a surrogate (esp. a self-appointed one), you're likely to have this problem. START BY FINDING AND MAKING CONTACT WITH THE REAL CUSTOMER.

Brian said...

"Surrogates ... Real Customer."

Another key factor for me - make sure that you are dealing with "The Man", i. e., the person who knows the goals of the project and wants it to succeed and is willing and able to commit resources to the project.

This rules out the C-level manager or analyst who has no authority to pay you and also the purchasing agent who knows nothing and cares less about the project, only that it's cheap and the paperwork is correct.

Channing Walton said...

Brian, yes its important to deal with 'the man', but its interesting how little they actually understand of the day-to-day operations, workflow and minutia of the end-users that work for them.

Brian said...

Channing - Of course, "the man" may not know the nuts and bolts of the project. But s/he must be committed to the goals.

I work regularly (not by choice) with an organization whose "head" continually whines "Do I have to be involved in that?" Well of course he should, but by copping out, he not only avoids personal responsibility but also authorizes his underlings to do all sorts of stupid things.

Totally dysfunctional. Flunkies spending all their time and energy covering their ass.

Channing Walton said...

Brian, I think we are in violent agreement ;)