1. DevOps The effects of DevOps on your IT service organization
Dave van Herpen
Sogeti Netherlands
@daveherpen /

2. DevOps?

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

4. Agenda
Drivers
What is:
Agile
Continuous Delivery
DevOps
DevOps & ITSM

5. 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

6. Time, cost & risks

7. 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

8. Silos

9. 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

10. Agile =
FDD
DSDM
Scrum XP
TDD
SAFe
Kanban

11. 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.

12. CD - DevOps Continuous Delivery:
Integration within the deployment pipeline
DevOps:
Collaboration between Dev, Ops, QA, business, & ...

13. Name = implementation approach
CD - DevOps
DevOps
Continuous Delivery
Basis = principles
Name = desired result
Basis = organization
Name = implementation approach

14. Continuous Delivery
BUILD
INTEGRATE
TEST
DEPLOY
PROVISION

15. 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

16. 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

17. 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

18. DevOps = ... Collaboration Dev + Ops (Lite) + QA + business + ...
Shippable code + environments
Fast flow planned work, small batch size
P = reliable, stable, resilient, secure

19. DevOps: relations DevOps Agile Lean ToC ALM Cloud ITIL Continuous
Build
Integration
Deployment
Delivery
Quality
Testing
...

20. 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

21. 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”

22. DevOps in an IT service context
Enterprise DevOps
DevOps in an IT service context

23. 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

24. 10 rules of Enterprise DevOps
DevOps engineers do not exist 10

25. 10 rules of Enterprise DevOps
Facilitate multidisciplinarity 9

26. 10 rules of Enterprise DevOps
Do not forget about the business 8

27. 10 rules of Enterprise DevOps
Delivering services include support 7

28. 10 rules of Enterprise DevOps
Balance your portfolio 6

29. 10 rules of Enterprise DevOps
Constantly remove bottlenecks 5

30. 10 rules of Enterprise DevOps
Not everything can be automated 4

31. 10 rules of Enterprise DevOps
Reward risk takers 3

32. 10 rules of Enterprise DevOps
Embrace the cloud 2

33. 10 rules of Enterprise DevOps
Do not neglect your core systems 1

34. Q&A. Twitter. @daveherpen LinkedIn. http://nl. linkedin
Q&A. Twitter @daveherpen LinkedIn Whitepaper