Overskriften siger det hele: Scrum er ikke en løsning på noget som helst, så vi skal lade være med at fremstille det sådan. Alle bliver skuffede, og nej-sigere får mulighed for kategorisk at afvise de agile værdier, fordi metoden ikke løser alt som lovet.
Scrum er i stedet den projektør vi bruger til at få øje på vores problemer, som vi så skal til at finde løsninger på. Scrum sætter fokus på problemerne, såsom vage visioner, dårligt samarbejde, aflevering af halvfærdige features, for mange ting i gang på en gang, nyudviklingsinteresser som kæmper med drift-interesser, nyudviklingstid versus supporttid, prioritering af den korte bane over den lange bane og så videre og så videre. Løsninger er typisk ikke simple, fordi vi som mennesker, som teams, vores domæne og vores teknologi ikke er simple – kompleksitet og nuancer fordrer komplekse løsninger. Første skridt på vejen kan være noget simpelt, men der skal sikkert mange simple skridt til (det er ligesom software-løsninger – tag de små skridt til vi til sidst har rykket os langt).
Hvis vi skal have alle nuancerne med, så kan Scrum også være en løsning, men kun hvis vores problemer er simple. Hvis et team af fem udviklere går til et problem uden at samarbejde men i stedet sætter sig ned og laver fem forskellige løsninger som ikke lærer af hinanden – så er Scrum en løsning, fordi selv naivt udført Scrum som regel indebærer et minimum af samarbejde og kommunikation (typisk Daily Stand-up meeting). Nuancer er ikke gode for længden af og den røde tråd i et blogindlæg, så jeg stopper her med at sætte “Scrum som løsning” på spidsen. Scrum består i det store hele af gode elementer som kan sætte fokus på problemerne og måske hjælper med at løse et par små-problemer ud af boksen.
Hvis folk garanterer at de har universelle løsninger på alle vores problemer, så sælger de “snake-oil”. Vi ved jo godt at salven ikke kurerer alle sygdomme i hele verden – det er umuligt.
Vi ved også godt at software-udvikling er svært. Vi har kigget omkring i branchen og set skandalerne og hørt hvisken i hjørnerne (og råben fra hustage) om spild og forsinkelser. Derfor tror vi heller ikke alvorligt på at man kan forstå en løsning på disse problemer på et to-dages kursus. Man kan åbne ballet og skrabe overfladen, men man bliver ikke ekspert eller “mester” på to dage.
Dette er ikke en kritik af Scrum fra min side. Jeg har ikke en forventning om at Scrum er en løsning, så jeg er ikke skuffet. Tværtimod er jeg imponeret over Scrums fortræffeligheder som diagnose-værktøj. Nogen kan sikkert se og artikulere problemerne uden den hjælp som Scrum er, men for os andre dødelige kan hverdagen godt forplumre udsigten.
Har Scrum svage sider – bestemt. Nok især på Product Owner-siden. Selv som diagnose-værktøj behøver Scrum ikke stå alene. Kan Scrum gøre skade – det tror jeg. Især hvis man har en konfliktsky organisation, som helst vil løbe fra problemerne – det er værre at se problemerne og ignorere dem end slet ikke at se dem. Det kan gøre ondt i øjnene/sjælen, når man får projektørlys på. Ignorance is bliss.
Scrum og de andre agile metoder bygger på sunde principper og gode værdier, men software-udvikling er ikke nemt – heller ikke selv om man bruger en god metode og har gode værdier.
På løsnings-siden kan ví tage meget inspiration fra hvad andre kloge, erfarne mennesker har gjort, men til tider er der ikke andet at gøre end at tage “inspect and adapt” til sig og prøve sig frem. Forhåbentlig får man først fjernet de store kampe-sten på vejen og ender med at diskutere løsninger på sand i skoen.
Scrum er et værktøj, en process skabelon om man vil. Det er et udgangspunkt til at skabe en agil process, men hvis man ikke laver et retrospekt, ikke over det seneste sprint, men processen som helhed, og tilpasser processen, så gør man det altså forkert – man er det modsatte af agil.
Det altoverskyggende problem med agile processer er for PO, at de ikke kan få en fast deadline og et fast scope. Selvfølgelig ved alle udviklere at det ikke er muligt, men Scrum variere scopet i sådan en grad at PO ikke kan garantere ret meget mere end et par sprints ude i fremtiden, og det er bare ikke altid godt nok. Løsningen findes et sted imellem, og fremkommer ved process retrospekt.
Hvis man kommer til et punkt hvor man bruger retrospekt til at fjerne sand i skoen, så er min påstand at udviklingsprocessen og samarbejdet med resten af organisationen er så godt som det kan blive 🙂
Den med sand i skoen var nok lidt en smart bemærkning fra min side :). Det er min erfaring at man i de fleste organisationer er nød til at acceptere at gå udenom en kampesten eller to og så gå videre til at fjerne lidt mindre sten.