Starting and Scaling DevOps

Editor's Notes

• #2: Introduction Always introduce this way because I truly believe this is the potential impact
• #6: This is going to require eliminating waste and improving efficiencies Types of work: New/Unique, repetitive, triage Getting everyone on the same page & where to start DP Agenda 12Min Basic DP 1 Dev Metrics for aligning starting point and progress Scaling to a Dev team DevOps appr. for small teams DevOps appr. large tightly coupled teams Close with impacts of changes
• #7: Build 1: (Software Delivery Cycle) Regardless of how your company approaches software development and delivery, it includes fundamental tasks from defining requirements, to coding to managing builds, to integration testing, to packaging distributions, deploying to testing or production, monitoring and re-iterating all over again. Whatever specific steps you take, these are the sequential tasks of software delivery. Typically each stage is deployed to defined development, staging and productions environments. The tasks we focus on throughout are referred to upstream, and sometime “left” in the delivery flow or downstream, or “right” based on where the typically occur in the process. Build 2: (Rapid Changes driven by Use Feedback) The biggest driver for a need for faster delivery is the ever-increasing demand from users and consumers (depending on our business type), who are placing demands on the business to innovate and compete to provide better experiences and services. Not only do these changes need to be implemented quickly, they have to be delivered with levels of quality that assure continuous user satisfaction. Methods to collect detailed feedback downstream must be continually fed back into upstream development Build 3: (Agile) Agile delivery and processes have become a standard incremental approach to building software faster, specifically targeting user needs . Whether you are in a highly regulated insurance or financial industry, or a fast moving start up, you have likely adopted some agile approach. But while agile is a predominant approach to software delivery, it comes with a fair set of challenges associated with many, fast moving tasks that must span teams and stages.   Build 4: (Continuous Integration)   10 years ago, Continuous Integration entered the scene when our CTO, Kohsuke Kawaguchi, created Jenkins to address the speed problem with automation. This allowed code that individuals and small teams were developing to be put into a framework to compresses repetitive and mundane tasks like commits, builds & unit tests. Without question, Jenkins is the defacto standard for continuous integration, with millions of users and projects across the world. Build 5: (Continuous Delivery) Today, Continuous Delivery is the next step to maturing the software delivery process, encompassing Continuous Integration to move the discrete tasks that were automated for developers and moving further down the delivery chain. Teams are able to confidently take the software coming out of development and have it ready deploy and run state for any stakeholder across the your organization. This doesn't always mean going as far as deployment into live production – that is decision based on your business needs - but you can confidently assure that the code is continuously delivered in a pipeline – ready for QA – whether internal or with third party partner – usability and acceptance testers - or to beta users release - and yes it may even deployed into live production. Build 6: (Continuous Deployment) Continuous delivery is NOT ALWAYS about delivering to live users, but if you do have continuous deployment needs - as many online retails and internet-only businesses like Google and Netflix do - then Continuous Delivery is THE necessary path to get to that objective. Build 6: (DevOps) When all this comes together, what it enables is a set a processes and technologies that allow you to realize DevOps – which makes continuous “everything” a reality for your business.
• #9: DevOps is associated with a number of tools technologies, and practices Most are important to apply or at least understand Frequently organizations get mired in the details Frequently teams lean wrongly on a specific dogmatic practice This results in losing site of the “best fit” goal Can inhibit progress and result in “overload”, or analysis paralysis
• #10: This results in losing site of the “best fit” goal Can inhibit progress and result in “overload”, or analysis paralysis
• #11: I have discovered, in practice that… If you simplify the problem space, you reduced noise, and accelerate progress
• #12: To this end, when approaching a DevOps transformation it is best to simplify… Consider the transformation a journey you plan to take. Befor you do ask 3 simple questions. Where are we? What is our current state, problems, stregnths, etc. Your starting point Where are we going? Your destinations What to you seek to achieve what is practical to achieve? How do we get there? What are the major steps (or roads) we will take to get there? In what order?
• #13: First we will establish the X-axis for the matrix composed of our Quadrants The X-Axis is: Focused on the SDLC Can represent a agile or non-agile team All development has some form of Define, Plan, Code, Build, Integrate, Release, Deploy (or install), and Operate But separated into to halves, Agile Upstream Practice of agile definition, planning and development methods such as Scrum, Kanban, Continuous Integration etc. Greater than 33% of organizations claim to have implemented Agile Upstream Processes Benefits include…faster feedback, less code defects, better management of work The other half is Agile Downstream Covers the integrate test, release, deploy part of the process Include practices such as automated testing, continuous delivery, and continuous deployment Only 13% of organizations practice this Next slides will look into why this is an issue
• #14: First we will establish the X-axis for the matrix composed of our Quadrants The X-Axis is: Focused on the SDLC Can represent a agile or non-agile team All development has some form of Define, Plan, Code, Build, Integrate, Release, Deploy (or install), and Operate But separated into to halves, Agile Upstream Practice of agile definition, planning and development methods such as Scrum, Kanban, Continuous Integration etc. Greater than 33% of organizations claim to have implemented Agile Upstream Processes Benefits include…faster feedback, less code defects, better management of work The other half is Agile Downstream Covers the integrate test, release, deploy part of the process Include practices such as automated testing, continuous delivery, and continuous deployment Only 13% of organizations practice this Next slides will look into why this is an issue
• #15: The Y-axis: Represents adoption of agile-upstream and downstream across the enterprise or at scale Broken down into team->work group adoption and workgroup to enterprise. Definition of a “workgroup” or even a team may differ by organization Only a subset of those that have implemented agile-upstream have scaled it. When considered with those that implemented downstream….. As studies show only a select few organizations of implemented enterprise devops, practiciing agile-upstream and downstream at scal
• #16: For organizations that connect upstream and downstream, and scale that to the enterprise: Can achieve DevOps and its benefits: Innovate faster Respond to market Gain competitive advantage Increased productivity Employee satisfaction and retention Often overlooked, but privately cited by many customers Leads to many of the other benefits For those interested in the bottom-line, all of these can lead to reduced-cost and/or increase revenue So why hasn’t everybody done this? [next slide]
• #17: Implementing DevOps requires connecting multiple stake holders, often across organizations other boundaries… On th planes of People or Culture Praces and practices Tools and technology However this present what we call the Chasms, seperations between upstream and downstream, and between teams and the enterprise. Examples are: [see slide](TBC)
• #18: These chasms, and the areas of each axis which they separate, which are supported by real data and experience, represent the Quadrants of maturity. Quadrant 1, Team-Level Agile Quadrant 2, Team-Level Continuous Delivery Quadrant 3, Enterprise Agile Upstream Quadrant 4, Enterprise DevOps I often consider this just DevOps. CD can be implemented and team-level, but DevOps requires organization wide implementation Each of the quadrants can be described, by a set of characteristics found in companies in each of the Quadrants. [next slide]
• #20: Implementing DevOps requires connecting multiple stake holders, often across organizations other boundaries… On th planes of People or Culture Praces and practices Tools and technology However this present what we call the Chasms, seperations between upstream and downstream, and between teams and the enterprise. Examples are: [see slide](TBC)
• #23: 1st order effect DevOps 100s vs 10s Lack of alignment
• #24: Right way first Marketing faster execution Dev Push into production Millennial Release Everything under version control Ops feature toggles working closely with Dev on scripts Exec stock price and bonus Aligned top to bottom, Everyone excited what could possible go wrong 10 Min
• #25: All the right parts BUT Doesn’t look or work like and elephant DevOps face plant
• #26: This is going to require eliminating waste and improving efficiencies Types of work: New/Unique, repetitive, triage Getting everyone on the same page & where to start DP Agenda 12Min Basic DP 1 Dev Metrics for aligning starting point and progress Scaling to a Dev team DevOps appr. for small teams DevOps appr. large tightly coupled teams Close with impacts of changes
• #27: Basic flow Simple process what could go wrong
• #28: What can go wrong at each step Business Idea Waterfall planning too much inventory Lean JIT (20 to 5%) Env (250 day story) Consistency SE, SD, automation, cloud Testing stage Cycle time repeatability branch time Approval times (approval time story) Prod deploy time and effort (launch calls story) Monitoring New issues (IE8 short story)
• #29: What can go wrong at each step Business Idea Waterfall planning too much inventory Lean JIT Env (250 day story) Consistency SE, SD, automation, cloud Testing stage Cycle time repeatability branch time Approval times (approval time story) Prod deploy time and effort (launch calls story) Monitoring New issues (IE8 short story)
• #30: What can go wrong at each step Business Idea Waterfall planning too much inventory Lean JIT Env (250 day story) Consistency SE, SD, automation, cloud Testing stage Cycle time repeatability branch time Approval times (approval time story) Prod deploy time and effort (launch calls story) Monitoring New issues (IE8 short story)
• #31: Where to start
• #32: All about change management and personal ownership Smaller for simplicity Stuff that matters Loosely coupled Tightly coupled
• #33: 40 Mins DevOps more important with more people Teams of 10 people diff from teams 100s Common view more important Start with biggest issues to create + momentum Design DP to help minimize triage waste Build Freq, BAT, SV
• #34: Break it down into stable subsystems Then build it up releasable
• #35: Need to start build up you subsystem deployment pipelines with gates and stage Stages localize feedback (triage) Gates for cultural changes and block instability
• #36: Define the system DP Complex system have more stages for localizing triage and gating instabilities Multiple stages have more opportunities for waste with repetitive tasks
• #37: Define the system DP Complex system have more stages for localizing triage and gating instabilities Multiple stages have more opportunities for waste with repetitive tasks
• #38: Minimizes rework with fast feedback and enables efficient triage Focus on long legs
• #39: Separate new work issues from repetitive Issues with repetitive tasks and cycle time for repetitive work will be used to prioritize automation Start with Env and Test before CI
• #40: Possible Results Complex Benefits are more pronounced 10s versus 100s Jez and David DP Engaged executives