leading and motivating engineers - what product managers need to know - product camp '17
TRANSCRIPT
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
Ron Lichty, Managing Development &
Product Teams
SOFTWEST
2
Annual Study of Product Team Performance
http://www.ronlichty.com/study.html © Ron Lichty 3
* Addison Wesley
*
© Ron Lichty 4
Training Teams: Agile
1-4 weeks
© Ron Lichty 5
Debugging Software Teams
© Ron Lichty 6
Debugging Software Teams
© Ron Lichty 7
Debugging Software Teams
© Ron Lichty 8
Debugging Software TeamsTransforming Chaos to
Clarity• Product Management is essential
© Ron Lichty 9
Debugging Software TeamsTransforming Chaos to
Clarity• Product Management is essential– Technical– Effective– Experienced
© Ron Lichty 10
Debugging Software TeamsTransforming Chaos to
Clarity• Product Management is essential
– Technical– Effective– Experienced
• Product Managers have to lead– Vision– Data– Collaboration– Prioritization
© Ron Lichty 11
Vision
pixabay.com
© Ron Lichty 12
Scattershot, Hit-or-Miss Development
pixabay.com
© Ron Lichty 13
Scattershot, Hit-or-Miss Development
• It’s PdM that supplies consistent direction– vision– roadmap– prioritized backlogs of stories
© Ron Lichty 14
It Starts with Vision
pixabay.com
© Ron Lichty 15
… Based on Data
© Ron Lichty 16pixabay.com
Your Opportunity:Engage Developers with Real
Users
pixabay.com
© Ron Lichty 17
Engage Users
• Open a connection to users for developers
• Remember: It’s about delighting users!
18
Project WorkflowVision
Project Workflow
Roadmap
Vision
Project WorkflowVision -> Roadmap ->
Project
Project Workflow
Epics & Stories
Listin
gProject
Cost of Adding Features Spikes
pixabay.com
© Ron Lichty 23
Project Workflow
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Listin
gProject
Project Workflow
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Sizing
Listin
g
Sizing
Project
Project Workflow
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Sizing
Orderi
ng
Listin
g
Sizing
Project
Order the Backlog by Value
© Ron Lichty 27pixabay.com
Ordering: Value / Size: ROI
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Sizing
ROIOrderi
ng
Listin
g
Sizing
Project
Ordering: Not Just ROI
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Sizing
ROI/Dependencies/
Risk
Orderi
ng
Listin
g
Sizing
Project
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
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
Ordering: Not Just ROI
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Sizing
ROI/Dependencies/
Risk
Orderi
ng
Listin
g
Sizing
Project
Project Workflow
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Sizing
Urgency / RiskROI/Dependencies/
Risk
Orderi
ng
Listin
g
Sizing
Project
Project Workflow
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Sizing
Urgency / RiskROI/Dependencies/
Risk
Orderi
ng
Listin
g
Product BacklogInt
egrati
ng
Sizing
with ~ 2 ½ sprints detailed
Project
Provide Clarity: Scope or Deadline???
© Ron Lichty 35
Project WorkflowProject
Technical PBIs*
Epics & Stories
*PBI: Product Backlog Items; list provided by technical leadership
Two-Pass Sizing
Urgency / RiskROI/Dependencies/
Risk
Orderi
ng
Listin
g
Product BacklogSprint Backlog
Integr
ating
Sizing
Planni
ngwith ~ 2 ½ sprints detailed
Sprints Are a Mishmash of Stuff
pixabay.com
© Ron Lichty 37
Scattershot, Hit-or-Miss Development
• It’s PdM that supplies consistent direction– vision– roadmap– prioritized backlogs of stories– theming sprints
© Ron Lichty 38
Theme Your Sprints
© Ron Lichty 39pixabay.com
pixabay.com
© Ron Lichty 40
Manage Stakeholders / Protect Developers
pixabay.com
© Ron Lichty 41
Be an umbrella to the noise
--John Evans photo
© Ron Lichty 42
Be an umbrella to the noise
--John Evans photo
• Speed of Ideation exceeds the Speed of Development
© Ron Lichty 43
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
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
Let developers focus
© Ron Lichty 46pixabay.com
Don’t Be a Source of Interruptions
© Ron Lichty 47pixabay.com
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
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
--Larry Maccherone, The Impact of Agile Quantified, Rally, 2013
Don’t Be a Source of Multitasking
© Ron Lichty 50
Enliven Your Developers!
pixabay.com
© Ron Lichty 51
Connect the vision with the team’s work
http://www.ManagingTheUnmanageable.net© Ron Lichty
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
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
Personify Agile Culture
© Ron Lichty 55
Personify Agile Culture
© Ron Lichty 56
• Focus on fomenting amazing teamwork– on supporting the team becoming high performance
Deliver Clarity
© Ron Lichty 57
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
Share the “What” not the “How”
• It’s subtle
59
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
Listen to Developers
pixabay.com
© Ron Lichty 61
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
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
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
Projects Not Suitable for Agile?
65
Projects Not Suitable for Agile?
• Micromanagement
66
Projects Not Suitable for Agile?
• Micromanagement disrupts Agile• Micromanagement prevents Best Teams
• Micromanagement prevents Learning• Micromanaged teams become order-takers
67
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
Partner
69
Photo by Esti Alvarez, Some rights reserved, http://www.Flickr.com/photos/esti/4638056301/
Debugging Software TeamsTransforming Chaos to
Clarity
Product Management is essential
© Ron Lichty 70
Debugging Software TeamsTransforming Chaos to
Clarity
Product Management leadership and
motivation are essential
© Ron Lichty 71
Rules of Thumb / Nuggets of Wisdom*
* 300 in the book / more at http://managingtheunmanageable.net/morerulesofthumb.html
© Ron Lichty 72
Ron Lichty Consulting • Interim & acting CTO/VP Eng roles / making development
hum– http://ronlichty.com, [email protected]
• 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 DaysThe Agile ManagerManaging Software People and Teams
© Ron Lichty 73