Agile, Continuous Delivery, devops. Friend or Foe??? Jason Gray e Jason.gray@bankwest.com.au t jas50ng
whoami 1989 Bch Comp Sci (this is what you did before youtubeand slideshare) 1990s Operations -sysadmin/network admin 2000s devopsedan online courseware system 10 countries and 6 languages 2002 Honours in The challenges of ITIL implementations 10+ yrs Operations experience Automated deployments of 400 workstations / 60 servers for breakfast 10+ yrs Service Management experience Now 2 yrs Capacity Management / 2 yrs Problem Management Head of Service Integrity @Bankwest ITIL 2011 expert Agile - ICAgile Professional Certification devops Meetup event co-organiser Perth
As your business demands more SPEED techniques are being adopted that are putting Service Management under pressure. How do you respond? Do you defend or adapt/evolve/transform? Is service availability under threat?
Is ITIL under attack?
Are agile, Continuous Delivery & devops friend or foe?
1. How did we get here? Approach What was wrong & what problems are we try to solve? 2. What is this magic? (agile, CD, devops) Why are these techniques being adopted and what do they promise? Why is your CIO/business interested? 3. What does this mean for ITSM What to expect from agile, CD, devops How will this impact your ITSM processes? Which ITSM Processes need to Adapt, Evolve or Transform? 4. Friends or Foe: tips to prepare for ITSM Disruption 5. Wrap up: Monday -> 90 days -> Next year
1. How did we get here? Approach What was wrong & what problems are we try to solve? 2. What is this magic? (agile, CD, devops) Why are these techniques being adopted and what do they promise? Why is your CIO/business interested? 3. What does this mean to ITSM What to expect from agile, CD, devops What is the impact on your ITSM processes? Which ITSM Processes need to Adapt, Evolve or Transform? 4. Friends or Foe: tips to prepare for SM Disruption 5. Wrap up: Monday -> 90 days -> Next year
1970 Dr Winston Royce Managing the development of large software systems although Royce believe in this concept, he described the above as risky and inviting failure http://www.cs.umd.edu/class/spring2003/cmsc838p/process/waterfall.pdf
What Royce was really recommending was this Recommending this To fix this to transform a riskydevelopment process into one that will provide the desired outcome
1976 Bell and Taper Referedto Royce s initial design as Waterfall and the Waterfall SDLC was born BDUF: Big Design Up Front Each phase 100% complete before performing the next
Waterfall was good for delivering a bunch of stuff we didn t really need and will never use 45% of features never used YAGNI you aren t going to need it YAGRI you aren t going to release it Standish Group 2002
Waterfall s Legacy to the Enterprise: It was great for generating lots of this
and building these Walls between teams (Handoffs) https://www.flickr.com/photos/79286287@n00/215951891
and for constructing these Great for this Silos of teams
Waterfall delivery also has some serious issues BDUF = Incorrect Assumptions Everything is known up front.myth Everything comes together in the end.myth Better solutions will not be discovered along the way stifles innovation Customers/Business/Markets do not change their mind...missed opportunity
but 2 of the biggest problems
Problem #1: Failure to deliver 14% Successful 57% Challenged Source: Standish Group 2011 (project data from 2002-2010)
with 29% EPIC FAIL
and Problem #2: SLOW delivery? concept Time until the business begins to see value? Project Lifecycle Plan Build Test Run 18-24 months 4 months 8months 3 years?
AWESOME!!! Your happy customer is only 3 years away
The New World problem statement becomes How do I deliver customer valuefaster?
1. How did we get here? Approach What was wrong & what problems are we try to solve? 2. What is this magic? (agile, CD, devops) Why are these techniques being adopted and what do they promise? Why is your CIO/business interested? 3. What does this mean for ITSM What to expect from agile, CD, devops What is the impact on your ITSM processes? Which ITSM Processes need to Adapt, Evolve or Transform? 4. Friends or Foe: tips to prepare for SM Disruption 5. Wrap up: Monday -> 90 days -> Next year
Start with the why? To deliver customer valuefaster Simon Sinek http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action
Problem 1: Failure to deliver Waterfall vs Agile 14% vs 42% 3x more successful Source: Standish Group 2011 (project data from 2002-2010)
Problem 2: FASTER delivery Plan Waterfall (old world) Build Test Run concept 18-24 months 3 months 6months agile, CD, devops (new world) 3 years vs weeks Plan Build Test Run concept Weeks, days Sprints/iterations ASAP
agile, cd, devops -What?
What are these new techniques? 1. Agile mid 90 s Iterative software delivery lifecycle evolutions from XP, RAD 2001 Agile Manifesto 8 values, 12 principals Always evolving eg. LEAN, ToC, technology/tools 2. Continuous Delivery 2006 Started with Continuous Integration to support the speed of Agile development Automation of builds and testing 2010 Continuous Delivery Jez Humble & David Farley 3. devops 2009 Early days called Agile systems administration Andrew Clay Shafer/Patrick Debois then started devopsdays #devops Don t think devops think *.ops 2009 Velocity -John Allspaw& Paul Hammond 10 deploys a day Culture, LEAN, Automation, Measurement, Sharing
agile, cd, devops -How?
Transformation from old world to new world Business Perspective 12 months release Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD Team Silos Walls of confusion/frustration/handoffs
Transformation from old world to new world Business Perspective 12 months release Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations CONSTRAINT ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD
Agile Business Perspective 4 months release cycle Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations agile ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD
Agile Business Perspective 4 months release cycle Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations agile CONSTRAINT ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD
Continuous Integration Business Perspective 3 month release cycle Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations agile Continuous Integration ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD
Continuous Integration Business Perspective 3 month release cycle Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations agile Continuous Integration ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD CONSTRAINT
Continuous Delivery Business Perspective 1 month release cycle Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations agile Continuous Delivery ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD
Continuous Delivery Business Perspective 1 month release cycle Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations agile Continuous Delivery ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD CONSTRAINT
Devops (*.ops) Business Perspective daily or weekly releases Project Lifecycle Plan Build Test Run ITIL Service Strategy Service Design Service Transition Service Operations agile Continuous Delivery devops ENVIRONMENT MANAGEMENT TEAMS BA DEV TEST TEST n PROD
Why is your CIO/Business Interested? Two Important Problems are Solved 1. Better customer value/outcomes - Increased customer satisfaction 2. Delivered sooner - Payback/value delivered earlier plus 3. Encourages Innovation for a competitive advantage and as a bonus (combined with process evolution and technology improvements eg LEAN, cloud) 4. Some pretty serious productivity and cost saving potential and this is why you should be interested
Offensive Strategy: How fast can you deliver your idea or innovation?
Defensive Strategy: How fastcan you close the gap on your competitors?
The game has changed Andrew Clay Shafer there is no talent shortage
1. How did we get here? Approach What was wrong & what problems are we try to solve? 2. What is this magic? (agile, CD, devops) Why are these techniques being adopted and what do they promise? Why is your CIO/business interested? 3. What does this mean for ITSM What to expect from agile, CD, devops How does this impact your ITSM processes? Which ITSM Processes need to Adapt, Evolve or Transform? 4. Friends or Foe: tips to prepare for ITSM Disruption 5. Wrap up: Monday -> 90 days -> Next year
Some examples of impacts on ITSM? Agile Iterations: Smaller but more frequent changes Discovery-test and learn: more pilots/poc/canary Launches/Dark Launching Minimum Viable Product -MVP Low doc -this does not mean no documentation(audit requirements still need to be satisfied) Continuous Delivery Automation of development pipeline (builds, tests, deploys) Version control and Revision control of everything Logging: what, when, where, why and who Fix forward instead of rollback or replace instead of fix transient Cis devops Spin up/tear down of complete environments Role/ Responsibility Confusion Possible audit/regulation considerations - Segregation of duties (compensating controls)
How does this impact your ITSM processes Exercise: Heatmap on ITIL/ITSM process
Which processes need to adapt, which processes need to evolve, and which processes need to transform? And by processes I mean people, process, technology and partners
Examples
Adapt, Evolve and Transform process examples Adapt Service Level Management (not going to cover) Evolve Problem Management (if we have time) Transform Release and Deployment Management Change Management (if we have time) Configuration Management
1. Problem Management - Evolve Issues: Releases fix forward rather than rollback Replacing servers rather than investigating (masking the root cause) Role confusion: who does root cause analysis? problem management or the devops team Card walls being used by agile teams to track defects CSI Actions: Process/Role clarification: Who does RCA Who does problem resolution Figure out how you are going to track defects/known errors Benefits: Should be improved logging and metrics for RCA activities
1. Problem Management cont Legacy systems Problem Management Categorisation Phase Diagnosis Phase (RCA) Solution Phase Resolution agile systems Problem Management Categorisation Phase Diagnosis Phase (RCA) Agile Team Solution Phase Resolution
2. Release and Deployment - Transform Issues: Spin up / Tear down of complete environments automated releases Automated builds after every code check-in Automated testing more frequent with quicker feedback Transient Cis asset lifecycle of hours or minutes Versioning and Revision control of everything CSI Actions: Connect cd/devops tools up to change: what, when, where, why and who Exploit automated documentation Benefits: Sit back and watch Release and Deployment mature
2. Release and Deployment cont Service Transition: Release & Deployment Management (ITIL Service Transition-2011 4.1.4.2) 4.4.4.4 Release and deployment models pg 121 Automate the delivery, distribution, installation, build and configuration audit procedures where appropriate to reduce costly manual steps automate the build, installation and release distribution processes to improve re-use, repeatability and efficiency Automation will help to ensure repeatability and consistency..if a manual mechanism is used, it is important to monitor and measure the impact of many repeated manual activities, as they are likely to be inefficient and error-prone. Automated configuration baseline procedures save time and reduce errors in capturing the status of configurations and releases during release build, test and release deployment.
2. Release and Deployment cont Service Transition: Release & Deployment Management (ITIL Service Transition-2011 4.1.4.2) Support a rapidly changing business
2. Release and Deployment.cont ssshhhhhh!!!! Continuous Delivery and devops is Release and Deployment Management done well
3 Change Management - Transform Issues: Need to get better at smaller more frequent changes/releases Make sure you aren t getting Gamed Hidden surprises: Feature toggles, feature flags (testing impact) Testing in Production Canary releases Dark launches Automation through new toolsets Automated release documentation through tools CSI Actions: Open up toolset to automation (APIs) Improve Standard change (preapproved) options for low risk activities Fast lanes / slow lanes not all changes are equal
Change Fast lanes + Slow lanes SLOW - anti-patterns Eg. COTS, Legacy system Low number of releases No automation No automated testing Fragile design high change failure rate High level of Tech debt FAST Eg strategic investment Frequently released systems Automated deployment Automated testing Anti-fragile design Low change failure rate Shorter release cycle
4 Configuration Management v2.0 - transform Issues: Transient servers/environments/cis/data How much manual configuration work are you currently doing and planning on doing What is really important to track / what adds value What is your definition of asset and what is your definition of lifecycle Continuous Delivery will version and revision control everything the whole stack from boots to application OS versions, OS Patch levels, OS configs, App versions, App Patch levels, App/Web configs Software defined datacentre (SDDC) Network/Security configs deployed with applications (version controlled) Would you trust your CMDB or the Continuous Delivery servers Who has the better information Does your current automation cut it (is daily discovery enough)
Treating servers (CIs) more like Cattle and less like Pets
4 Configuration Management cont. Issues cont.. Servers treated more like cattle and less like pets Naming standards control CSI Action: Ec2-54-79-45-25.ap.southwest Utilise CD servers for information Develop APIs to push CI information to CMDB on create and update through build Benefits: Real-time automation of CMDB (CIs and relationships) Meaningful and rich release detail
If an environment is provisioned, built, tested and decommissioned before configuration management can detect it. George Berkeley (1710) Philosopher Did the CIs really exist? Is there value in tracking transient CIs?
In Summary Agile, CD and devops if done right should be improving your ITIL/ITSM capability and maturity?
1. How did we get here? Approach What was wrong & what problems are we try to solve? 2. What is this magic? (agile, CD, devops) Why are we adopting these techniques and what do they promise? Why is your CIO/business interested? 3. What does this mean to ITSM What to expect from agile, CD, devops How does this impact your ITSM processes? Which ITSM Processes need to Adapt, Evolve or Transform? 4. Friends or Foe: tips to prepare for ITSM Disruption 5. Wrap up: Monday -> 90 days -> Next year
friends or foes?
They are friendsto your business You need to becomes friends with them.
These debates ITIL vs agile ITIL vs CD ITIL vs devops
ITIL vs agile ITIL vs CD ITIL vs devops
The real debate becomes? How do we become friends? and how do we prepare for ITSM disruption?
4 tips to prepare for ITSM disruption
1. Service Management Culture Start cultivating culture Agile/cd/devops require culture change so does ITSM Make sure your people understand how your business works End-to-end Value stream map how an idea makes it into production Common Goals/Objectives/KPIs stop Delivery at all costs mentality stop punishing operations for failures Ensure you are employing the right people in your teams People that value collaboration and outcomes. People that value outcomes, not people that love processes Do you have ITIL/ITSM perception problems you need to face them
ITSM Perception Problems... Which ones do you have?
2. TRUST Protect Do you believe ITSM enables this Serve Stagnate or this Serve and protect SLOW Low trust = Low performance Low transparency High levels of Approval Silo-ed Low levels of engagement FAST High trust = High performance Transparent High levels of trust Collaborative Engaged teams
2. TRUST - Understand the why/what/how Understand agile, continuous delivery and devops Read, watch, go and see Understand what they are doing and why Apply learnings to your processes Take an interest, get involved, collaborate, go to meetups, conferences Understand the end-to-end value chain, speak a common language it helps build trust
3. Get LEAN From mean to LEAN processes Apply LEAN Value stream mappings for all of your processes Focus on value and outcomes (not output) Start with a MVP (Min. Viable Product) for your processes Including Minimum Standards of Documentation Identify and remove constraints 2003: Lean Software Development Mary Poppendieck/Tom Poppendieck Identify the next constraint in your processes and reduce or remove it ToC Theory of constraints 1984: The Goal Eliyahu M. Goldratt and Jeff Cox
4. Be prepared for SPEED Prepare yourself for Ludicrous speed Be prepared more frequent changes Maybe a ridiculous amount of change Automate, automate, automate don t just automate a bad process Ensure your SM tool has a usable friendly API (RESTful) If not start thinking about developing one or getting one Its not just about federation (ETL, batching -slow), it is about real time connection and linking into richer toolsets Automate documentation
to prepare for disruption and the New World
Old World New World
Old World vs New World Old World Implement 5 ITIL Volumes Target Maturity 5 SLOW Low trust Done when code cut Output Silos, Walls FUD There s a book for that New World Fit for purpose Target Maturity enough - LEAN (MVP) FAST High Trust Done is shipped Outcomes Collaborative Discovery, Do it more frequently There is an app for that
1. How did we get here? Approach What was wrong & what problems are we try to solve? 2. What is this magic? (agile, CD, devops) Why are we adopting these techniques and what do they promise? Why is your CIO/business interested? 3. What does this mean to ITIL/SM What to expect from agile, CD, devops What is the impact on your ITIL/SM processes? Which ITIL/SM Processes need to Adapt, Evolve or Transform? 4. Friends or Foe: Preparing for SM Disruption 5. Wrap up: Monday -> 90 days -> Next year
Action Plan Monday Morning Become friends with agile, CD and devops teams Assess yourself - Heatmap Exercise - Are your ITIL processes Fit for purpose CSI: Adapt, Evolve & Transform your ITIL processes Next 90 Days Start cultivating culture: collaborating and breaking down the walls and the silos Start building TRUST Get LEAN Prepare your processes for max. SPEED Next Year Too slow.your agile now
(W. Edward Deming) It is not necessary to change, survival is not mandatory
Additional Resources The Goal (theory of constraints) Eliyahu M Goldratt The Phoenix Project Gene Kim, Kevin Behr, George Spafford Release it Michael T Ngard Management 3.0 Jurgen Apello Continuous Delivery Jez Humble & David Farley Implementing LEAN Software Development Mary and Tom Poppendieck Also follow: Andrew Clay Shafer, Jeff Patten, John Allspaw Conferences/meetups: Velocity conference, devopsdays.com, devops meetups