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.

Building a DevOps Team that Isn't Evil

2,455 views

Published on

The world of IT is shifting rapidly towards DevOps with analysts predicting the majority of companies will adopt DevOps practices in the next few years. In fact, in a recent study on DevOps by International Data Corp. (IDC), they believe that DevOps will be adopted (in either practice or discipline) by 80% of Global 1000 organizations by 2019!

Forming a DevOps team seems like a natural step, but the idea of creating a dedicated DevOps team has ignited anger in the community. Why? What's the concern? Is a DevOps team evil? Completely necessary? A necessary Evil?

Join IBM UrbanCode's Eric Minick to learn the pitfalls of creating bad DevOps teams, and successful approaches of good ones. Along the way, we’ll explore other heresies such as using tools to change culture.

Published in: Software
  • Be the first to comment

Building a DevOps Team that Isn't Evil

  1. 1. © 2015 IBM Corporation Cloud Software Creating a DevOps Team That Isn’t Evil
  2. 2. © 2015 IBM Corporation1 Cloud Software • Eric is the Product Management Lead for Continuous Delivery with IBM where he helps shape the future of IBM’s CD products. • He works with customers and industry leaders to find the best ways of adopting continuous delivery and DevOps. • @EricMinick Eric Minick Who is that guy?
  3. 3. © 2015 IBM Corporation2 Cloud Software Evil?
  4. 4. © 2015 IBM Corporation3 Cloud Software Evil?
  5. 5. © 2015 IBM Corporation4 Cloud Software Evil?
  6. 6. © 2015 IBM Corporation5 Cloud Software Evil?
  7. 7. © 2015 IBM Corporation6 Cloud Software And yet… 6 Slide from Stephen Elliot at #DOES14: http://youtu.be/9_ZuEhgTdLc?t=12m16s https://ibm.biz/costofdowntime
  8. 8. © 2015 IBM Corporation7 Cloud Software Is the industry making a huge mistake?
  9. 9. © 2015 IBM Corporation8 Cloud Software The Plan What would make a DevOps team evil? Designing a healthy team Other good models Q&A
  10. 10. © 2015 IBM Corporation9 Cloud Software Silos 9 Dev OpsDevOps HT: Matthew Skelton http://slidesha.re/1vOiHc4
  11. 11. © 2015 IBM Corporation10 Cloud Software 10 Rebranding – Declaring Success without any Doesn’t sound helpful
  12. 12. © 2015 IBM Corporation11 Cloud Software 5 Signs your DevOps Team is Evil 1 • Other groups interact with you via tickets 2 • Your team own lots of things 3 • The manager is growing his fiefdom 4 • You share metrics “up” not “out” 5 • Define success in IT terms, not business terms
  13. 13. © 2015 IBM Corporation12 Cloud Software The Plan What would make a DevOps team evil? Designing a healthy team Other good models Q&A
  14. 14. © 2015 IBM Corporation13 Cloud Software Matthew Skelton’s DevOps Team Topologies
  15. 15. © 2015 IBM Corporation14 Cloud Software Matthew Skelton’s DevOps Team Topologies Enterprises… Do this
  16. 16. © 2015 IBM Corporation15 Cloud Software Building your DevOps Team
  17. 17. © 2015 IBM Corporation16 Cloud Software Guidelines for building your team People • Variety of Dev, Ops, other backgrounds • People that command respect (technical chops) Home • Neutral territory Mission • Work self out of job
  18. 18. © 2015 IBM Corporation17 Cloud Software Mini Case Study 1: Fortune 100 Tech Company “IT Developers are our first line clients” • Devs deliver software, how do we provide tools / services to help that? Focus on private cloud and full stack environment provisioning • 2008: 5% virtualized and 60 day environment provisioning time • 2014: 95% virtualized same day environment creation (minutes) The Target • Blend ALM with Operations • Simplify governance • Visibility, visibility, visibility
  19. 19. © 2015 IBM Corporation18 Cloud Software Mini Case Study 2: Fortune 100 Health Insurer Found a home in QA • Wasn’t trusted by Ops in Dev or vice versa Radically inclusive • Knock on doors rather than break down silos • Show info-sec / audit holes in the process and where DevOps makes it better “Tracer-bullet” – Release Automation • Spans dev and ops • High value • Relatively simple • Attach quality checks to pipeline later
  20. 20. © 2015 IBM Corporation19 Cloud Software The Plan What would make a DevOps team evil? Designing a healthy team Other good models Q&A
  21. 21. © 2015 IBM Corporation20 Cloud Software IBM – A global team of developers Perth Canada Toronto, Ottawa Montreal, Victoria Haifa Rehovot China Beijing Shanghai Xian Yamato Taiwan Paris Pornichet Kirkland Seattle Foster City San Francisco SVL/San Jose Almaden Agoura Hills Irvine El Segundo Costa Mesa Las Vegas Bedford, MA Bedford, NH Essex Junction, VT Westborough Cambridge Littleton Marlborough Cork Dublin Galway India Bangalore Pune Hyderabad Gurgaon Vizag Cairo Rome Gold Coast Sydney Canberra Fairfax Raleigh Charlotte Lexington, KY Atlanta Boca Raton Tampa Krakow Warsaw Sao Paulo Malaysia DelftStockholm Boeblingen Southbury New York City Princeton Hawthorne Endicott Moscow Zurich Pittsburg Poughkeepsie Somers Yorktown Heights Hopewell Junction Wayne Hursley Warwick York Edinburgh London / Staines Milton Keynes Phoenix Austin Dallas Dublin Rochester, MN Boulder Denver Lenexa, KA Tucson El Salto, MX
  22. 22. © 2015 IBM Corporation21 Cloud Software IBM’s DevOps Center of Competency Responsible to drive the transformation • CEO support • Lead by example • We work the way we ask teams to work, specifically - Using IBM Design Thinking to determine how to best help our teams transform – user out come focused - Report our transformation work in the context of our user – SWG teams - Using Lean & Agile practices to deliver
  23. 23. © 2015 IBM Corporation22 Cloud Software IBM’s DevOps Center of Competency Responsible to drive the transformation • CEO support • Lead by example • We work the way we ask teams to work, specifically - Using IBM Design Thinking to determine how to best help our teams transform – user out come focused - Report our transformation work in the context of our user – SWG teams - Using Lean & Agile practices to deliver Execute a simple experiment for a coded hypothesis (based on a Design Hill) in < 7 days SWG Team can find information on measuring a signal that will validate a hypothesis < 30 secs SWG Team can continuously collect & visualize correlated signal data in < 7 days Who What Wow
  24. 24. © 2015 IBM Corporation23 Cloud Software IBM CoC Approach • Facilitate communication & collaboration ‒ Establish a Community (internal forums) to share what works and get support ‒ Roadshows / Presentations for techies and execs ‒ Internal educational sessions (webinars for several thousand participants) ‒ Online tutorials • Build Support in the Org ‒ Recruit evangelists with grass roots and management respect ‒ Benchmarking and case studies across teams ‒ Recruit implementation managers on the individual teams • Map business controls to DevOps techniques ‒ Does an experiment imply a commitment to a feature? ‒ Can we experiment with something in English only, for a product available in 10 languages? ‒ How should marketing work with a steady stream of features instead of big releases?
  25. 25. © 2015 IBM Corporation24 Cloud Software IBM CoC Approach cont. • Invest in tooling ‒ Provide as a service 24
  26. 26. © 2015 IBM Corporation25 Cloud Software Success Story: Watson Analytics Continuous Delivery to SoftLayer in 15 minutes 25
  27. 27. © 2015 IBM Corporation26 Cloud Software Environments Manual Automated Gain Deploy Tests Deploy Tests Test 4 hours 80 hours 20 min 3 hrs 96% Staging 8 hours 4 hours 40 min 15 min 92.5% Production (25 environments) 200 hours 4 hours 3 hours 5 min 98.5% Gain 98% 96% 98.5% Success Story: Workload Automation aaS Rome, Italy 26 IBM SoftLayer Monitor and Optimize Rational Team Concert Rational Quality Manager Rational Performance Tester IBM Security AppScan SmartCloud Control Desk IBM Application Performance Management IBM Endpoint Manager IBM Security QRadar® IBM UrbanCode Deploy IBM Workload Automation • Production deploymentin few hours • Change management process • Automated tests • No “black out” during update
  28. 28. © 2015 IBM Corporation28 Cloud Software Standard Model for a Center of X DevOps Team 28 Dev OpsDevOps
  29. 29. © 2015 IBM Corporation29 Cloud Software Standard Model for a Center of X DevOps Team 29 Dev OpsDevOps
  30. 30. © 2015 IBM Corporation30 Cloud Software Standard Model for a Center of X DevOps Team 30 Dev OpsDevOps
  31. 31. © 2015 IBM Corporation31 Cloud Software In Summary DevOps as a silo is bad DevOps teams work in the right context Not a silo. A facilitator DevOps teams should put themselves out of work
  32. 32. © 2015 IBM Corporation Cloud Software Questions? @EricMinick https://developer.ibm.com/urbancode/

×