Moving Fast at Scale
•Download as PPTX, PDF•
3 likes•743 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Moving Fast at Scale
Similar to Moving Fast at Scale (20)
More from Randy Shoup
More from Randy Shoup (11)
Recently uploaded
Recently uploaded (20)
Moving Fast at Scale
- 1. Moving Fast at Scale Randy Shoup @randyshoup linkedin.com/in/randyshoup
- 2. Build the Thing Right Build the Right Thing
- 7. “I may be slow … but I do poor work!”
- 9. 2.5x more likely to exceed goals o Profitability o Market share o Productivity Moving Fast at Scale
- 10. Moving Fast at Scale •Organizing for Speed •What to Build / What NOT to Build •When to Build •How to Build
- 11. Moving Fast at Scale •Organizing for Speed •What to Build / What NOT to Build •When to Build •How to Build
- 14. Two-Pizza Teams 4-6 people “A team should be no larger than can be fed by two large pizzas.” -- Jeff Bezos, Amazon
- 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
- 18. Moving Fast at Scale •Organizing for Speed •What to Build / What NOT to Build •When to Build •How to Build
- 19. What problem are you trying to solve?
- 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.
- 24. “Building the wrong thing is the biggest waste in software development.” @randyshoup
- 25. “A problem well-stated is a problem half-solved.” -- Charles Kettering, head of research at GM
- 26. Moving Fast at Scale •Organizing for Speed •What to Build / What NOT to Build •When to Build •How to Build
- 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
- 29. Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Traditional Organizations Month 4
- 30. Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Continuous Delivery: Fewer Things, More Done Month 4Month 2
- 31. When you solve problem 1, problem 2 gets a promotion
- 32. Continuous Delivery: Iterative Development Month 4Month 2 1a 1b 1c 1d 2a 2b 2c 3a 3b 3c 3d 4a 4b 4c 5a 5b
- 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)
- 37. Moving Fast at Scale •Organizing for Speed •What to Build / What NOT to Build •When to Build •How to Build
- 38. “Do you have time to do it twice?” “We don’t have time to do it right!”
- 39. The more constrained you are on time or resources, the more important it is to get it done the first time.
- 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
- 43. Moving Fast at Scale •Organizing for Speed •What to Build / What NOT to Build •When to Build •How to Build