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
6. Your Turn5 Seconds Each
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?
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
11. Let’s Share Some Stories
12. First StoryPM’s pairing on 1 products
13. Second StoryPM’s pairing across products
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
20. Go Get a Pair Thanks &Happy Camping !!
21. Some Content• A funny video (pairing bit @45 sec)http://vooza.com/videos/code-pigs• A critique of pairinghttp://techcrunch.com/2012/03/03/pair-programming-considered-harmful• A story about a PM & Developer pairinghttp://www.philmetcalfe.com/developer-and-product-manager-pair-programming• A story about Pair Designinghttp://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