5. Hi My Name is Scott Gilbert
• I’m a product guy who likes Agile/Lean
• Been building new SaaS products lately
• Helped create P-Camp, 2013 Camp Organizer
• Pan, praise or poke me @AgileProductMgr
7. My Perspective On PM
• It’s a big tough job
– Too much work, not enough time
– Can’t cover the whole grid
• Covering the planning onion is hard to do
– Can’t be in 2 places at once (Team & Market)
• We feel like we could/should be doing better
• We generally don’t collaborate together
– But we kind of like to…look around
• We have hard problems to solve
8. Premise
• Engineers pair to solve tough problems and
achieve better outcomes.
• PM’s have tough problems to solve so why
can’t we pair too?
9. Pairing Primer
• 2 people 1 workstation
• Driver / Navigator roles
• Rotate “often”
10. Pairing Benefits
• Produce shorter programs, with better designs and fewer bugs,
• Typically consider more design alternatives
• Arrive at simpler, more-maintainable designs; they also catch design defects
early.
• Usually complete work faster
• “Impossible" problems become easy or even quick, or at least possible to
solve when they work together
• Knowledge passes between pair programmers as they work. They share
knowledge of the specifics of the system, and they pick up techniques from
each other
• New hires quickly pick up the team practices and learn the the system
• Improved discipline and time management. The partner "keeps them
honest”
• People are more reluctant to interrupt a pair than someone working alone
• Increased morale and greater confidence in the correctness of the code
14. Pairing on 1 Product
• The Situation
– Flipin the whole flipin’ Model and Brand
– 3 PM’s, 1 Product, 2 Teams*
– C-level tiger team met daily and made decisions
– Teams are executing and iterating weekly
15. Paring on 1 Product
• What we did
– Iterative solution definition using Jeff Patton’s
story mapping technique to find our MVP.
• I drove initial map set up
• My pairs helped navigated to find right solutions
• I updated stories and AC’s during/after each session
– Once we agreed, I handed off story map and they
drove implementation rolling stories into backlogs
– I was then free to handle rest of of the go to
market and other tasks
16. Pairing Across Products
• The Situation
– Implementing a portfolio-wide capability (Q1 ship)
– 4 PM’s, 5 Products, 5 Teams
– Each team at a different stage of development
• 1 already shipped a partial solution…the Pioneer*
• 1 already shipped a complete solution…the Standard
• 3 were in development…the Followers
– Historically not well “aligned”
• PM’s go it alone
• releases would come out and…“you did what?”
17. Pairing Across Products
• What we did
– Show and tell
• Document differences, issues, opportunities
– Prioritize the list agreeing upon acceptance
criteria and exceptions for each product
• Established a portfolio wide MVP
– Rolled stories based on above into each backlog
with coordinated release schedules
18. Suggestions
• Pairing Benefits
– More critical thinking
– Better understanding of the problem
– Find cross-product issues sooner
– More funner workin’ together
• Pairing Situations
– Roadmaps/Release Plans
– Backlog Grooming & Priority
– Market / User Research
– Epic Breakdowns / Story Mapping
– Lo-fi prototypes
– Stories, esp. the AC’s, esp. across the portfolio
19. Suggestions
• Pairing Practices
– No Cold Starts – have something minimal to start
– Do it in Chunks – Don’t be together all day
– Do it Consistently – Maybe through 1 release cycle
– Switch your Pair – Rotate and pair with others
– Switch your Role – Start as Driver, be Navigator
21. Some Content
• A funny video (pairing bit @45 sec)
http://vooza.com/videos/code-pigs
• A critique of pairing
http://techcrunch.com/2012/03/03/pair-programming-considered-
harmful
• A story about a PM & Developer pairing
http://www.philmetcalfe.com/developer-and-product-manager-pair-
programming
• A story about Pair Designing
http://www.slideshare.net/k4rl/the-psychology-behind-pair-designing
• An article on Product Managers and Owners
http://www.rallydev.com/community/agile-blog/how-staff-
appropriately-successful-transition-agile-product-management
