enthiosys agile product management - agile product management, motivated from within

Market problems are still THE problem — even when you’re Agile!

On Feb 18, 2009 I was the lead facilitator for a market research event run by Borland and Enthiosys on how Agile teams identify, express, organize, prioritize, and validate requirements in Agile projects.Quite naturally, the event was based on Innovation Games, which created a seriously fun and inviting context to explore these topics. This blog post captures our key findings from this event; We hope to present an even more complete result at the Agile 2009 conference, including a detailed description of our research methodology. Based on the data we gathered, we have developed the following observations about Requirements Management in Agile projects:

1. Roadmaps Are Essential.
   Roadmaps are considered even more essential in Agile environments than traditional environments, but only a few organizations had effective roadmaps (as one participant said, in with much frustration, “I would like to see further than ‘just over the hood’ where we are going.”). We believe that this is because shorter release cycles place even greater pressure on Agile teams to consider the “future beyond the release”. Many participants were not pleased with their roadmapping processes and felt that could be improved.
2. Market problem identification, prioritization, and valuation are still key challenges.
   While Agile is touted as a way to respond to change, product companies still must identify, prioritize, and quantify the value of solving market problems. Agile methods will highlight any deficiencies that product companies may have in these areas. Note that these were three of the top five issues facing product managers as ranked using the Innovation Game 20/20 Vision! (My friend Steve Johnson at Pragmatic would have predicted this—and he would have been right!).
3. Communicating “Requested” vs. “Built” is a challenge.
   A common challenge in traditional requirements management processes concerns requirements traceability. This appears to be changing in Agile project teams to requirements transformation, the challenge of communicating how an Agile team takes market feedback (such as product enhancement requests) and communicates market deliverables (which have been generalized and/or integrated with other requests). Participants noted that while there are some tools that help organize gathered feedback, no tools really helped in managing this transition (and some hypothesized that perhaps a tool can’t).
4. Simple or strict financial analysis of R&D investment choices and backlogs is not working.
   Calculating the return on R&D investment choices using traditional tools such as NPV or ROI is done poorly, or not at all. One participant reported that their organization approved projects with negative ROI! While seemingly irrational, this is a very successful organization, and these projects do contribute to the growth of the firm. This, it is clear that more alternatives to the prioritization of backlog items are needed. (This confirms what I first said last year in my blog—ROI based schemes for prioritizing product backlogs just don’t work!).
5. Simple tools do not scale.
   Simple tools (such as simple spreadsheets or shared documents) do not work even for small teams and no single tool does everything well for anyone.
6. Prototyping and mock-ups work!
   Participants were quite enthusiastic in their endorsement of paper prototypes, collaboratively developed hi-fidelity prototypes, and the continuous feedback loop afforded by time-boxed development cycles from early adopters and co-development partners. Many considered prototypes as replacements for documented requirements in some cases. While this is congruent with earlier advice in traditional projects, the “Agile twist” appears to be the emphasis on high-quality code and either planned or emergent architectures, which enable early prototypes to be transformed into customer-facing deliverables.

   Return to insights-tools