Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Jan de Vries - How to convince your boss that it is DevOps that he wants

684 views

Published on

- We all know that we could implement DevOps a lot faster if we only would have commitment from our boss. We all know that there is a shiny business case for almost every DevOps implementation
- And we all know that the whole company will reap the benefits regarding speed, agility and stability once we implemented DevOps. Actually, it provides good, fast and cheap at the same time. So, what are we waiting for? What is your boss waiting for? What is C-level waiting for?
- That’s something we will do research on in this workshop. We will also share our research on this from the recent past.
- The workshop starts with a presentation about 7 practices that a company should adopt to be able to apply DevOps.
- The technique that we use is called Appreciative Inquiry. To tackle a problem, it discovers the best practices that work, the reason they work and how these combined practices can be used to avoid the problem ahead and create a strategic change. The aim is to build – or even rebuild – organizations around what works, rather than trying to fix what doesn’t.
- So we want to know what your boss is afraid of and what you have already tried to convince him that he is better off with DevOps. You will leave the workshop with the combined Appreciative Inquiry insights of all the attendees

Published in: Software
  • Be the first to comment

Jan de Vries - How to convince your boss that it is DevOps that he wants

  1. 1. How to convince your boss that it is DevOps that she wants • 11.00 – 11.45 The great transformation 7 surprising experiences -> 7 best practices • 12.00 – 12.45 Appreciative Inquiry Build – or even rebuild – organizations around what works, rather than trying to fix what doesn’t. 2 parts 1 Happy to talk in front of an agile audience!
  2. 2. The great transformation 7 surprising experiences -> 7 best practices
  3. 3. Intro Jan de Vries 3 • Fan of Agile • DevOps evangelist • Business IT Consultant at insurance company a.s.r. • Convenor Enterprise DevOps group (uniting members of ASL BiSL Foundation, ITSMF and Agile Consortium) • Member Scaling Agile group at Agile Consortium • Trainer BiSL, ASL, ITIL, FSM, ISM • Blue Ocean Defined Demand expert • Chairman Clarity User Society
  4. 4. Huh? Part 1
  5. 5. c How iterative is your software process?
  6. 6. c How often do you release to your customer?
  7. 7. The result and the consequences Tijd Tester:discovers defectsthat a developerintroduced 3 months ago Developer:what did I build 3 months ago? Designer:whatdid I design 6 months ago User: what did I ask for long time ago?
  8. 8. Manual activities: • Preparation and tuning of scenarios • Acceptance tests • deployments • conversions Why not release more often? 600 Why not automate? No business case Because we don’t do it often enough So we keep the frequency low: • Saves time for Dev and Ops • Increases stability
  9. 9. Huh? Part 2
  10. 10. Project based organisation
  11. 11. Product based organisation
  12. 12. • A multidisciplinary team that is fully responsible for continuously developing and maintaining a service Business Servicechain Platform#1 Platform#2 Platform#3 Platform#n Infrastructure
  13. 13. DevOps, the team basics • Development AND Operations in 1 team per businessline (or part of it) • Development, Business Information Management (BiSL), Application Management (ASL) and IT Infrastructure Management (ITIL) in 1 team per businessline (or part of it) • You build it, you run it. Eat your own dogfood • DevOps finishes what Agile started, because every PSI goes to production. • Extra flavours: BusDevOps and Enterprise DevOps 14
  14. 14. DevOps teams in stead of projects Because of the direct relationship with the customer there is less need to start projects. A very large part of the requirements is being realised through changes. In stead of staffing projects Bring the work to the scrum team • No resource shuffling • Reliable velocity • Clear Cost of Ownership per business line
  15. 15. Headline from the future 2017 SCRUM finally breaks through Numberof newly launched projects decreased with 80 % in the last 2 years.
  16. 16. Blow up silo’s, to create DevOps teams 17
  17. 17. Strategic Alignment Model Enhanced
  18. 18. S T O B I T
  19. 19. S T O B I T DevOps
  20. 20. S T O B I T BusDevOps
  21. 21. S T O B I T Enterprise DevOps
  22. 22. S T O B I T CIO influence....
  23. 23. S T O B I T ... applied in the board
  24. 24. ? S T O B I T
  25. 25. Huh? Part 3
  26. 26. Integration of management track and technical track Based on a whitepaper of XebiaLabs ?
  27. 27. Huh? Part 4
  28. 28. What is more important? Mean Time Between Failure as long as possible? Mean Time To Repair as short as possible? 29
  29. 29. • Failure is not acceptable…. But it will happen! • MTTR is more important than MTBF (John Allspaw) • Time spent on facilitating an efficient and effective response to failure >= time spent at preventing that failure. • Focus on MTBF: only for space hardware and embedded medical devices • Focus on MTTR: everything else What is more important? MTTR or MTBF?
  30. 30. Huh? Part 5
  31. 31. No time for technical debt and improvements http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/ Source:Brian Teunissen,Inspearit
  32. 32. 4 input sources for the backlog Technical debt backlog Improvement backlog Tasks
  33. 33. With time for technical debt and process improvement http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/
  34. 34. Bite the bullet http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/
  35. 35. Huh? Part 6
  36. 36. Provisioning in the last decade • Software is eating the world -> Infrastructure as code • We can generate DTAP-environments on demand.Treatthem like that 3 weeks 100 milliseconden3 minuten
  37. 37. Huh? Part 7
  38. 38. Fully automated to production Who is againstthat? 39
  39. 39. So, I don’t dare to mention • The Chaos Monkey (resilience testing -> anti fragility) • Continuous Delivery as code (the pipeline sits in a file) • The dismissal of testing (-> scripting) 40
  40. 40. The great transformation What got us started with DevOps
  41. 41. Straight Through Processing % %
  42. 42. In the old days Nowadays
  43. 43. Formula 1 in IT -> DevOps 44 Source:Car and Driver, K.C. Colwell/ Bryan Christie Design
  44. 44. 45 Car and Driver, K.C. Colwell / Bryan Christie Design Anatomy of an F1 Pit Stop: 0:03 Is the Magic Number
  45. 45. Acceleration is not easy in the 21st century • The most important contribution of management in the 20th century was the fifty-fold increase in the productivity of the manual worker in manufacturing • The most important contribution management needs to make in the 21st century is similarly to increase the productivity of the knowledge work and knownledge workers. Peter Drucker, 2000
  46. 46. Acceleration is not easy in the 21st century Cuckoo effect “Any foreign innovation in a corporation will stimulate the corporate immune system to create antibodies that destroy it.” Peter Drucker
  47. 47. 8 key differences between DevOps en Traditional IT 48 Source:Mustafa Kapadia,IBM
  48. 48. DN D G S J O M I C R W W M R I C O D D G S N J R D O S D G C N M J W I R J C D G I M S N O W D O C S N I WRJ M D G D S W J R M I N C D G O D DevOps maturity 01-01-2014 DevOps Building Testing Deploying Provisioning Reporting J = ok J = in progress J = no change
  49. 49. DN D G S J O M I C R W W M R I C O D D G SN J R D O S D G C N M J W I R J C D G I M S N O W D O C S N I WRJ M D G D S W J R M I N C D G O D DevOps maturity 01-06-2014 DevOps Building Testing Deploying Provisioning Reporting J = ok J = in progress J = no change
  50. 50. DN D G S J O M I C R W W M R I C O D D G SN J R D O S D G C N M J W I R J C D G I M S N O W D CS N I WRJ M D G D S W J R M I N C D G O D DevOps maturity 01-10-2014 DevOps Building Testing Deploying Provisioning Reporting O C O C O C O C O C O C O V V V V V V J = ok J = in progress J = no change
  51. 51. Role of IT in an organization Support the business Addedvaluetothebusiness Impact on organization Improve the business Innovate the business
  52. 52. 53
  53. 53. 55
  54. 54. The great transformation How to convince your boss of DevOps?
  55. 55. Abstract • We all know that we could implementDevOps a lot faster if we only would have commitmentfrom our boss.We all know that there is a shiny businesscase for almostevery DevOpsimplementation • And we all know that the whole company will reap the benefits regarding speed,agility and stability once we implementedDevOps.Actually,it provides good,fast and cheap at the same time. So, what are we waiting for? What is yourboss waiting for? What is C-levelwaiting for? • That’s something we will do research on in this workshop.We will also share our research on this from the recentpast. The method we use is Appreciative Inquiry.To tackle a problem,it discoversthe best practices that work, the reason they work and how these combined practicescan be used to avoid the problem ahead and create a strategic change.The aim is to build – or even rebuild – organizationsaround whatworks, rather than trying to fix what doesn’t. • So we want to know what yourboss is afraid of and what you have already tried to convince him that he is better of with DevOps.You will leave the workshop with the combined AppreciativeInquiry insights of all the attendees. 57
  56. 56. But first: what is the core problem? Why is not every organization, not everybody in an organization working agile / doing DevOps?
  57. 57. Tackling this problem
  58. 58. c c
  59. 59. 4 D’s • DISCOVER: The identification of organizational processes that work well. • DREAM: The envisioning of processes that would work well in the future. • DESIGN: Planning and prioritizing processes that would work well. • DEPLOY: The implementation (execution) of the proposed design 61
  60. 60. DISCOVER: The identification of organizational processes that work well For the speaker: • Which ‘Peak experiences’ did you encounter in your work, in specific projects, specific incidents? • What do you value most in yourself, your work, your organization? • Which factors keep your organization alive? For the listeners: • Focus on the story • Avoid discussions 62 • What are the key elements that you hear in the peak experience
  61. 61. DREAM: The envisioning of processes that would work well in the future • Which themes can be derived from these stories? • How does the future, based on these themes look like? 63
  62. 62. DESIGN: Planning and prioritizing processes that would work well. • How can we turn this exceptional dream phase into our everyday experience? • This expectional dream once existed. It may again be reality • Which scenario’s can we follow to get there? • Which activities do we need to plan? 64
  63. 63. DEPLOY: The implementation (execution) of the proposed design • Activities to deploy the dream state in your organization 65

×