DOES 15 - Jan-Joost Bouwman and Ingrid Algra - ITIL and DevOps Can Be Friends
•Download as PPTX, PDF•
0 likes•639 views
Jan-Joost Bouwman, Enterprise Process Owner Change Management, ING Ingrid Algra, IT Chapter lead, ING ING is a worldwide financial institution, based in the Netherlands. The IT department of the Netherlands manages a mix of off the shelf applications and in house built software. Traditionally development was governed by CMMi and IT Servicemanagement by ITIL processes. Three years ago the developers started working in Agile/Scrum teams, dropping CMMi. The next step was to involve Operations as well and transform to an DevOps organisation, striving for Continuous Delivery. In a lot of Agile organisation ITIL is considered the evil soul sucking epiphany of bureaucracy. But is it really? If we look at the tasks you perform in the ITIL processes Incident management, Problem management and Change management, you will find that a lot of those you still need to perform in an Agile/Scrum way of work. And that there actually is a lot of value in making some rules on how we want to interact in these processes between teams. But we may call the task differently than we were used to in ITIL. And we may choose to use different tools to handle parts of the process. We call this adaptation of ITIL Agile ITSM. This talk focuses on the adaptations we have made to our ITSM processes to accommodate the requirements of an Agile/Scrum way of work. Proving that there is still value in a lot of the things we used to do in ITIL And that there is no real conflict between Agile and ITIL.
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
Viewers also liked (18)
Similar to DOES 15 - Jan-Joost Bouwman and Ingrid Algra - ITIL and DevOps Can Be Friends
Similar to DOES 15 - Jan-Joost Bouwman and Ingrid Algra - ITIL and DevOps Can Be Friends (20)
More from Gene Kim
More from Gene Kim (20)
Recently uploaded
Recently uploaded (20)
DOES 15 - Jan-Joost Bouwman and Ingrid Algra - ITIL and DevOps Can Be Friends
- 1. ITIL and DevOps can be friends Jan-Joost Bouwman, Ingrid Algra Implementing Agile ITSM @ ING Netherlands DOES2015 San Francisco• 19 October 2015
- 2. Jan-Joost Bouwman • Process Owner Change Management • DevOps Community manager @ ING • Background in Operations and Processes • >15 years of experience in IT • Birdwatcher, travelling the world for birds • @JanJoostBouwman Ingrid Algra • IT Chapter Lead • Integration layer girl • >15 years of experience in IT • @ING since: 01-10-2000 • Aerobics, horseback riding • @ingridweij 2 Introducing us
- 3. Market leaders Benelux Growth markets Commercial Banking Challengers 3 Who is ING?
- 4. 4 At ING the role of IT has changed from service to strategy driver Clear and easy Today straight through processing enables ING to deliver a 5 min instantaneous offering Anytime & anywhere Today internet & mobile enable ING´s customers to do their banking 24x7 via Mobile or the internet Empower Today CRM and predictive banking solutions enable ING to focus on helping customers to understand their future prosperity Keep getting better Agile development methods have enabled ING to constantly deliver new value to our customers
- 5. Transition of the organisation 2011 2013 2015
- 6. 6 The great divide Risk Management: We still need ITIL to prove to our regulators we are in control! You have to use it! DevOps teams: We don’t want to do ITIL anymore! It is so much administration and we don’t see the added value. We only want to use a backlog.
- 7. 7 There may be a way to restore the peace! Eliminating duplicate administration, making the ITIL Processes as lean as possible. Introducing…
- 8. Solving incidents should not affect team predictability (Sprint goal) • Each Sprint has reserved capacity for operational tasks • Recommended 30% - but base it on historical data • Priority 1 and 2 incidents must be solved immediately • Lower priority within bandwidth • Outside bandwidth after approval of Product Owner 8 Incident management in ING Agile ITSM means utilising bandwidth
- 9. Strive for Today in – Today out (TiTo) Working with almost empty incident queues gives more satisfaction and a competitive mindset Each team has a dashboard showing open incidents in real time 9
- 10. Changes: • Workarounds in Knowledge systems • No more Known Error record Problem records still require minimal registration (status, short description): • Reassignment to other teams • Management reports & dashboards • Linking incident records for insight in reoccurrence Minimise build up of Technical Debt by aiming for This Sprint In Next Sprint Out (TSINSO) Problem Management tasks managed as User Story in the Product Backlog 10
- 11. 11 In Change management we take the biggest steps
- 12. We still need to manually change our CI’s. Possible improvements: • Discovered data • Automated generation of CI’s in the CD Pipeline CFG is more in the ‘new’ world! • Also includes building actual configurations of applications and the stack • And keeping those in version control 12 Configuration Management: more progress to be made
- 13. • Customer focus (reliability) • Feedback loop (mostly incident management) • Uniform process • Discipline What can Agile/Scrum learn from ITIL? 13
- 14. • Need for speed • Customer focus (adding value) • Limiting WiP • Feedback loop (what customers really want) 14 What can ITIL learn from Agile/Scrum?
- 15. • no real conflict. • ITIL still has adds value ta a DevOps way of work. • It does help to make the processes as lean as possible • ITIL and Agile/Scrum/DevOps can work together • This requires understanding and acceptance of each other’s expertise 15 Wrap up
- 16. Thank you @ingridweij @JanJoostBouwman visuals by Isabelle Hörl: www.isabellehorl.com | @IsabelleHorl we are hiring!
Editor's Notes
- Jan-Joost Ingrid Ingrid Jan-Joost
- Ingrid: ING is a global financial institution in over 40 countries ING Bank’s more than 52,000 employees offer retail and commercial banking services to customers. This talk focuses about what we do in the netherlands. We are the largest Retail bank in the Netherlands.
- Ingrid: The four pillars of our strategy are Clear and easy- providing clear information that is easy to understand in a fast way, with easy access. Making it possible to give the customer a fast offering on his loan application, that he actually understands. Anytime, anywhere – our clients should be able to use any device to access their information, at any time. Naturally IT plays a vital role here. Empowering people to make solid decisions about their financial future – with our customer data, predictive analytics and the information we have from other sources we can provide our clients with the information they need to make informed decisions. Keep getting better – Agile development with its short cycles and the feedback loop is a great way to improve our products and the way we make them constantly.
- Ingrid: In 2011 we started our transformation in the development process from CMMi to Agile/Scrum In 2013 we added Ops to form DevOps teams, because we found the handover to Ops to be an obstacle in realising the Agile promise. We started in one department with 150 teams; now all of ING Netherland is working in DevOps teams, which is about 500 teams NB. This still does not include the INFRA Ops teams! Only the applications Ops people. In 2015 the department DB (150 teams) started to implement the Spotify model of squads, chapters and tribes to integrate fully with business. We did a talk last week at Velocity about this, if you want to know more, look it up.
- Jan-Joost: Our DevOps transition came with a period of freedom for the teams to discover new tools and ways to organize their work. That had some side effects… Teams: We don’t want to do ITIL anymore, it is too much work Risk management: We have to do ITIL, because we need the evidence for regulators
- Jan-Joost: We want to eliminate duplicate work, make ITIL as lean as possible = Agile ITSM
- Jan-Joost Scrum teams need to reserve bandwidth time for operational activities like fire lanes for solving high priority incidents & fast tracks for fulfilling agreed service requests But also for technical debt and Problem analysis size should be based on historical data about time spent, but 30% of Sprint capacity is recommended Priority 1 or 2 incidents must still be solved immediately the current Sprint task is put down and assigned employee(s) start working on resolving the incident, even if Sprint goal is at risk or the bandwidth capacity already has been used Align with Product Owner if no bandwidth left for prio 3-5 incidents the current Sprint task is finished first, the incident is picked up after that if time left in the reserved bandwidth, or it is planned in the next Daily Scrum. If picking up a low priority Incident puts reaching the Sprint goal at risk, the Product Owner is contacted to prioritize and decide to reduce the Sprint goal or delay Incident resolution Ingrid: In practise the team has a very important say in whether or not incidents will get priority over Sprint tasks. They will make the Product Owner an offer he cannot refuse… A practical way to solve the bandwidth is to appoint an engineer of the day who is responsible for monitoring the incident queue and assigning tasks to his/her colleagues.
- Jan-Joost
- Jan-Joost: A lot of the tasks of the Problem management process can be handled as User Stories on a Product Backlog. This way you can plan them in the Sprints (and actually do them! Which is often an issue with Problem management: we register problems, but never get around to finding the root causes and solving them) The bandwidth we talked about in incident management helps a lot here as well. There were some additional changes for us. The biggest was that we decided to only put Work arounds in Knowledge systems where we could actually access them when we needed them. This is related to the Service management tool we use, which is not really suited to search for work arounds when you have an incident. We also decided to skip registering a Known Error Record completely. Minimal registration (status, short description) in Service management tooling still required: to be able to reassign (possible) problems to other teams Status information for Management reports & dashboards Linking incident records to problem records to have insight in the reoccurrence potential of incidents caused by the same problem Ingrid To minimise the risk of build up of Technical Debt the aim should be This Sprint In Next Sprint Out (TSINSO) i.e.: a Problem found in this Sprint should be on the Backlog of the next Sprint This has the same effect as TITO in incident management: working with a empty problem queue makes it easier for engineers to take their responsibility for solving things, makes it more fun to work on the occasional problem and creates competition between teams to outperform each other.
- RFC logging, analysis and managing the development process is done in the Backlog No need to do that as well in the Change process (as described in ITIL) Focus is on risks surrounding implementation instead This can be done by a much simpler Change process We reduced the no. of types of change from 5 to 3 (Normal, Emergency, Standard) Approval governance is now based on risk and impact, for which 14 questions have to be answered in each Change record Each Change needs a Definition of Done, covering the most important proof that a Change is Production ready (covering items for risk mitigating and sound operational management) In the future both the risk analysis and (a lot of) the DoD will be automated the Continuous Delivery Pipeline, reducing the administrative workload
- Ingrid If we don’t update our CI’s we can’t use CI information for analysis for incident, problems and changes. For exemple: if the relations between CI’s are not registered you cannot find all the teams affected by a change that need to give their approval. (we use a tool for that, because we have so many CI’s, teams and CABs) Example 2: for an incident is is difficult to determine which business services are affected and who has to be informed. It also means we are not fully in control of our IT budget. Configurations management means other things as well in development.
- Jan-Joost
- Ingrid
- Jan-Joost