Agile, Continuous Delivery, devops. Friend or Foe???

Transcription

1 Agile, Continuous Delivery, devops. Friend or Foe??? Jason Gray e [email protected] t jas50ng

2 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 ITIL 2011 expert Agile - ICAgile Professional Certification devops Meetup event co-organiser Perth

3 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?

4 Is ITIL under attack?

5 Are agile, Continuous Delivery & devops friend or foe?

6 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

7 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

8 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

9 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

10 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

11 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

12 Waterfall s Legacy to the Enterprise: It was great for generating lots of this

13 and building these Walls between teams (Handoffs)

14 and for constructing these Great for this Silos of teams

15 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

16 but 2 of the biggest problems

17 Problem #1: Failure to deliver 14% Successful 57% Challenged Source: Standish Group 2011 (project data from )

18 with 29% EPIC FAIL

19 and Problem #2: SLOW delivery? concept Time until the business begins to see value? Project Lifecycle Plan Build Test Run months 4 months 8months 3 years?

20 AWESOME!!! Your happy customer is only 3 years away

21 The New World problem statement becomes How do I deliver customer valuefaster?

22 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

23 Start with the why? To deliver customer valuefaster Simon Sinek

24 Problem 1: Failure to deliver Waterfall vs Agile 14% vs 42% 3x more successful Source: Standish Group 2011 (project data from )

25 Problem 2: FASTER delivery Plan Waterfall (old world) Build Test Run concept months 3 months 6months agile, CD, devops (new world) 3 years vs weeks Plan Build Test Run concept Weeks, days Sprints/iterations ASAP

26 agile, cd, devops -What?

27 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

28 agile, cd, devops -How?

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 Offensive Strategy: How fast can you deliver your idea or innovation?

40 Defensive Strategy: How fastcan you close the gap on your competitors?

41 The game has changed Andrew Clay Shafer there is no talent shortage

42 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

43 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)

44 How does this impact your ITSM processes Exercise: Heatmap on ITIL/ITSM process

45 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

46 Examples

47 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

48 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

49 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

50 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

51 2. Release and Deployment cont Service Transition: Release & Deployment Management (ITIL Service Transition ) 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.

52 2. Release and Deployment cont Service Transition: Release & Deployment Management (ITIL Service Transition ) Support a rapidly changing business

53 2. Release and Deployment.cont ssshhhhhh!!!! Continuous Delivery and devops is Release and Deployment Management done well

54 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

55 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

56 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)

57 Treating servers (CIs) more like Cattle and less like Pets

58 4 Configuration Management cont. Issues cont.. Servers treated more like cattle and less like pets Naming standards control CSI Action: Ec 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

59 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?

60 In Summary Agile, CD and devops if done right should be improving your ITIL/ITSM capability and maturity?

61 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

62 friends or foes?

63 They are friendsto your business You need to becomes friends with them.

64 These debates ITIL vs agile ITIL vs CD ITIL vs devops

65 ITIL vs agile ITIL vs CD ITIL vs devops

66 The real debate becomes? How do we become friends? and how do we prepare for ITSM disruption?

67 4 tips to prepare for ITSM disruption

68 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

69 ITSM Perception Problems... Which ones do you have?

70 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

71 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

72 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

73 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

74 to prepare for disruption and the New World

75 Old World New World

76 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

77 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

78 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

79 (W. Edward Deming) It is not necessary to change, survival is not mandatory

80 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