Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Similar to DevOps, Continuous Delivery and Deployment at Hyper Scale
Similar to DevOps, Continuous Delivery and Deployment at Hyper Scale (20)
Recently uploaded
Recently uploaded (20)
DevOps, Continuous Delivery and Deployment at Hyper Scale
- 1. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | DevOps, Continuous Delivery and Deployment at Hyper Scale Martin Hogg Senior Director Oracle Cloud May 30, 2018 1
- 2. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Scaling Your Team 2
- 3. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Lean Product Development 3 • Small cross-functional team. • Learning loop guides startups to product market fit & growth. • Learning loop guides later stage companies to optimal ROI & TTR. • Focus on reducing the cycle time. • But how do you scale this?
- 4. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Avoid Large Teams 4 Ideas Build Product Measure Data Learn • Communication links for a team on N are N x (N-1) / 2 • Beyond 7 people things start to suck! • The learning loop slows.
- 5. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Try Multiple Teams • If large teams won’t work we need multiple teams. • But how do we divide work between teams?
- 6. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | You asked for this. So we’re building this. • Each team builds a piece. • Then we assemble the car. 6 While you wait! Avoid Component Per Team
- 7. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Ideas Build Product Measure Data Learn Avoid Component Per Team • Each team’s piece is of no value to customers on its own. • Someone needs to break the product into components. • Someone needs to integrate the pieces before you have a product. • Someone needs to test the product. • This leads you (back) into waterfall. • The learning loop slows.
- 8. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Ideas Build Product Measure Data Learn Avoid Role Per Team • Each team has a single role – Product Management, Development, Test, Documentation, Operations, Support • Each team’s work is of no value to customers on its own. • Local optimization within teams. • Wasteful handoff between teams. • This leads you (back) into waterfall. • The learning loop slows.
- 9. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Try Product Per Team • Each team has their own product. • Each team has customers. • Each team rapidly cycles around the learning loop. • Each team is independent of others – Never depend on anything from another teams that isn’t already shipping in their product. – By doing so you implicitly become responsible for it! 9
- 10. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 1. Now you can go faster because we solved the speed problem. 2. Now with less effort because we solved the effort problem. 10 3. Now with your friends because we solved the space problem. Try Solving a Sequence of Small Problems
- 11. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Scaling Your Product 11
- 12. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Accept Entropy • Something, somewhere is always broken. • Any manual step will have been done incorrectly. • Mutable things will have been mutated in bad ways. • Bad things will happen. • Awesome people, trying really hard cannot overcome this! 12
- 13. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Avoid • Sequencing Tasks • Mutability • Fixing Things • Direct Communication • Manual Workarounds Try • Converging to a State • Immutability • Replacing Things • Service Mesh • High Velocity Automated Fix Forward 13 Architect for Entropy
- 14. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Avoid Running your own Platform • Deploying a platform is very difficult. • Running a platform is extremely difficult. • Finding people to do this for you is ridiculously difficult! • Try a managed Platform as a Service (PaaS) so you can focus on differentiating value. 14
- 15. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Scaling Your Culture 15
- 16. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Avoid • Mandating Tools • Mandating Process • Separate Product Owner • Fixed Intention • Command & Control Try • Team Chooses Tools • Team Chooses Process • Team Owns Product • Constant Attention • Autonomy 16 Scaling You Culture
- 17. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Avoid Pushing … Try Directing Pushing ➡ Piloting ➡ Navigating ➡ Training ➡ Directing 17
- 18. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. “ – Mel Conway 18 Accept Conway’s Law
- 19. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | “Awareness, Responsibility, Commitment .“ – John Whitmore 19 Try ARC
- 20. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Team • Avoid – Large Teams – Component Per Team - Role per Team • Try – Multiple Teams – Solve Sequence of Problems Product • Avoid – Sequencing Tasks, Mutability, Fixing Things, Direct Communication, Manual Workarounds, Running your own Platform • Try – Convergence to a State, Immutability, Replacing Things, Service Mesh, Fixing Forward Fast 20 Culture • Avoid – Mandating Tools, Mandating Process , Separate Product Owner, Fixed Intention, Command & Control, Pushing • Try – Team Chooses Tools, Team Chooses Process, Team Owns Product, Constant Attention, Autonomy - Directing, ARC Recap
- 21. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Thanks! • Follow: @martinahogg • Read: http://medium.com/@martinahogg • Join: https://www.meetup.com/Bristol-Cloud-Native 21
- 22. Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Note: The speaker notes for this slide include instructions for when to use Safe Harbor Statement slides. Tip! Remember to remove this text box. 22
Editor's Notes
- In a startup this loop is use to establish product/market fit and power growth. In a later stage company this loop is used to optimize ROI & TTR.
- This is a Safe Harbor Front slide, one of two Safe Harbor Statement slides included in this template. One of the Safe Harbor slides must be used if your presentation covers material affected by Oracle’s Revenue Recognition Policy To learn more about this policy, e-mail: Revrec-americasiebc_us@oracle.com For internal communication, Safe Harbor Statements are not required. However, there is an applicable disclaimer (Exhibit E) that should be used, found in the Oracle Revenue Recognition Policy for Future Product Communications. Copy and paste this link into a web browser, to find out more information. http://my.oracle.com/site/fin/gfo/GlobalProcesses/RevRec/Policies/cnt2321729.pdf For all external communications such as press release, roadmaps, PowerPoint presentations, Safe Harbor Statements are required. You can refer to the link mentioned above to find out additional information/disclaimers required depending on your audience.