Currently in the editing and production queue, for publication in the next couple of weeks, are the following documents by Yours Truly:
The role of product management in Agile development.
The role of product management in software as a service (SaaS).
NEW! The questions people have been asking us about Agile, and what they reveal about the state of Agile development practices.
Also in the works is a piece that I'm co-authoring with Thomas Keitt about serious gaming as a tool for requirements collection. Updates on the exact publication date of these documents are coming soon.
Unfortunately, the document about the future of CRM is coming next month. I'll give you a more exact ETA, Dear Reader, as soon as I can.
I'll confess, one of the more surprising results of my recent research into Agile development in practice is the large number of motives to go Agile. From eliminating useless documentation to shortening development cycles to making the schedule more predictable, there were as many different reasons for Agile as people I interviewed.
Perhaps that's part of the success story of Agile: partly by design, partly by historical accident, the Agile movement addressed many different needs. In this way, Agile is a lot like the Protestant Reformation. Remember junior high school history class, when we heard that Luther's protest conveniently occurred just when secular princes were looking for ways to gain independence from Rome? The Agile movement arrived when more was happening in the technology industry than just the disgust of developers with schedules in which no one believed, or projects that didn't deliver what the customer wanted.
Sometimes, personal or organizational change depends less on what new techniques you choose, and more on the fact that you're making any choice at all. For example, to some degree, losing weight is about making a commitment to some dieting technique, to be named later. Which diet you choose matters, of course, but it's not the sole determinant of weight loss.
In doing research here at Forrester, I keep having that thought as I skip merrily from topic to topic. Thinking about adopting some requirements tools? Good for you! The acknowledgement that you need better ways to track and analyze what customers want you to build, rather than what you prefer to build, is the first step towards greater product success. Before you choose the right tool, congratulate yourself on making that commitment.
Feel like the development team is going to lose its collective mind trying to apply some waterfall methodology? Congratulations! You're ready to look at the product development process in a whole new way. Soon, you'll be ready to pick the Agile methodology that works for you.