Continuous Delivery - Agile's missing manual

Traditional agile methods has been fundamental in transforming teams to operate in iterative and incremental ways, but what seems to be missing is some clear cut requirements on how software should be released and how frequently. Enter Continuous Delivery (CD) - a more prescriptive software engineering approach that enables teams to release more frequently into the hands of users, safely, quickly and in a sustainable way.

In this talk, I will be sharing the drivers that made us consider CD at Xero, and the value that it has brought to the business. But implementing CD was not just about the process. So I'll also cover the culture, practices and organizational changes we had to undergo to make deployments a predicable, routine affair that can be performed on demand with a warm cup of tea in hand.

Transcript

1. Continuous Delivery Agile's missing manual @hadynz
2. So what tools do you use for Continuous Delivery?
4. Illustrations based on: https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff
5. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Agile Manifesto, 2001 “Continuous attention to technical excellence and good design enhances agility.” “Deliver working software frequently” “Working software is the primary measure of progress.”
6. Mindset Culture Practices Motivators Key Ingredients:
7. Mindset Assumptions: • Can’t prevent bugs in Production • Prefer the risk of things breaking for more speed/velocity It’s a losing battle!
8. “Arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.” - Facebook Limit risk by failing fast
9. Original Wizard Express Wizard Account > Trial (Started Trial) Trial > Wizard (Completed Wizard) Wizard > Paying (Paying Customer) ACCOUNT > PAYING CUSTOMER (Overall Conversion) 77% 67% 31% 16% 90% 99% 18% 16%
10. Original Wizard Express Wizard Account > Trial (Started Trial) Trial > Wizard (Completed Wizard) Wizard > Paying (Paying Customer) ACCOUNT > PAYING CUSTOMER (Overall Conversion) 77% 67% 31% 16% 90% 99% 18% 16% Conclusion You’re probably wrong unless you’re in market and using actual data
11. Original Wizard Express Wizard Account > Trial (Started Trial) Trial > Wizard (Completed Wizard) Wizard > Paying (Paying Customer) ACCOUNT > PAYING CUSTOMER (Overall Conversion) 77% 67% 31% 16% 90% 99% 18% 16% Conclusion You’re probably wrong unless you’re in market and using actual data Everyone agreeing to something wrong doesn’t make it right. When you’re fast enough, cost of failure is minimal, so you can afford to learn
12. Original Wizard Express Wizard Account > Trial (Started Trial) Trial > Wizard (Completed Wizard) Wizard > Paying (Paying Customer) ACCOUNT > PAYING CUSTOMER (Overall Conversion) 77% 67% 31% 16% 90% 99% 18% 16% Conclusion You’re probably wrong unless you’re in market and using actual data Everyone agreeing to something wrong doesn’t make it right. When you’re fast enough, cost of failure is minimal, so you can afford to learn If you’re not prepared to fail, then you’re not prepared to learn and improve
13. Convention wisdom = Prevention is better than recovery
14. But it should now be re-visited
15. Culture Prefer the risk of things breaking for more speed/velocity
16. If the organisation culture is not explicit, then resistance to Continuous Delivery is implicit Justin Latimer, Xero Product Architect
22. Structured for autonomy Clear bounds of #ownership
23. Product Manager Product Group support: TGL Architect Agile Coach Design Embedded Dev/Ops Practice Leads Other Specialists Product Owner QA Testers Developers (Front & Back End) acting Agile Facilitator Purpose & Alignment
24. Xero Monolith Microservices
25. @bradley_scott GM of Product @lukeryannetnz Product Architect Mark Schultz Product Owner
28. Development Practices Reducing Risk Inducing Ownership
29. Testing Confidence Speed (< 5min) First class citizen “Everyone owns quality”
30. Lowering Risk Small and frequent releases Feature flagging Canary deployments Pilot customers Monitoring and alerting Graceful degradation
31. Autonomy Decoupling units of work Favour code duplication over reuse Independent deployment of each unit Event driven integration Integrate with defined HTTP contracts
32. Motivators
33. Pain
34. Motivators Pain Reducing fear Greenfield development Long term speed
35. Mindset Culture Practices Motivators Key Ingredients: Rapid recovery Top down support Org structure Pain Reducing Fear Green Fields Autonomy Reducing Risk Strategic Tests Manageable code base