Making Your Product Manager Productive by Clinton Wolfe
-
Upload
devopsdays-baltimore -
Category
Technology
-
view
15 -
download
0
Transcript of Making Your Product Manager Productive by Clinton Wolfe
• Dev => DevOps, lots of consulting
• Former DevOps Practice Lead at
OmniTI
• Now Senior Cloud Architect at Relus
Who am I?
Personal photo
Enter Continuous Integration
Product Dev QA Ops
Uncoordinated promotionCoordinated promotionFeedback loop
• Understand a PO
• Understand a PM
• Identify conflicts
• Build bridges
Changing the Dynamic
Via blogspot
• Often “non-technical”
• Defends the team to the
customer
• Little control over outcomes
• Transitional role
Meet Your PO
via lifebuzz
• Quantitative / financial background?
• “Plan the work, work the plan”
• PMP certification - “waterfall” thinking
• Often first software project
Meet Your PM
via oldpix
The PO/PM doesn’t understand any technical details!
Conflict Point: Common Language
The engineers speak in technobabble!
“I feel misunderstood”
Dev / Ops: PO / PM:
Can you speak in customer language?
Personal investment, workmanship bias
Being “Non-Technical”
ctak via flickr
To be a PO:
• Negotiation, compromise
• Business domain knowledge
• People skills, patience, listening
Being “Non-Technical”
Via brauctworks
It doesn’t matter how much we plan, there will always be
unexpected work.
Conflict Point:Unexpected Work
When we commit to a sprint, that’s exactly the work I as a PO expect to happen - anything else is unauthorized.
“No one understands where work comes from,or who commits to it.”
Dev / Ops: PO / PM:
Planned Work
Features
Infrastructure
Process improvement
Unplanned Work
Incidents
Emergent tasks
Rework
Types of Work
See The Goal and The Phoenix Project
• Involve Ops early
• Validate across functions
• Track dependencies
Unplanned Work - Emergent
kevin o’mara via flickr / CC-BY
• CI Pipeline!
• Automate to reduce error
• Add testing upstream
• Reach out, build trust
Unplanned Work - Rework
via imgur
PMs expect software developmentand operations to be predictable,
and it simply never will be.
Conflict Point: Estimation
The engineers can’t be trusted to give good estimates, and my schedules keep getting ruined!
“I cannot control the outcomesfor which I am accountable.”
Dev / Ops: PO / PM:
• Ops unfamiliar with Agile estimation
• Modeling => loss of detail
• Points have one input, one output
• Discards a lot of context and risk data
Conflict Point: Estimating Work
BestCase Typical Worst
Case Expected Risk Index
A 3 4 20 6.5 0.8
B 1 4 20 6.2 0.8
C 3 4 5 4 0.2
Inputs:• Best-Case• Typical• Worst-Case
Outputs:• Expected Effort
• (1xBest + 4xTypical + 1xWorst) / 6• Risk
• 1 - (Typical / Worst)
Solution: Three Estimates
See Software Estimation by Steve McConnell - p120
Every service must be scalable, monitorable, manageable -
basically, operable.
Conflict Point: Ops Needs
The customer didn’t ask for monitoring; we’re not going do it.
Later: Why do we keep getting surprised by outages?
“Operations needs are not considered…until too late.”
Dev / Ops: PO / PM:
• Early ops consults
• Whole team can add missed
stories
• Focus on working deployed
software
• Make tradeoffs clear
• inoperable == missed SLAs
Tactical: Operational Needs
egonsarv via pintrest
Separate Dev and Ops
CTO
VP Eng
Product Team A
Dev
Dev
Product Team B
Dev
Dev
QA Team
QAE
QAE
VP Ops
DB Team
DBA
DBA
Sys Team
SRE
SRE
DB Guild
Cross Functional Teams
Ops Guild
QA Guild
CTO
Frontend Team
Dev
Dev
QAE
DBA
SRE
API Team
Dev
Dev
QAE
DBA
SRE