Pair PM-ing, An Exploration of an Idea

3,786 views

Published on

Published in: Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,786
On SlideShare
0
From Embeds
0
Number of Embeds
2,554
Actions
Shares
0
Downloads
4
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Pair PM-ing, An Exploration of an Idea

  1. 1. Pair PM-ingSilicon Valley Product Camp 2013
  2. 2. to Pair or Not to PairExploring Deep Questions
  3. 3. Spending Our Time• Intro’s• Perspective• Premise• Primer• Stories• Suggestions
  4. 4. Introductions 5 Seconds Each
  5. 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. 6. Your Turn5 Seconds Each
  7. 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. 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. 9. Pairing Primer• 2 people 1 workstation• Driver / Navigator roles• Rotate “often”
  10. 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. 11. Let’s Share Some Stories
  12. 12. First StoryPM’s pairing on 1 products
  13. 13. Second StoryPM’s pairing across products
  14. 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. 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. 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. 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. 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. 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. 20. Go Get a Pair Thanks &Happy Camping !!
  21. 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

×