User>Driven

We've been exploring Agile methods where I work at ATG. A number of us attended a seminar given by Ken Schwaber on Scrum methods for product development and it stirred up some interest.

I've been doing a bunch of reading about agile methods, especially on how it affects the product owner (read: product manager) and requirements. Predictably, Steve Johnson at Pragmatic Marketing has a good summary of Agile requirements. It takes a little time to get past his trademark warnings against "ReqSpecs" (requirements that have too much implementation in them) and the need to say no to feature-creep, but the wait is worth it for his insights on the true motivations behind Agile.

If you can't wait, though, here are four paragraphs I think are key: 

Agile is often an attempt to manage our executives rather than to be more responsive to the market. The executives keep changing their minds, adding new feature requests, flip-flopping on issues. The agile approach of development is a technique in forcing executives to choose.

Management mandates rigor and precision before the scope of the work is truly understood. “How long would it take you to build it?” “Well, that depends on what it is, doesn't it?” “Yes, but give me a date anyway.” Management over-commits Development all the time.

As product managers, we should support the ideals of agile development. We want some process, but not too much process. Small iterations give us more flexibility to adapt to change. Team collaboration means less time is spent documenting, leaving more time for doing.

The key to any agile team is building products that people want to buy. To do that, an agile team needs a messenger for the market, a product manager who thoroughly understands the problems facing today’s customers. In agile programming—and frankly in any programming model—the effective product manager serves as representative of a market of customers.

Thanks, Steve!