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.
In the second of three posts about the product management hierarchy, we’ll focus on technology product managers (PMs) who’ve been in their jobs long enough to consider what comes next. (User story: “As a Senior Product Manager, I want to be promoted to Director so that I get more money and respect and glory.”)
A thoughtful choice between “I” and “we” and “you” is a reflection of the workplace emotional temperature: are managers and executives motivating line employees to do their best, or “throwing them under the bus?” Are we rewarding cross-functional cooperation and market impact, or angling for promotion and impressing our peers? 
What: “Reducing Risk through Agile Product Planning” webinar