eriksmartt.com/blog

Followup: “Agile Software Development Techniques and its Impact on Product Management”

I posted last week about going to a talk on “Agile Software Development Techniques and its Impact on Product Management.” Since I mentioned I was going, I thought it might be useful to post some followup comments, so here goes…

I went into the session hoping to hear some strategies and practical advise on applying Agile (and XP) to large-scale software projects that have key requirements and a timeline which is dictated by an outside driver. For example, let’s say you need to deliver a podcasting application for a piece of commercial hardware that has a fixed shipping date. Well, the answer from the session was simply that Agile isn’t always a good fit. Fair enough. And, to be honest, I was glad to hear advocates of Agile/XP being blunt about when the technique does or doesn’t fit well to a project’s needs. (Note: absent of the fixed shipping date and requirement to be installed on hardware that might not be easily upgraded, a podcasting client would normally be an excellent fit for XP.)

I was also hoping to here more opinions on mapping Agile/XP techniques to the Pragmatic Marketing process (that it seems all Product Managers have studied, including me.) I was a little disappointed here as well, since although the Pragmatic process was mentioned, there wasn’t a discussion on how the two approaches can harmonize.

Since the session, I’ve been looking for more overlap between XP and Product Management and ways to adapt some of philosophies to my current projects. One area where I believe the Pragmatic approach can adopt XP techniques in User Stories vs. Use Cases. (extremeprogramming.org has more on User Stories if you’re interested.) User Stories offer a simplified approach to documenting and explaining customer requirements, with a focus on involving the customer in the process. This is actually a much better fit for Product Management then Use Cases, since they are quicker to write, less technical, and completely focused on customer-driven requirements.

I was also glad to find that XP projects do have a role that somewhat maps to Product Management. They call it a Customer Representative. This role focuses on real customer requirements, much as Product Managers do already, but drops tasks like Market Research, Win/Loss analysis, etc. (which you might not want to do for a commercial product.)

Overall, I didn’t get what I wanted out of the session, but it has prompted me to look for more ways to influence product creation process using philosophies from XP. XP itself isn’t new to me, nor are Agile and Iterative development processes, but I rarely get to use them outside of personal projects. Applying XP in an environment that favors more traditional approaches will be an interesting challenge, but they pay-off for the team and the customers could be worth it.