Why Scaling Agile Doesn't Work (and What to Do About It)

There are now several frameworks designed to address the demand for "big agile."

In this talk Jez will explain the flaws in such frameworks, why they so often fail to produce the desired effects, and what we should do instead. He will also address some common organizational obstacles to moving fast at scale: governance, budgeting, and the project paradigm - and discuss how to address them. Warning: this talk will include liberal use of real, statistically sound data.

Video here: https://www.youtube.com/watch?v=2zYxWEZ0gYg

Transcript

1. @jezhumble #gotober | december 4 2015 why scaling agile doesn’t work (and what to do about it)
2. scrum- fall water-
4. cost “Even in projects with very uncertain development costs, we haven't found that those costs have a significant information value for the investment decision… The single most important unknown is whether the project will be canceled. The next most important variable is utilization of the system, including how quickly the system rolls out and whether some people will use it at all.” Douglas Hubbard | http://www.cio.com/article/119059/The_IT_Measurement_Inversion
5. batching up work “Black Swan Farming using Cost of Delay” | Joshua J. Arnold and Özlem Yüce | bit.ly/black-swan-farming
6. create feedback loops to validate assumptions accept our “requirements” will be wrong focus on value, not cost enable an experimental approach to product dev make it economic to work in small batches what should we do
7. impact mapping Gojko Adzic, Impact Mapping
8. @jezhumble Jeff Gothelf “Better product definition with Lean UX and Design” http://bit.ly/TylT6A hypothesis-driven delivery We believe that [building this feature] [for these people] will achieve [this outcome]. We will know we are successful when we see [this signal from the market].
9. experiments Different types of user research, courtesy of Janice Fraser
10. Jon Jenkins, “Velocity Culture, The Unmet Challenge in Ops” | http://bit.ly/1vJo1Ya
11. do less “Evaluating well-designed and executed experiments that were designed to improve a key metric, only about 1/3 were successful at improving the key metric!” “Online Experimentation at Microsoft”, Kohavi et al http://stanford.io/130uW6X
12. hp laserjet firmware division 2008 ~5% - innovation capacity 15% - manual testing 25% - product support 25% - porting code 20% - detailed planning 10% - code integration Costs Full manual regression: 6 wks Builds / day: 1-2 Commit to trunk: 1 week Cycle times
13. deployment pipeline
14. hp laserjet firmware team ~5% - innovation 15% - manual testing 25% - current product support 25% - porting code 20% - detailed planning 10% - code integration 2008 ~40% - innovation 5% - most testing automated 10% - product support 15% - one main branch 5% - agile planning 2% - continuous integration 2011 The remaining 23% on RHS is spent on managing automated tests.
15. the economics 2008 to 2011 • overall development costs reduced by ~40% • programs under development increased by ~140% • development costs per program down 78% • resources now driving innovation increased by 8X A Practical Approach to Large-Scale Agile Development - Gruver, Young, Fulghum
16. lightweight planning A Practical Approach to Large-Scale Agile Development - Gruver, Young, Fulghum
17. capacity planning Leading the Transformation - Gruver, Mouser
19. What obstacles are preventing you from reaching it? which one are you addressing now? What is the target condition? (The challenge) What is the actual condition now? When can we go and see what we learned from taking that step? What is your next step? (Start of PDCA cycle) improvement kata
20. improvement kata A Practical Approach to Large-Scale Agile Development - Gruver, Young, Fulghum
21. innovation culture “I think building this culture is the key to innovation. Creativity must flow from everywhere. Whether you are a summer intern or the CTO, any good idea must be able to seek an objective test, preferably a test that exposes the idea to real customers. Everyone must be able to experiment, learn, and iterate.” http://glinden.blogspot.com/2006/04/early-amazon-shopping-cart.html
22. create feedback loops to validate assumptions accept our “requirements” will be wrong focus on value, not cost enable an experimental approach to product dev make it economic to work in small batches conclusion
23. thank you! © 2016-7 DevOps Research and Assessment LLC https://devops-research.com/ To receive the following: • A copy of this presentation • A 100 page excerpt from Lean Enterprise • An excerpt from the DevOps Handbook • A 20m preview of my Continuous Delivery video workshop • Discount code for CD video + interviews with Eric Ries & more Just pick up your phone and send an email To: jezhumble@sendyourslides.com Subject: devops