Moving Fast at Scale
Download as PPTX, PDF•3 likes•763 views
The document discusses strategies for organizations to enhance speed while maintaining stability in software development. It emphasizes the importance of autonomous teams, clear prioritization, iterative delivery, and disciplined problem-solving to achieve better outcomes and higher productivity. The author also highlights the significance of delivering minimal viable features and leveraging continuous experimentation to optimize results.
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