As the research in Accelerate and in the DevOps Handbook shows, high-performing organizations deliver more rapidly, more repeatably, and more reliably. And as an organization scales, it becomes more and more important to get the product development process right. Drawing on the speaker's experiences leading high-performing organizations at Google and eBay, this session discusses the upstream parts of that process, focusing on organization, problem definition, and prioritization. We will discuss forming small, cross-functional teams with clear areas of responsibility. Then we will discuss the importance of clearly defining the problem we are trying to solve as a team. Finally, we will cover focus and prioritization -- how we decide what to do when. You will take away actionable techniques you can apply in your own organization.
15. Business / Domain
Alignment
<Business
Domain>
• Aligned around a business
problem
o Clear goals and metrics …
o … that matter to customers!
• Well-defined area of responsibility
o Single application / service or set of related
applications / services
• Grow by “cellular mitosis”
16. Ideally, 80% of project work
should be within a team
boundary.
17. Autonomy and
Accountability
• Give a team a goal, not a solution
o Measured by clear, customer-oriented metric(s)
• Give the team autonomy
o Let team own the best way to achieve their goal
• Hold team accountable for *results*
o Responsible for producing business value
o Responsible for the results of their choices
@randyshoup
20. Please tell us what
problem you are trying to
solve
Please just add this button
21. Engineering
Discipline
• Engineers are trained
in disciplined problem-
solving
o Not everyone is
• It is our job to help
clarify and refine the
problem
@randyshoup linkedin.com/in/randyshoup
22. “The Curse of
Knowledge”
• We understand the
options, tradeoffs,
and implications
• It is our job to help
others understand
them
@randyshoup linkedin.com/in/randyshoup
23. Engineering is about solving
problems.
Sometimes we solve those
problems by writing code.
27. Focus and
Prioritization
• We always have more to do than resources to do it
• Scarce resources require prioritization
o Every decision is a tradeoff
• Opportunity cost
o Deciding to do X means deciding not to do Y
@randyshoup linkedin.com/in/randyshoup
34. Fewer Things,
More Done
• Deliver Highest Priority Features First
o Don’t treat priority 1 and priority 5 the same
• Deliver Full Value Earlier
o Time Value of Money
o Benefit now is worth more than benefit in the future
• Deliver Value Along the Way
o Deliver increments along the way instead of everything at the end
• Deliver Value More Efficiently
o Multiple engineers can unblock one another
@randyshoup linkedin.com/in/randyshoup
35. eBay Machine-Learned
Ranking
• Ranking function for search results
o Which item should appear 1st, 10th, 100th, 1000th
o Before: Small number of hand-tuned factors
o Goal: Thousands of factors
• Incremental Experimentation
o Predictive models: query->view, view->purchase, etc.
o Hundreds of parallel A | B tests
o Full year of steady, incremental improvements
2% increase in eBay revenue (~$120M / year)
36. eBay
Site Speed
• Reduce user-experienced latency for search results
• Iterative Process
o Implement a potential improvement
o Release to the site in an A | B test
o Monitor metrics –time to first byte, time to click, click rate, purchase rate
2% increase in eBay revenue (~$120M / year)
41. Minimal Viable
Feature
• Build one great thing instead of two half-finished things
• Definition of Done != Perfect
o 80 / 20 Rule
• Marginal Cost vs. Marginal Benefit
• Reduce Scope, not Quality
42. • Minimal Viable Feature
• Automated Tests
• Released to Production
• Feature flag turned on
• Monitored
Definition of
Done