Er Scrum og ITIL en del av problemet?

Noen ganger lurer jeg på om det har oppstått en form for religionskrig mellom miljøene innen for IT-Drift og de som arbeider med utvikling. Det utvikles industristandarder og ”good practice frameworks” på mange områder. Men ingen av rammeverkene har lykkes med å kommunisere godt med de som er utenfor sin primærmålgruppe. Det er et gap mellom utvikling og drift.

Dette tema var belyst på årets itSMF-konferanse som ble avholdt på Gardermoen 3-4 mars. ”Dei leikar ikkje saman – enno!” het presentasjonen til Bjørnar Tessem fra Universitetet i Bergen. Denne presentasjonen setter fokus på at det er samhandlingen mellom utvikling og drift som er mangelfull. Man er usikker på å la andre ”komme inn på sitt domene”, både fra utvikler- og driftsmiljøene. Hva skyldes denne usikkerheten? Er det frykt for å miste makt og innflytelse? Eller får man skylapper av sine egne ”good practice frameworks” enten de heter ITIL, CoBIT, Scrum, smidig eller noe annet? Dersom man får en for streng tolking av sitt eget rammeverk, så mister man den pragmatiske tilnærmingen.

Det er ingen tvil om at slike rammeverk bidrar til forbedring innen for sine respektive områder, men de kan også bidra til å stenge ute andre fornuftige innspill. Resultatet kan bli en religionskrig, der kundene og brukerne er de som må lide for den mangelfulle samhandlingen.

Utvikling og drift må i større grad ha følelsen av et felles ansvar for at tjenestene de utvikler og drifter vil tjene det formål de er tiltenkt på en måte som er effektivt for både brukerne og leverandørene.

Arbeider innen området IT Service Management og ITIL som senior rådgiver.
ITIL v2 Manager Certificate, ISO 20000 Consultant.
Har vært med å etablere itSMF Norge i 2003, og sitter som nestleder i styret. Har også sittet 2 år i det internasjonale styret for itSMF International.

7 kommentarer om “Er Scrum og ITIL en del av problemet?”

  1. Gi oss en smidig-veileder for ITIL-rammeverket!

    Det er et veldig sentralt og viktig tema Ole-Vidar trekker frem her. Med økt utbredelse av både ITIL-rammeverk og Scrum-praksiser får man ofte en kollisjon mellom svært ulike paradigmer: det ene taler først og fremst planmessighetens og stabilitetens sak, mens det andre ønsker størst mulig albuerom for kreativ og spontan utvikling. Disse kunne har levd godt og lykkelig side om side hvis man så på dem som nettopp henholdsvis ytre rammer og retningslinjer for hva man slipper ut i test- og produksjonsmiljøene fra et ITIL-perspektiv, og spilleregler for det praktiske systemutviklingsløpet fra Scrum-perspektivet. Men når man lar dem få bli til urokkelige dogmer og ideologier, og forsøker å presse paradigmet sitt over på alle andre, blir det trøbbel.

    De fleste kan forstå at det er ønskelig å beslutte handling først når man har dypdykket i en problemstilling og å kunne produksjonssette og tilby et produkt til en kunde så raskt som mulig, slik smidige metoder prediker. Men hva er hjelpen i det hvis ikke omverdenen klarer å henge med? Hva når kundene opplever oppgraderinger av programvaren vedkommende ikke rekker å utnytte fordi varselet om at det kom til å skje noe kom for brått på? Slike endringer er helt OK når det dreier seg om enkle webtjenester. Men når en leverandør endrer sine grensesnitt uten å gi samarbeidspartnerne tid til å justere på sine, kommer vel ikke tjenestene kundene fullt ut til gode før det har gått en del tid uansett?

    Men som Ole-Vidar peker på: det andre perspektivet blir like ille: når en leveranse eller oppgradering blir liggende i månedsvis i pipeline fordi det må igjennom et meget rigid og tidkrevende endringsregime, blir også kundene av tjenestene skadelidende.

    Nå har vi fått Smidig-veileder for PS2000-kontraktsstandarden, et stort og viktig skritt for å gjøre de merkantile sidene av smidigprosjektene mer solide. Hvem kan ta nå på seg å lage Smidig-veileder for ITIL-rammeverket? Eller er det noen som er i gang allerede?

  2. Meget bra og aktuelt tema som beslyses av Ole Vidar og Anne Kristine. Min erfaring med utvikling og driftsmiljøer er at de ofte befinner seg på «to ulike planeter», og da mener jeg bokstavlig. De har ulikt syn på hverandre som er preget av manglende forståelse av drivkrefter, de har ulike mål (ref hva Anne Kristine påpeker ift stabilitet vs endring) og de har ulikte språk og rammeverk. Hva kan gjøres for at disse miljøene kan nærme seg hverandre, jobbe tettere, mer avklart og med større grad av helhetsforståelse til beste for kunde og brukere? Jeg tror som Anne Kristine og Ole Vidar at vi ikke kommer langt med å banke rammeverk i hodene på hverandre. Her hjelper det ikke med Talibanisme. Jeg mener det i hovedsak er tre veier å gå. Det ene er fokus på tjenesten og kunde/bruker. Dette perspektivet kan bidra til at de to miljøene ser seg selv som en del av en verdikjede med felles mål. Den andre veien går på å tenke klare grensesnitt og leveranser til avtalt tid og med avtalt innhold. Rammeverkene må med andre ord leve side om side, men de må henge sammen. Det tredje og kanskje viktigste virkemidlet for bedre samhandling er større grad av kommunikasjon, møteplasser og dialog satt i system. Bjørnar Tessem fra Universitetet i Bergen hadde et godt og utprøvd virkemidel som jeg har sansen for, nemlig hospitering eller jobbrotasjon. Det å jobbe en periode i hverandres miljøer bidro til økt gjensidig forståelse og respekt. Gjensidig forståelse og respekt legger da grunnlaget for tettere og mer avklart samhandling hvor målrettet utvikling, overtakelse og god drift av tjenestene foregår til beste for kunde og brukere. Noen som har andre konkrete virkemidler som kan bidra til tettere samarbeid?

  3. Manglende samarbeidet mellom utvikling og drift er også et problem Smidig-miljøet klager over: http://forum.smidig.no/forums/6/topics/579

    Men her er kanskje også noe av stridens kjerne: Smidige metoder er opptatt av lav formalisme i kommunikasjonen og hyppige endringer. Dette oppfattes ofte til å være i strid med ITIL sine prinsipper.

    Er det faktiske forskjeller på hva erfaringen fra god utviklingspraksis og hva ITIL foreskrive?

  4. Der er ingen tvivl om, at Ole Vidar peger på en vigtig problemstilling som ikke kun handler om modsætningsforholdet mellem de frameworks, der forsøger at øge kvaliteten gennem øget planlægning, test, godkendelse og kontrol (Plan-Do-Check-Act frameworks) og de framewords, der forsøger at øge innovationsevnen gennem søge-lære processer, iteration og emergens (Discover-Choose-Act) frameworks.

    Det handler også om det gamle modsætningsforhold mellem udvikling og drift og de idealer, som over årene er opstået i begge lejre. Modsætningsforholdet stikker således dybere end ITIL versus SCRUM etc.

    Efter mine erfaringer kan modsætningsforholdet delvis elimineres ved at den enkelte organisation analyserer og beslutter, hvilken tilgang, der bedst passer til organisationen:

    – Modernistisk tilgang, der tror på, at det er muligt at forudsige og dermed planlægge fremtiden og rationelt designe, teste, implementere og evaluere løsninger og systemer. I et modernistisk perspektiv bliver frameworks som ITIL let idealmodeller, som organisationen mere eller mindre følger slavisk med nødvendigt bureaukrati til følge. Man glemmer let at ITIL skal tilegnes (adopt) og tilpasses (adapt).

    – Socialkonstruktivistisk tilgang, der tror, at det vigtigste er at have klare fælles opfattelser og praksisser i organisationen. Ændringer opfattes som subjektive sociale konstruktioner, der kun lykkes hvis man har en fælles opfattelse af f.eks. koncepter og terminologi. Derfor hører man ofte i denne type organisationer udsagnet, at «det vigtigste, vi har opnået med ITIL (eller andre frameworks) er en fælles begrebsforståelse». Da ændringer er subjektive, kan man ikke forudsige udfaldet af disse på lang sigt, hvorfor de socialkonstruktivistiske organisationer bekender sig til iterative, løbende forbedringer med udgangspunkt i eksisterende praksisser a la LEAN. Frameworks som ITIL bliver opfattet som inspiration for begrebsafklaring og løbende iterativ forbedring.

    – Postmodernistisk tilgang, der tror, at det reelt ikke er muligt at sige noget om fremtiden end sige styre den. Virksomheder er komplekse organismer, der ikke kan styres, men som højst kan påvirkes gennem narrativer, tematisering (italesættelse, iscenesættelse etc.), ko-konstruktion og med-konstruktion, communities of practice etc. Best practices som ITIL opfattes som historier eller myter, der kan italesættes og dermed føre til ændringer i organisationen, med et minimum af bureaukrati.

    Jeg kender til virksomheder, der har opnået gode resultater gennem alle tre tilgange – men absolut også virksomheder, som har haft fiasko med de samme tilgange.

    Jeg tror derfor, at det som organisation er vigtigt at erkende, hvilke grundlæggende antagelser organisationen hviler på, da tilgangen som oftest viser sig at være mere vigtig end selve det framework, man tager udgangspunkt i. Sagt på en anden måde: Jeg tror ikke, at ITIL eller SCRUM i sig selv fører til succes eller fiasko. Det kombinationen af organisationens kultur, de valgte best practices og den valgte tilgang, der afgør udfaldet.

  5. Takk for at du belyser et viktig problem, Ole-Vidar. Dette problemet er ikke bare kjent mellom utvikling og drift. Det er også kjent for oss som jobber med design av brukergrensesnitt. Gapet mellom design og utvikling er viden diskutert i våre kretser (og har inspirert tegneserier).

    «Dersom man får en for streng tolking av sitt eget rammeverk, så mister man den pragmatiske tilnærmingen.»

    Dette gjelder alle. Og jeg lurer på om problemet ikke er rammeverkene, men PERSONENE som gjør disse fortolkningene. Dette skyldes nok i stor grad også den økende graden av spesialisering vi ser i bransjen. Det er veldig lett for oss å grave oss ned i et fagfelt og dermed få skylapper. Den beste medisinen jeg kjenner mot dette er å jobbe i tverrfaglige team og stadig bli påminnet om HVORFOR og HVEM vi lager produktene for. Det er overraskende ofte vi peker på best practice og glemmer hvem vi lager systemet for. Er ikke det paradoksalt?

  6. Interessant tema Ole Vidar tar opp. Når Ram skriver at personene som gjør fortolkninger er et større problem enn rammeverkene, så tror jeg det er veldig riktig. Personer drives av behov for kontroll på den ene siden og behov for frihet på den andre siden. Dette ser vi på mikronivå i familielivet og på makronivå i internasjonale konflikter om hvordan samfunn organiseres. Det er kanskje lett å oppfatte smidig rammeverk og Scrum som et svar på frihet og ITIL som et svar på kontroll. Dette blir en missforståelse som kan missbrukes til å skape unødvendig polarisering. For å sikre både produksjonskvalitet og høy endringstakt så må man gjøre de riktige tingene på riktig måte. Prosesser og rammeverk bidrar til dette, men det er fortsatt de menneskene som gjør jobben som avgjør resultatet. For å sikre at utviklere fokuserer tilstrekkelig på produksjonskvalitet, så er hospitering hos brukermiljøer og hos driftsavdelinger veldig verdifullt. Det er også nyttig at det samme utviklingsteamet jobber både med utvikling av ny funksjonalitet og med forvaltning av den versjonen som er i produksjon. Hvis du ikke leverer produksjonskvalitet så er det veldig lite interessant at du jobber smidig og utvikler nye funksjoner raskt.

    Et annet aspekt er at forretningsmodellene gjerne er forskjellig mellom leveranse av en driftstjeneste og leveranse av en utviklingstjeneste. Det kan ofte virke som en driftsleverandør får best økonomisk resultat ved å gjøre minst mulig arbeid og at en utviklingsleverandør får best økonomisk resultat ved å gjøre mest mulig arbeid. Dette gjør noe med hvordan virksomhetene ledes og dermed noe med kultur og individuell adferd i respektive miljøer.

Legg inn en kommentar