Agile marries itil


Published on

This presentation has been held in several seminars about Agile and Itil.

Published in: Business
1 Comment
  • I think this is very interesting. It is when you put together the different standards for the different areas (Project Management and HelpDesk), whatever standards you use, that you actually will find the major benefits.
    We develop our products using Scrum and then use ITIL in our HelpDesk. To be able to support this we had to look a lot for softwares that actually could support us. The thing is that we thought it would be useless without having all information in the same system.
    So, we finally found VisionProject (a product created by the Swedish company Visionera) as a tool to support us in this.
    We are now developing the products using the Project Management Module. We are then testing and reporting/tracking bugs, using the Bug Tracking Module. After releasing one version, we get the feedback (feature requests and more bugs) from the customers using the HelpDesk module.
    To make this even better, we publish the documentation for the products using the knowledge base, also included in the system.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Vi är bland dem som har hållt på längst i Sverige med Agile.Ett tusen-tal personer utbildade i ITIL sedan starten 2004.
  • Problembilden:Vi ibland svårt att skilja på projekt och produkt.Itil kan inte projekt, Itil har valt bort projekt medvetet och kan inte användas för projekt. Kommer från England och där använder man Prince2Itil och utvecklingsavdelning har inte samma bild av hur produkten skall hanteras i drift. Ganska tydliga gränser.Exempel på där de pratar med varandra är ärendehanteringen, där man hanterar förändringar och fel.Men det kanske kärvar en del i förståelsen och det kan finnas revirtänk och rädsla för annorlunda arbetssätt.
  • Två världar som möts; utvecklingsavdelning och drift & förvaltning.Dessa har olika fokus och värderingar som beror på en rad saker; vilka krav som ställs, problem som kan uppstå och naturligtvis från den kultur och tradition man har med sig. Agile ITIL? For many, that sounds utterly oxymoronic—like "jumbo shrimp" or "unbiased opinion." Agile: Lean, automated, adaptive. ITIL: Lumbering, bureaucratic and rigid. These are mutually contradictory, nonsensically combined concepts. More oil and water than peanut butter and chocolate. Right? ITIL is about control, compliance and predictability. It's about uptime and stability. Agile? It's about speed and change—the mortal enemies of uptime and stability. So, what happens when Agile meets ITIL? Today, worlds collide. Part of the issue is rooted in the divergent cultures and motivations of dev and ops: • Dev: freewheeling, ideological, collaborative, self-organizing, and organic • Ops: policy-driven, command-and-control, focused on uptime and compliance When dev meets ops—when Agile meets ITIL—the velocity gains in application development are lost, caught in the purgatory of long, cumbersome release cycles. Worse still is change. For IT, change portends nothing but punctuated pain and a passel of unintended consequences. Change is empowering for dev and dispiriting for IT. According to Israel Gat, who, together with Michael Cote, blog as The Agile Executive: 1. The business needs to respond to change quicker than ever. 2. Various traditional IT management methods tend to discourage change and slow it down. 3. Competent Agile dev/test teams are now able to respond much quicker to the changes required by the business. The time gained in dev/test, however, could be completely wasted if IT Service Management fails to become (more) agile. And there's the key: When IT puts on the breaks, velocity gains—responsiveness, agility—are nothing but false hopes and empty promises. Agile becomes fragile.
  • För er som vi läsa mer finns denna sida med
  • ITIL kunskap om hantering av produkten i drift tillföra eftersom de flesta utvecklingsavdelningar inte fattar det och behöver lyssna lite på ITIL.Dessutom behöver driftavdelningen lyssna på utvecklingsavdelningen, vad krävs för att leverera affärsnytta kontinuerligt.Måste stödja varandra.!Drift behöver ställa upp på att leverera nytta hela tiden.Ta bort gränser, det här är ju ett team.Exempel på där de pratar med varandra är ärendehanteringen, där man hanterar förändringar och fel.
  • Vi antar att vi har en utvecklingsavdelning som funkar och levererar med affärsnytta med kvalitet. Har disciplin och autotester. Inte har en driftavdelning som kan ta emot frekventa leveranser.Ta med features som gör produkten lättare att underhålla.
  • Inte vattentäta skott mellan utvecklingsavdelningen.ITIL är till för verksamheten inte bara drift och förvaltning precis som Agile är till för verksamheten inte bara för utvecklingsavdelning.
  • Agile marries itil

    1. 1. We help you become more effective and efficient, including having more fun at work Operations and Development in the best of worlds How Agile can support ITIL ”To deliver what you’re told may be a good thing, but to deliver what is needed is better.”
    2. 2. mPeira • We help you become more effective and efficient, including having more fun at work • To do this we – focus on the practically usable • Through – training, consultancy, resourcing • Our delivery is really about: – a measureable effect (a goal fulfilled) • Our tools are – Practical knowledge of industry best practice 1
    3. 3. Terms and acronyms we work with … CMMI testing XP MoSCoW Agile Lean ITIL requirements management business benefit PMI PMP process business case KPI EA ROI efficiency release architecture ISO 20 000 UML modelling SOA workshop automisation GAP XML user stories IT management SCRUM application management and more … DSDM/Atern 2
    4. 4. Current deliverables • Book • Conference talks • The agile enterprise • Agile certification • Scrum, Lean and much more Agile • ITIL training • Consulting, coaching Follow us on twitter: Check our agile blog out at: Writing books and sharing our Scrum-agile experience: 3
    5. 5. A possible problem Bye, Bye! It’s not working! Development Product Operations Project 5
    6. 6. Orginsational focus 4
    7. 7. Agile from 10 000 meters 6
    8. 8. The need for agility Current status (??) Challenges - STANDISH 1994 • Projects do not deliver on time 1. Lack of User Input 12.8%  • Customers change their minds 2. Incomplete requirements 12.3%  • Increasing complexity 3. Changing Requirements 11.8%  • More and more projects are done for 4. Lack of Executive Support 7.5%  the first time 5. Technology Incompetence 7.0% • Cost overruns 6. Lack of Resources 6.4%  • Simple things seem to take too long 7. Unrealistic Expectations 5.9%  • ... but .... 8. Unclear Objectives 5.3%  • sometimes for some projects it seems 9. Unrealistic Time Frames 4.3%  to work very well 10. New Technology 3.7% Other 23.0% About communication & requirements Agile addresses > 70 % 7
    9. 9. Skill The financial problem … Our ability to change Agile Our understanding requirements of requirements Automisation & set-based design help us decide as late as possible Which line changes – and how - when we introduce agility? Time 8
    10. 10. Agile core values We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick 9
    11. 11. The power of prototyping, it’s nothing new • Deliver the highest value early on. • But do not neglect the bigger picture. • Design can emerge while still delivering value to your customer. 10 The idea of this slide comes from Tobias Mayer, certified scrum trainer at Agile thinking
    12. 12. Principle: Empowerment • The team is empowered to make decisions • The best architectures, requirements, and designs emerge from self-organizing teams • Agile best practices – The team NEVER waits for decisions – The customers & users involved have FULL authority to make decisions on behalf of the business (NOW) – The team informs the steering group which decisions have been made rather than asking for decisions (within a pre-defined scope) 11
    13. 13. Anti-thesis What we do not: • Write detailed specifications early • Produce detailed plans that cover a long time period • Perform product test & verification afterwards • Ask for permission • Produce and send documents to people and expect that to be communication • Sit in different cubicles in different buildings • Do stuff tomorrow or next week 12
    14. 14. References • - Values and principles • - Agile Alliance • - Atern • - XP • - Agile Project Management • - Crystal • - Scrum • - Lean Software Development • - Lean design • - Complex Adaptive • - Agile roll out • - Agile community • - Agile wiki • - Scrum home page 13
    15. 15. The meeting point Development Product Operations Project 14
    16. 16. How – two work streams Real processes Process Mgr Coach Measure Insert Capture learning Provide process updates Coach Process project Project Mgr 15
    17. 17. What ITIL can get from Agile done right • Testability in minutes – due to automatic builds. • Automatic regression tests, – due to automatic tests created already during development. • Installation in zero time – due to automatic installation. • Emergency patches without risk – due to automatic build + installation + test + installation • Reduced risks in change projects – due to agile principles, values and tools • Better service solutions – due to strong multi disciplinary involvement. • Much higher quality of service and process – due to the great continuous improvement focus 16
    18. 18. What you need to do • Development must do agile right, no cheating! – discipline – automation – real customer involvement • Operations must participate in development • Operations must be fast and allow frequent changes to operations • Operations must focus on automating and stop bureaucratic procedures • Status accounting need to include development • CM must be a core development skill • and … most important … • stop “the them and us” attitude … we are ONE team ! – Operations, development, business and whatever … 17
    19. 19. mPeira summary advice • Process change is a fuzzy business – All details cannot be defined up front - a step-wise Agile implementation process is necessary. • Process owner and process manager – Both roles are important - make sure they are both there. • Secure time and resources – The pay-off of a good process is great - but it does not come for free. • Use projects – Implement the process through a project using a project manager who uses an Agile model. 18
    20. 20. Almost the last page Questions ? 19
    21. 21. The last page Thank you and welcome back! 20