Successfully reported this slideshow.

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

1

Share

1 of 73
1 of 73

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

1

Share

Download to read offline

Description

Effective, experienced technical product management is crucial to make software development hum: Engineering and Product Management are symbiotic. Product managers lead and motivate by first establishing credibility with engineers, and by bringing vision, data, collaboration, prioritization, and protection. Ron Lichty has repeatedly been brought in to transform chaos to clarity in software development. Here’s what product managers can apply to lead and motivate engineers and make software development hum.


BIo:
Ron Lichty has, for 30-plus years, championed delighting customers. He believes that strong product/engineering collaboration is essential to achieving that goal. Ron co-authored the Addison-Wesley book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.ManagingTheUnmanageable.net) and annually coauthors the Study of Product Team Performance (http://www.ronlichty.com/study.html).

Ron spent seven years as a programmer, two years as a product manager, and 25 years managing product and development organizations at all levels - to VP of engineering, VP of product and CTO - at companies ranging in size from tiny startups to Charles Schwab,Stanford, and Apple.

He now consults across that realm, taking on fractional interim VP Engineering and acting CTO roles, training teams in agile, training managers in managing software people and teams, and coaching development teams and executives in making software development hum. (http://www.ronlichty.com)

Ron has long been a popular speaker at product, development and agile meetups and conferences. Ron@RonLichty.com

Transcript

  1. 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. 2. Ron Lichty, Managing Development & Product Teams SOFTWEST 2
  3. 3. Annual Study of Product Team Performance http://www.ronlichty.com/study.html© Ron Lichty 3
  4. 4. * Addison Wesley * © Ron Lichty 4
  5. 5. Training Teams: Agile 1-4 weeks © Ron Lichty 5
  6. 6. Debugging Software Teams © Ron Lichty 6
  7. 7. Debugging Software Teams © Ron Lichty 7
  8. 8. Debugging Software Teams © Ron Lichty 8
  9. 9. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential © Ron Lichty 9
  10. 10. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential – Technical – Effective – Experienced © Ron Lichty 10
  11. 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. 12. Vision pixabay.com © Ron Lichty 12
  13. 13. Scattershot, Hit-or-Miss Development pixabay.com © Ron Lichty 13
  14. 14. Scattershot, Hit-or-Miss Development • It’s PdM that supplies consistent direction – vision – roadmap – prioritized backlogs of stories © Ron Lichty 14
  15. 15. It Starts with Vision pixabay.com © Ron Lichty 15
  16. 16. … Based on Data © Ron Lichty 16 pixabay.com
  17. 17. Your Opportunity: Engage Developers with Real Users pixabay.com © Ron Lichty 17
  18. 18. Engage Users • Open a connection to users for developers • Remember: It’s about delighting users! 18
  19. 19. Project Workflow Vision
  20. 20. Project Workflow Roadmap Vision
  21. 21. Project Workflow Vision -> Roadmap -> Project
  22. 22. Project Workflow Epics & Stories Listing Project
  23. 23. Cost of Adding Features Spikes pixabay.com © Ron Lichty 23
  24. 24. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Listing Project
  25. 25. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Listing Sizing Project
  26. 26. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Ordering Listing Sizing Project
  27. 27. Order the Backlog by Value © Ron Lichty 27 pixabay.com
  28. 28. Ordering: Value / Size: ROI Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing ROIOrdering Listing Sizing Project
  29. 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. 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. 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. 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. 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. 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. 35. Provide Clarity: Scope or Deadline??? © Ron Lichty 35
  36. 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. 37. Sprints Are a Mishmash of Stuff pixabay.com © Ron Lichty 37
  38. 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. 39. Theme Your Sprints © Ron Lichty 39 pixabay.com
  40. 40. pixabay.com © Ron Lichty 40
  41. 41. Manage Stakeholders / Protect Developers pixabay.com © Ron Lichty 41
  42. 42. Be an umbrella to the noise --John Evans photo © Ron Lichty 42
  43. 43. Be an umbrella to the noise --John Evans photo • Speed of Ideation exceeds the Speed of Development © Ron Lichty 43
  44. 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. 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. 46. Let developers focus © Ron Lichty 46 pixabay.com
  47. 47. Don’t Be a Source of Interruptions © Ron Lichty 47 pixabay.com
  48. 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. 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. 50. --Larry Maccherone, The Impact of Agile Quantified, Rally, 2013 Don’t Be a Source of Multitasking © Ron Lichty 50
  51. 51. Enliven Your Developers! pixabay.com © Ron Lichty 51
  52. 52. Connect the vision with the team’s work http://www.ManagingTheUnmanageable.net © Ron Lichty
  53. 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. 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
  55. 55. Personify Agile Culture © Ron Lichty 55
  56. 56. Personify Agile Culture © Ron Lichty 56 • Focus on fomenting amazing teamwork – on supporting the team becoming high performance
  57. 57. Deliver Clarity © Ron Lichty 57
  58. 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. 59. Share the “What” not the “How” • It’s subtle 59
  60. 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
  61. 61. Listen to Developers pixabay.com © Ron Lichty 61
  62. 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. 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. 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. 65. Projects Not Suitable for Agile? 65
  66. 66. Projects Not Suitable for Agile? • Micromanagement 66
  67. 67. Projects Not Suitable for Agile? • Micromanagement disrupts Agile • Micromanagement prevents Best Teams • Micromanagement prevents Learning • Micromanaged teams become order-takers 67
  68. 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. 69. Partner 69 Photo by Esti Alvarez, Some rights reserved, http://www.Flickr.com/photos/esti/4638056301/
  70. 70. Debugging Software Teams Transforming Chaos to Clarity Product Management is essential © Ron Lichty 70
  71. 71. Debugging Software Teams Transforming Chaos to Clarity Product Management leadership and motivation are essential © Ron Lichty 71
  72. 72. Rules of Thumb / Nuggets of Wisdom* * 300 in the book / more at http://managingtheunmanageable.net/morerulesofthumb.html © Ron Lichty 72
  73. 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

Editor's Notes

  • http://www.ronlichty.com
  • The 2013 Study of Product Team Performance, http://www.ronlichty.com/study.html
  • Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, http://www.ManagingTheUnmanageable.net
  • Mike Cohn: citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993
  • Mike Cohn: citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993
  • Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, chapter 8
  • 3rd ‘C’ in Planning Meeting 3 C’s: Confirmation (after Cards and Conversation)
  • the “creamy center” of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, http://www.ManagingTheUnmanageable.net
  • Description

    Effective, experienced technical product management is crucial to make software development hum: Engineering and Product Management are symbiotic. Product managers lead and motivate by first establishing credibility with engineers, and by bringing vision, data, collaboration, prioritization, and protection. Ron Lichty has repeatedly been brought in to transform chaos to clarity in software development. Here’s what product managers can apply to lead and motivate engineers and make software development hum.


    BIo:
    Ron Lichty has, for 30-plus years, championed delighting customers. He believes that strong product/engineering collaboration is essential to achieving that goal. Ron co-authored the Addison-Wesley book Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.ManagingTheUnmanageable.net) and annually coauthors the Study of Product Team Performance (http://www.ronlichty.com/study.html).

    Ron spent seven years as a programmer, two years as a product manager, and 25 years managing product and development organizations at all levels - to VP of engineering, VP of product and CTO - at companies ranging in size from tiny startups to Charles Schwab,Stanford, and Apple.

    He now consults across that realm, taking on fractional interim VP Engineering and acting CTO roles, training teams in agile, training managers in managing software people and teams, and coaching development teams and executives in making software development hum. (http://www.ronlichty.com)

    Ron has long been a popular speaker at product, development and agile meetups and conferences. Ron@RonLichty.com

    Transcript

    1. 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. 2. Ron Lichty, Managing Development & Product Teams SOFTWEST 2
    3. 3. Annual Study of Product Team Performance http://www.ronlichty.com/study.html© Ron Lichty 3
    4. 4. * Addison Wesley * © Ron Lichty 4
    5. 5. Training Teams: Agile 1-4 weeks © Ron Lichty 5
    6. 6. Debugging Software Teams © Ron Lichty 6
    7. 7. Debugging Software Teams © Ron Lichty 7
    8. 8. Debugging Software Teams © Ron Lichty 8
    9. 9. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential © Ron Lichty 9
    10. 10. Debugging Software Teams Transforming Chaos to Clarity • Product Management is essential – Technical – Effective – Experienced © Ron Lichty 10
    11. 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. 12. Vision pixabay.com © Ron Lichty 12
    13. 13. Scattershot, Hit-or-Miss Development pixabay.com © Ron Lichty 13
    14. 14. Scattershot, Hit-or-Miss Development • It’s PdM that supplies consistent direction – vision – roadmap – prioritized backlogs of stories © Ron Lichty 14
    15. 15. It Starts with Vision pixabay.com © Ron Lichty 15
    16. 16. … Based on Data © Ron Lichty 16 pixabay.com
    17. 17. Your Opportunity: Engage Developers with Real Users pixabay.com © Ron Lichty 17
    18. 18. Engage Users • Open a connection to users for developers • Remember: It’s about delighting users! 18
    19. 19. Project Workflow Vision
    20. 20. Project Workflow Roadmap Vision
    21. 21. Project Workflow Vision -> Roadmap -> Project
    22. 22. Project Workflow Epics & Stories Listing Project
    23. 23. Cost of Adding Features Spikes pixabay.com © Ron Lichty 23
    24. 24. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Listing Project
    25. 25. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Listing Sizing Project
    26. 26. Project Workflow Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing Ordering Listing Sizing Project
    27. 27. Order the Backlog by Value © Ron Lichty 27 pixabay.com
    28. 28. Ordering: Value / Size: ROI Technical PBIs* Epics & Stories * PBI: Product Backlog Items; list provided by technical leadership Sizing ROIOrdering Listing Sizing Project
    29. 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. 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. 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. 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. 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. 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. 35. Provide Clarity: Scope or Deadline??? © Ron Lichty 35
    36. 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. 37. Sprints Are a Mishmash of Stuff pixabay.com © Ron Lichty 37
    38. 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. 39. Theme Your Sprints © Ron Lichty 39 pixabay.com
    40. 40. pixabay.com © Ron Lichty 40
    41. 41. Manage Stakeholders / Protect Developers pixabay.com © Ron Lichty 41
    42. 42. Be an umbrella to the noise --John Evans photo © Ron Lichty 42
    43. 43. Be an umbrella to the noise --John Evans photo • Speed of Ideation exceeds the Speed of Development © Ron Lichty 43
    44. 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. 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. 46. Let developers focus © Ron Lichty 46 pixabay.com
    47. 47. Don’t Be a Source of Interruptions © Ron Lichty 47 pixabay.com
    48. 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. 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. 50. --Larry Maccherone, The Impact of Agile Quantified, Rally, 2013 Don’t Be a Source of Multitasking © Ron Lichty 50
    51. 51. Enliven Your Developers! pixabay.com © Ron Lichty 51
    52. 52. Connect the vision with the team’s work http://www.ManagingTheUnmanageable.net © Ron Lichty
    53. 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. 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
    55. 55. Personify Agile Culture © Ron Lichty 55
    56. 56. Personify Agile Culture © Ron Lichty 56 • Focus on fomenting amazing teamwork – on supporting the team becoming high performance
    57. 57. Deliver Clarity © Ron Lichty 57
    58. 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. 59. Share the “What” not the “How” • It’s subtle 59
    60. 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
    61. 61. Listen to Developers pixabay.com © Ron Lichty 61
    62. 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. 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. 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. 65. Projects Not Suitable for Agile? 65
    66. 66. Projects Not Suitable for Agile? • Micromanagement 66
    67. 67. Projects Not Suitable for Agile? • Micromanagement disrupts Agile • Micromanagement prevents Best Teams • Micromanagement prevents Learning • Micromanaged teams become order-takers 67
    68. 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. 69. Partner 69 Photo by Esti Alvarez, Some rights reserved, http://www.Flickr.com/photos/esti/4638056301/
    70. 70. Debugging Software Teams Transforming Chaos to Clarity Product Management is essential © Ron Lichty 70
    71. 71. Debugging Software Teams Transforming Chaos to Clarity Product Management leadership and motivation are essential © Ron Lichty 71
    72. 72. Rules of Thumb / Nuggets of Wisdom* * 300 in the book / more at http://managingtheunmanageable.net/morerulesofthumb.html © Ron Lichty 72
    73. 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

    Editor's Notes

  • http://www.ronlichty.com
  • The 2013 Study of Product Team Performance, http://www.ronlichty.com/study.html
  • Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, http://www.ManagingTheUnmanageable.net
  • Mike Cohn: citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993
  • Mike Cohn: citing Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality, 1993
  • Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, chapter 8
  • 3rd ‘C’ in Planning Meeting 3 C’s: Confirmation (after Cards and Conversation)
  • the “creamy center” of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, http://www.ManagingTheUnmanageable.net
  • More Related Content

    Related Books

    Free with a 30 day trial from Scribd

    See all

    Related Audiobooks

    Free with a 30 day trial from Scribd

    See all

    ×