Skip to main content

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.

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.
Unknown 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.
Unknown 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.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio