Leading and Motivating Engineers - what product managers need to know - product camp '17

1. Leading And Motivating Engineers: What Product Managers Need To Know Ron Lichty, principal, Ron Lichty Consulting author, Managing the Unmanageable www.RonLichty.com www.ManagingTheUnmanageable.net

2. Ron Lichty, Managing Development & Product Teams SOFTWEST 2

3. Annual Study of Product Team Performance http://www.ronlichty.com/study.html© Ron Lichty 3

4. * Addison Wesley * © Ron Lichty 4

5. Training Teams: Agile 1-4 weeks © Ron Lichty 5

6. Debugging Software Teams © Ron Lichty 6

9. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential © Ron Lichty 9

10. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential – Technical – Effective – Experienced © Ron Lichty 10

11. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential – Technical – Effective – Experienced • Product Managers have to lead – Vision – Data – Collaboration – Prioritization © Ron Lichty 11

12. Vision pixabay.com © Ron Lichty 12

13. Scattershot, Hit-or-Miss Development pixabay.com © Ron Lichty 13

14. Scattershot, Hit-or-Miss Development • It’s PdM that supplies consistent direction – vision – roadmap – prioritized backlogs of stories © Ron Lichty 14

15. It Starts with Vision pixabay.com © Ron Lichty 15

16. … Based on Data © Ron Lichty 16 pixabay.com

17. Your Opportunity: Engage Developers with Real Users pixabay.com © Ron Lichty 17

18. Engage Users • Open a connection to users for developers • Remember: It’s about delighting users! 18

19. Project Workflow Vision

20. Project Workflow Roadmap Vision

21. Project Workflow Vision -> Roadmap -> Project

22. Project Workflow Epics & Stories Listing Project

23. Cost of Adding Features Spikes pixabay.com © Ron Lichty 23

24. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Listing Project

25. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Listing Sizing Project

26. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Ordering Listing Sizing Project

27. Order the Backlog by Value © Ron Lichty 27 pixabay.com

28. Ordering: Value / Size: ROI Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing ROIOrdering Listing Sizing Project

29. Ordering: Not Just ROI Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing ROI/Dependencies/RiskOrdering Listing Sizing Project

30. Groom the Backlog in Collaboration with your Tech Lead! • PdMs are responsible for the backlog • Critical technical Product Backlog Items: – just-enough architecture – resolving technical risk – automating building and testing – fixing critical bugs • Either – collaboratively interweave technical PBIs – assign nn% every sprint to tech team stories © Ron Lichty 30

31. Ordering Is More than ROI • Good user-story ordering is a collaboration with Eng – take dependencies into account – support risk-first development – reduce uncertainty – enable design to emerge – test architecture – listen for opportunities

32. Ordering: Not Just ROI Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing ROI/Dependencies/RiskOrdering Listing Sizing Project

33. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Urgency / RiskROI/Dependencies/RiskOrdering Listing Sizing Project

34. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Urgency / RiskROI/Dependencies/RiskOrdering Listing Product Backlog Integrating Sizing with ~ 2 ½ sprints detailed Project

35. Provide Clarity: Scope or Deadline??? © Ron Lichty 35

36. Project Workflow Project Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Two-Pass Sizing Urgency / RiskROI/Dependencies/RiskOrdering Listing Product Backlog Sprint Backlog Integrating Sizing Planning with ~ 2 ½ sprints detailed

37. Sprints Are a Mishmash of Stuff pixabay.com © Ron Lichty 37

38. Scattershot, Hit-or-Miss Development • It’s PdM that supplies consistent direction – vision – roadmap – prioritized backlogs of stories – theming sprints © Ron Lichty 38

39. Theme Your Sprints © Ron Lichty 39 pixabay.com

40. pixabay.com © Ron Lichty 40

41. Manage Stakeholders / Protect Developers pixabay.com © Ron Lichty 41

42. Be an umbrella to the noise --John Evans photo © Ron Lichty 42

43. Be an umbrella to the noise --John Evans photo • Speed of Ideation exceeds the Speed of Development © Ron Lichty 43

44. Be an umbrella to the noise --John Evans photo • Speed of Ideation exceeds the Speed of Development • Courage: “Great idea! I’ll put that in the backlog” © Ron Lichty 44

45. Be an umbrella to the noise --John Evans photo • Speed of Ideation exceeds the Speed of Development • Courage: “Great idea! I’ll put that in the backlog” • Prioritize: Developers want to do what customers value © Ron Lichty 45

46. Let developers focus © Ron Lichty 46 pixabay.com

47. Don’t Be a Source of Interruptions © Ron Lichty 47 pixabay.com

48. Source: Mike Cohn, citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993 Don’t Be a Source of Multitasking © Ron Lichty 48

49. taking communications overload into account Source: Rob Maher, “Increasing Team Productivity: A project focus creates waste and leaves value on the table”, Scrum.org Whitepapers Rob Maher, surmising that email, texts, IRC, chat, smartphones together represent a second “task” Source: Mike Cohn, citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993 Don’t Be a Source of Multitasking © Ron Lichty 49

50. --Larry Maccherone, The Impact of Agile Quantified, Rally, 2013 Don’t Be a Source of Multitasking © Ron Lichty 50

51. Enliven Your Developers! pixabay.com © Ron Lichty 51

53. Prioritize • Developers want to know they’re working on the stuff customers will value most! • There is no such thing as “2 top priorities”! • Get good at the mantra, “I’ll put it in the backlog” 53

54. Prioritize • Developers want to know they’re working on the stuff customers will value most! • There is no such thing as “2 top priorities”! • Get good at the mantra, “I’ll put it in the backlog” • “If everything is a priority, nothing is a priority.” — Sheila Brady, Apple project management guru 54

56. Personify Agile Culture © Ron Lichty 56 • Focus on fomenting amazing teamwork – on supporting the team becoming high performance

58. Deliver Clarity / Be Present • Clear requirements • Always based on the customer • An answer to every ambiguity • The “what”; for context the “who” & the “why” • Never the demotivating “how” • How we’ll know we’ve achieved success: UATs • 3rd ‘C’ in Planning Meeting 3 C’s: Confirmation © Ron Lichty 58

59. Share the “What” not the “How” • It’s subtle 59

60. Be Available • Be there with clarity – with the priorities / with the backlog – with the stories – with the acceptance tests – with the detail – with the clarity / the disambiguation 60

62. Listen to Developers • Support a culture of communication – at every level – with everyone • up, down, within and across • “We have two ears and one mouth. Use them in this ratio.” — Kimberly Wiefling 62

63. Listen to Developers “If you’re just using your engineers to code, you’re losing half their value.” “The single biggest innovator in many companies is the tech lead.” --Marty Cagan © Ron Lichty 63

64. Listen, Ask pixabay.com • Developers want to delight customers, too • They see opportunities in the code • Give them context / expect rich options © Ron Lichty 64

65. Projects Not Suitable for Agile? 65

66. Projects Not Suitable for Agile? • Micromanagement 66

67. Projects Not Suitable for Agile? • Micromanagement disrupts Agile • Micromanagement prevents Best Teams • Micromanagement prevents Learning • Micromanaged teams become order-takers 67

68. Projects Not Suitable for Agile? • Micromanagement disrupts Agile • Micromanagement prevents Best Teams • Micromanagement prevents Learning • Micromanaged teams become order-takers • Agile calls for everyone on the team to step up • Micromanagement causes everyone to step back 68

69. Partner 69 Photo by Esti Alvarez, Some rights reserved, http://www.Flickr.com/photos/esti/4638056301/

71. Debugging Software Teams Transforming Chaos to Clarity Product Management leadership and motivation are essential © Ron Lichty 71

72. Rules of Thumb / Nuggets of Wisdom* * 300 in the book / more at http://managingtheunmanageable.net/morerulesofthumb.html © Ron Lichty 72

73. Ron Lichty Consulting • Interim & acting CTO/VP Eng roles / making development hum – http://ronlichty.com, Ron@RonLichty.com • The book and the video training: Managing the Unmanageable: Rules, Tools & Insights for Managing Software People & Teams – http://ManagingTheUnmanageable.net • The study: The Study of Product Team Performance – http://www.ronlichty.com/study.html • Training: Zero to Agile in Three Days The Agile Manager Managing Software People and Teams© Ron Lichty 73