Continuous Delivery Agile's missing manual @hadynz

So what tools do you use for Continuous Delivery?

No content

Illustrations based on: https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff

“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.”

Mindset Culture Practices Motivators Key Ingredients:

Mindset Assumptions: ● Can’t prevent bugs in Production ● Prefer the risk of things breaking for more speed/velocity It’s a losing battle!

“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

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%

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

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

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

Convention wisdom = Prevention is better than recovery

But it should now be re-visited

Culture Prefer the risk of things breaking for more speed/velocity

If the organisation culture is not explicit, then resistance to Continuous Delivery is implicit Justin Latimer, Xero Product Architect

No content

No content

No content

No content

No content

Structured for autonomy Clear bounds of #ownership

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

Xero Monolith Microservices

@bradley_scott GM of Product @lukeryannetnz Product Architect Mark Schultz Product Owner

No content

No content

Development Practices Reducing Risk Inducing Ownership

Testing Confidence Speed (< 5min) First class citizen “Everyone owns quality”

Lowering Risk Small and frequent releases Feature flagging Canary deployments Pilot customers Monitoring and alerting Graceful degradation

Autonomy Decoupling units of work Favour code duplication over reuse Independent deployment of each unit Event driven integration Integrate with defined HTTP contracts

Motivators

Pain

Motivators Pain Reducing fear Greenfield development Long term speed

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

No content