Yesterday, during an open space discussion about introducing agile development to an organization, questions were raised about what is the role of product managers and project managers in an agile process. Most agreed that this isn't addressed in the literature (at least to the group's knowledge of the higher profile writings) and it is one of the examples of why you need experienced help when beginning the transition to agile development. There are a lot of activities and roles present in real, working situations that are ignored in the literature.

Project managers are addressed somewhat in discussions of Scrum, for example. But I have read very little about the role of the product manager. Though many agile processes shy away from over specifying of roles (which I agree with), there is little guidance about the supporting activites these roles play. My concern, is that a naive or literal adoption of the processes outlined in the literature drops a lot of necessary work on the floor.

For example, a product manager typically collaborates with marketing to discuss schedules, the creation of marketing collateral, and launch plans. Many may argue these are outside the scope of development activities, that they are business activities, and not central to an agile process. What about product documentation? It isn't written by developers, but requires intimate knowledge of the product being developed. What about testing? There is a lot written about automated unit testsing and a little less about automated customer acceptance tests, but this is only part of the testing landscape, as I learned at Agile Fusion last week.

One idea I have that is half baked (as is this entry) is that if agile processes tried to address all the elements that necessary to ship a commercial product, for example, the result would resemble the Rational Unified Process. This would bring us back to where we are trying to get away from. I think the real value of all agile processes is a pragmatism that encourages flexibility and adjustments, rather than prescriptions and ceremony. Ken Schwaber, when talking about Scrum, highlights the feedback that is provided by Scrum (and other agile processes) to guide you to your destination. In an agile process, you know the goals (destination) but you don't know the road you will take to get there at the start. This is better than mapping out the entire journey in advance only to find a bridge along the way has been washed out.

So, I am left with the following desire or challenge. I would like to see some of these issues discussed or addressed, in the same fashion as processes such as programming has been addressed. I want guidelines, tools, mechanisms, heuristics, frameworks, techniques or advice related to issues like testing, product docunmentation, marketing, and all the other elements of software development that aren't directly related to programming, but necessary to ship product. In all the conferences and events I go to, these issues are frequently raised by those considering agile development. It seems like the literature ignrores or hides from these issues. When confronted, an agile advocate typically responds with some comment about "Well in real practice..." or "Oh yeah, you do..." which addresses the practical necessity of these issues. So, why is such a pragmatic philosophy hiding from such practical issues?