Sunday, March 01, 2009

Agile Is Not Just a Development Methodology

Recently, several of my favorite bloggers have debated the role of product management in agile product development:
You'll find my thoughts dispersed throughout some of the comments in these blog entries.

If you're an executive interested in the debate, here's what you need to know.

First, read a blog entry I wrote in June 2005 entitled "Agile Product Management". In it, I lay out some of the basics of waterfall and agile methods.

Second, read a blog entry I wrote in September 2005 entitled "BUFR". In the entry, I contended that the two main causes of problems with waterfall methods are big up-front design (BUFD) and big up-front requirements (BUFR).

Third, note that the most important set of problems that agile methods overcome stem from BUFR, not just from BUFD. Arguably, this realization renders agile more directly important to product managers than to developers.

An agile product manager works in a fundamentally different way with both developers and customers. It's not just a matter of how and at what pace the requirements are delivered to developers. It's also how the requirements are elicited.

An agile product manager doesn't just interview and observe customers to understand their problems. She involves customers in an iterative feedback loop by "releasing" preliminary versions of the product to them. This feedback loop provides a way of eliciting requirements after implementation has begun but well before the product is officially released into production.

It's unfortunate that the term "agile" originally applied only to development. If you look at agile product management as merely something that a product manager does to co-exist with agile development, then it does seem silly to adopt (or co-opt) the buzzword.

But it turns out agile doesn't just enable developers to design and implement code more efficiently and reliably. It also enables product managers to understand their markets more efficiently and reliably.

So the popular notion that agile methods help developers, and that they therefore need product managers to cooperate, has it backwards. The opposite notion is equally, if not more, valid. Agile methods benefit product managers, and they need developers to fall in line to enable agile product management.

11 comments:

Adam said...

Well said, Roger.

I am completely on-board with showing clients prelim version of a product (potentially even mock-ups to get a feel in some cases) in order to gather feedback early and often.

Most people in the old-guard don't subscribe to this for the simple reason that, "you don't show clients anything until it's done."

Or they are lying during the sales cycle and the client has signed-on under the allusion of vapor ware...

bob said...

In my effort to better understand the "agile PM" mindset, can you tell me what sort of pool you draw these customers who give feedback? Are you getting feedback from the same people over and over, or do you spread the feedback out? Please note I have not called "agile PM" baloney in this post.

Roger L. Cauvin said...

Bob, practicality and circumstances determine the pool of customers who give feedback. Whenever I interview prospective or existing customers, I ask them to enroll in various programs:

1. Survey Program - customer opts to receive and respond to questionnaires.
2. Interview Program - customer agrees to follow-up interviews.
3. Demo Program - customer agrees to regular or occasional demos.
4. Ethnography Program - customer agrees to be observed in her native environment.

For simplicity, sometimes I present all of these individual programs as part of a single customer advisory board program.

Now, the answer to your question: I draw upon the customers who have opted to participate in demos and provide feedback. The particular customers in any individual case depends on their persona.

Why do you ask?

Roger L. Cauvin said...

Bob, I should add that a product manager can derive value from iterations even without "releasing" demos to actual customers. Sometimes the product manager himself discovers potential market problems by trying the demo. Then the product manager can incorporate this knowledge of potential market problems into future interviews and surveys, even if the customer never actually sees the demo.

Mike Lunt said...

I completely agree. One area where I don't see a lot of writing is how product managers deal with executives that still believe in the up front design and feel that they cannot market effectively without a feature set promised on a certain date. In other words, it would be great if there was a manual on training/convincing others on the business (i.e. not development specific) advantages of using agile.

info said...

Roger,

I'll post a response soon, but just want to point out that I've actually argued on my blog that Product Management has always been "agile" and it's Engineering that is now catching up.

http://onproductmanagement.net/2008/10/30/agile-pm/

Saeed

Roger L. Cauvin said...

I'll be interested in your response, Saeed. I've read your blog arguing that product managers have always been agile. I think there are some clear counter-examples.

First, take the typical 50 page requirements thrown over the wall to developers. To the extent that product managers resisted creating such documents, it wasn't because they were agile. It was because they were either lazy or didn't want to get into design details.

Second, I challenge you to find an example prior to the popularity of agile where the product manager pushed for frequent, regular iterations. If product managers were truly agile, you should be able to find numerous examples.

John Peltier said...

Roger, in a way, it seems intuitive. With the assumption that iterations (perhaps not all, but at least "many") are being put in front of users, the product manager will observe reactions and receive input that wouldn't otherwise be provided. In that event, adjustments to the backlog are possible that wouldn't otherwise be.

So perhaps those who argue it's only a development methodology are simply not putting interim builds in front of customers.

Chris said...

15 years ago, before I'd heard of agile development, Curt Rawley, then CEO of Avid Technology, told me how they had developed the first Avid editor; "build a little, ship a little, build a little..."
If you are developing a truly innovative product and carving out a whole new market (as they were), how else can you do it without getting it completely wrong?

Don Jarrell said...

Excellent article, Roger.

I have frequently denied Agile PdM as an accommodation or adapttion to Agile development, and still believe PdM should not get ensnared with,or defined by, whatever is the development process. You put it very well as its own approach, that is complentary to Agile development and quite probably - or in best cases - is the horse rather than the cart.

Roger L. Cauvin said...

Thanks, Don. I've observed a lot of defensiveness among product managers when it comes to agile development. The defensiveness usually comes in the form of stating that agile is merely for developers or that product managers have always been agile. It sounds like you and I agree that there's no reason to be defensive.