At Silicon Valley P-Camp ‘10 (March 13th), Rich Mironov led a session on “How Agile Changes Waterfall PM Processes and Thinking.” This was a tall order for a 45-minute colllaborative session with 120+ attendees, so we ran a real-time exercise in creating, prioritizing and attacking a backlog of agile PM issues. The room was full of enthusiastic attendees, both agile veterans and newbies, with good insights/advice from the crowd.
Agenda:
- Handful of level-setting slides (< 15 minutes) – see the slides
- Prioritize and time-box questions / issues raised by the group, i.e. build a backlog (< 10 minutes)
- Tackle issues based on priority (20 minutes, allocated 5 minutes each for top 4 issues)
- Thumbnail retrospective (3 minutes)
Rather than just talking about agile thinking and agile processes, we did a tiny re-enactment of some key process steps. The group raised 7 issues and ranked them as follows:
1. How much should/must we document requirements? – TIME-BOXED to 5 MINUTES
2. How to prioritize a list of 100 items (tools and strategies for handling long lists) – TIME-BOXED to 5 MINUTES
3. Where does UED/UI fit? We added architecture, since that has many of the same issues. – TIME-BOXED to 5 MINUTES
4. Agile metrics – TIME-BOXED to 5 MINUTES
5. How to deal with waterfall thinkers?
6. What to do about opinionated chickens (i.e. those who are interested but not committed)
7. What about engineers who don’t like product management?
This helped remind us of the essential nature of backlogs: that we don’t get everything done in any one iteration or release, but attacking the highest priority items gets them done first. In our (very limited) 5 minutes per topic, there were good suggestions and solutions from the floor, including (by topic):
1. Attack requirements iteratively, with less detail up front and more as teams engage with specific stories and raise questions; aim for ‘just enough’ based on team’s knowledge; do enough to motivate the next discussion with Dev team.
2. Prioritize only the top portion (e.g. 30 items) of your list and leave the rest for last; use a scoring/weighting scheme spreadsheet to group and rank items; apply various tools called out by the participants
3. Rich’s strong bias that a UED framework must exist at the beginning of a project, just as a product architecture must exist if this is a complex cross-team effort, and just as a business model/customer segmentation theory must be in place before spending lots of money on development. Sketching of the “one ahead, one behind” model for designing and testing UED elements.
4. A very brief extension past team’s story velocity toward economic value metrics per story or epic.
In a whirlwind retrospective (purely for structural completeness), the collective wisdom was that next time we might actually propose solutions to the above rather than just talking briefly about them.
Some of this material was lifted from earlier discussions and presentations on product manager/product owner issues, for instance this Product Camp NYC talk.
I spent 2006 consulting to small tech companies, including seven months as an interim executive. I also nearly co-founded a start-up. Come year-end, though, I find that I haven’t created a new company or joined a fledgling venture. This brings to mind discussions of commitment and “burning your boats.” 
Product managers are usually the people who “own the gap” for their specific products: identifying all of the missing or incomplete features and services and supporting processes that customers need for a successfully experience. This discussion is about elevating that concept to the product executive, who should be looking for systemic problems in the company’s end-to-end production cycle. 
Recently, I had lunch with a bright young product manager trying to perfect the process for deciding which features to include in his next product release. Skipping past theory about “internal ROI” and other quantitative approaches, we talked about having to choose among the many demands for enhancements from sales teams: that MRDs are only the starting point in an ongoing lobbying campaign for product improvements. In other words, product managers will always have to manage the emotional world of people and internal politics.