DevOps The effects of DevOps on your IT service organization Dave van Herpen Sogeti Netherlands @daveherpen / dave.van.herpen@sogeti.nl
DevOps?
Dave van Herpen Established in 1974 Work at Sogeti NL Management Consultant & Service Line Manager Expertise: Agile ITSM, AM & DevOps Business Information Mgmt Sourcing & SIAM Cert: ITIL, ISO20000, Lean, Agile, Scrum, SAFe, ... I was conceived in 1974, my parents named me after Dave Berry, you know, the singer of You’ve Got This Strange Effect On Me... Don’t worry people, I’ll spare you the details. Since 2000, I have been working for Sogeti Netherlands, which actually we pronounce the French way, Sogeti. My professional career has mostly revolved around service management, both as a consultant and a practitioner. In the past 4-5 years, I have been engaged in numerous Lean & Agile projects within the ITSM and operations area, combining the worlds of projects and services. Or, what the hipsters like to call DevOps...Also, I have several certifications as Scrum Master, Product Owner and SAFe Program Consultant. To me this illustrates the convergence of the worlds of agility and continuity. And last but not least, I am certified in applied common sense, which in my view is just too rare these days... @Mark
Agenda Drivers What is: Agile Continuous Delivery DevOps DevOps & ITSM
Agile & DevOps business drivers Business driven Customer Satisfaction Optimal value & risk First, there’s the happy customer. Here we need to stop focusing on SLA’s and service reports with availability percentages of 99,5%, which the customer couldn’t care less about. Agreeing and measuring on customer satisfaction (like NPS) is a nice first step. In Agile principles the close collaboration with the business is essential to all Agile practices, where the business (by means of the Product Owner) is IN the team, not shouting from the other side of the river. Second, your business changes its portfolio, its priorities, its goals while you’re brushing your teeth. Short iterations of distinctive value are crucial here to support the changing organization, where constant feedback is also crucial to keep everyone on board and minimize the long term business risk. Third, IF your organization requires changes, through legislation, or competition, or new market opportunities, these changes are needed yesterday. Only an agile development team is not enough to reach a short time to market. If it halts at test, or production, or the business itself, there will never be a fast flow here. And the last business driver is about delivering quality in a reliable, repetitive and sustainable manner. Working in splendid isolation, whether you are at a Service Desk, or a developer, teams need to be compressed with all required disciplines to deliver quality at the required pace. This is a big challenge in large companies with considerable legacy environments. @daveherpen
Time, cost & risks
Agile & DevOps business drivers Business driven Customer Satisfaction Feedback loops Optimal value & risk Fast flow Short TTM First, there’s the happy customer. Here we need to stop focusing on SLA’s and service reports with availability percentages of 99,5%, which the customer couldn’t care less about. Agreeing and measuring on customer satisfaction (like NPS) is a nice first step. In Agile principles the close collaboration with the business is essential to all Agile practices, where the business (by means of the Product Owner) is IN the team, not shouting from the other side of the river. Second, your business changes its portfolio, its priorities, its goals while you’re brushing your teeth. Short iterations of distinctive value are crucial here to support the changing organization, where constant feedback is also crucial to keep everyone on board and minimize the long term business risk. Third, IF your organization requires changes, through legislation, or competition, or new market opportunities, these changes are needed yesterday. Only an agile development team is not enough to reach a short time to market. If it halts at test, or production, or the business itself, there will never be a fast flow here. And the last business driver is about delivering quality in a reliable, repetitive and sustainable manner. Working in splendid isolation, whether you are at a Service Desk, or a developer, teams need to be compressed with all required disciplines to deliver quality at the required pace. This is a big challenge in large companies with considerable legacy environments. Efficient operations @daveherpen
Silos
Agile & DevOps business drivers Business driven Customer Satisfaction Feedback loops Optimal value & risk Fast flow Short TTM Multidiscipl. teams First, there’s the happy customer. Here we need to stop focusing on SLA’s and service reports with availability percentages of 99,5%, which the customer couldn’t care less about. Agreeing and measuring on customer satisfaction (like NPS) is a nice first step. In Agile principles the close collaboration with the business is essential to all Agile practices, where the business (by means of the Product Owner) is IN the team, not shouting from the other side of the river. Second, your business changes its portfolio, its priorities, its goals while you’re brushing your teeth. Short iterations of distinctive value are crucial here to support the changing organization, where constant feedback is also crucial to keep everyone on board and minimize the long term business risk. Third, IF your organization requires changes, through legislation, or competition, or new market opportunities, these changes are needed yesterday. Only an agile development team is not enough to reach a short time to market. If it halts at test, or production, or the business itself, there will never be a fast flow here. And the last business driver is about delivering quality in a reliable, repetitive and sustainable manner. Working in splendid isolation, whether you are at a Service Desk, or a developer, teams need to be compressed with all required disciplines to deliver quality at the required pace. This is a big challenge in large companies with considerable legacy environments. Efficient operations @daveherpen
Agile = FDD DSDM Scrum XP TDD SAFe Kanban
Agile: Scrum As said, Scrum is the best documented Agile approach worldwide. This approach is based on only a few roles. The Product Owner is representing the business IN the team. Constantly involved, especially with regard to explaining business needs (in the form of use cases or user stories, all available in the Product Backlog) and ensuring the team is acting according to the actual business priorities. Based on the PBL, the team breaks down the total list into limited parcels, which we call sprints. Within the sprint the sprint backlog is picked up by the team, which deliver ready products every 2-4 weeks, using daily standups to ensure short and constant feedback loops. The Scrum Master is safeguarding the Scrum process and facilitating the team members in doing their jobs. The Team Members are the people engineering the product, which for Scrum is usually a particular piece of software, but can in fact be any product or service you’d like. So the main characteristics of Scrum are the tight interaction with the customer, the iterations and feedback loops to deal with constant change, and the short time to deliver ready products. Now especially this item is a growing pain as well. After all, Scrum ends at the Potentially Shippable Product, it does not deal with the actual release, transition to production, knowledge transfers to support, documentation, etc. Now, to prevent the actual waterfall to sustain at the end of the product development and still hamper the delivery, operations & support need to be involved continuously during the Scrum process. I will come back to that later.
CD - DevOps Continuous Delivery: Integration within the deployment pipeline DevOps: Collaboration between Dev, Ops, QA, business, & ...
Name = implementation approach CD - DevOps DevOps Continuous Delivery Basis = principles Name = desired result Basis = organization Name = implementation approach
Continuous Delivery BUILD INTEGRATE TEST DEPLOY PROVISION
DevOps origin "Lean Startup" is a largely theoretical methodology for developing businesses and products first proposed in 2011 by Eric Ries. Based on his previous experience working in several US startups, Ries claims that startups can shorten their product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and what he calls "validated learning". Though still largely unsubstantiated, Ries' overall claim is that if companies, especially startups, invest their time into iteratively building products or services to meet the needs of early customers, they can sidestep the need for large amounts of initial project funding and expensive product launches
DevOps = ... "Lean Startup" is a largely theoretical methodology for developing businesses and products first proposed in 2011 by Eric Ries. Based on his previous experience working in several US startups, Ries claims that startups can shorten their product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and what he calls "validated learning". Though still largely unsubstantiated, Ries' overall claim is that if companies, especially startups, invest their time into iteratively building products or services to meet the needs of early customers, they can sidestep the need for large amounts of initial project funding and expensive product launches
DevOps = ... "Lean Startup" is a largely theoretical methodology for developing businesses and products first proposed in 2011 by Eric Ries. Based on his previous experience working in several US startups, Ries claims that startups can shorten their product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and what he calls "validated learning". Though still largely unsubstantiated, Ries' overall claim is that if companies, especially startups, invest their time into iteratively building products or services to meet the needs of early customers, they can sidestep the need for large amounts of initial project funding and expensive product launches
DevOps = ... Collaboration Dev + Ops (Lite) + QA + business + ... Shippable code + environments Fast flow planned work, small batch size P = reliable, stable, resilient, secure
DevOps: relations DevOps Agile Lean ToC ALM Cloud ITIL Continuous Build Integration Deployment Delivery Quality Testing ...
CAMS Culture Automation Measurement (metrics) Sharing Change management Automation Release mgt, config & version control, integration, monitoring Measurement (metrics) Performance (#deploys) Process (#handovers) People (#people/deployment) Sharing Feedback Co-location
N.N. Taleb “Antifragile: Things That Gain From Disorder” Beyond Agile... Robust Antifragile Agile Fragile Flexible N.N. Taleb “Antifragile: Things That Gain From Disorder”
DevOps in an IT service context Enterprise DevOps DevOps in an IT service context
DevOps focus: Enterprise DevOps Overfocus on: Standaardization Automation New technologies Underfocus on: Business Information Management IT support Portfolio Management Complex & core systems Behavior & competences Enterprise DevOps
10 rules of Enterprise DevOps DevOps engineers do not exist 10
10 rules of Enterprise DevOps Facilitate multidisciplinarity 9
10 rules of Enterprise DevOps Do not forget about the business 8
10 rules of Enterprise DevOps Delivering services include support 7
10 rules of Enterprise DevOps Balance your portfolio 6
10 rules of Enterprise DevOps Constantly remove bottlenecks 5
10 rules of Enterprise DevOps Not everything can be automated 4
10 rules of Enterprise DevOps Reward risk takers 3
10 rules of Enterprise DevOps Embrace the cloud 2
10 rules of Enterprise DevOps Do not neglect your core systems 1
Q&A. Twitter. @daveherpen LinkedIn. http://nl. linkedin Q&A. Twitter @daveherpen LinkedIn http://nl.linkedin.com/in/davevanherpen E-mail dave.van.herpen@sogeti.nl Whitepaper http://bit.ly/1wuFuFc