Bliv klogere på Scrum

Hver dag i it-verdenen er en buzzword-bingo-dag

I mine år i it-branchen har jeg mødt mange idéer, der var til salg. Vi elsker modeluner og kaster rundt med fagudtryk uden hensyntagen til, hvor de kommer fra, deres korrekte betydning eller konsekvenser.

Hver dag i it-verdenen er en buzzword-bingo-dag. Af og til – men kun meget lejlighedsvis – stopper jeg op og tænker: “Er det en god idé?” Foranlediget af nogle stærkt følte synspunkter og sammenstillingen af vandfaldsmetoden og Scrum er “vand-Scrum-fald” et af disse øjeblikke. I dette indlæg vil jeg dele mine tanker og forskning om sagen og dække spørgsmål som “hvad er ”vand-Scrum-fald””, “hvorfor findes det?” og “kunne vi blive ramt af det?”

For det første, hvad er “vand-Scrum-fald”? …

Vandfald

Vandfald opstod fra almindelig praksis i it-branchens tidlige dage og er en sekventiel livscyklus, der afspejler en lukket leveringsmetode fra krav, design, opbygning, integration og test til kundeaccept. Som følge af almindelig praksis er det noget vanskeligere at identificere en endelig definition. Winston Royce er bredt krediteret for sin definition i 1970, selvom han ikke opfandt den, og som han brugte til at fremhæve dens mangler. Det er mere eller mindre en opgivende tilgang med ringe “offentlig” støtte; vandfald har ingen officiel definition eller uddannelsesprogram.

Scrum

Scrum er et agilt framework til styring af teams udgivet og defineret af Ken Schwaber og Jeff Sutherland. Den er baseret på observationer fra Takeuchi og Nonaka i efterkrigstidens fremstillingsfremskridt i Japan. Schwaber og Sutherland udvikler stadig metoden med en klart skrevet definition og uddannelsesprogrammer. Brugen af Scrum er vidt udbredt inden for it-branchen og andre steder.

“Vand-Scrum-fald”

”Vand-Scrum-fald” er bredt krediteret som defineret i 2011 af Dave West fra Forrester Research i en artikel, der fremhæver den virkelighed, mange organisationer befinder sig i med deres rejse mod at blive agile. I en uhyggelig gentagelse af vandfaldets historie definerer Dave West ”vand-Scrum-fald” i et forsøg på at advare andre om dets anvendelse – kun for at få æren for at opfinde tilgangen.

I sin artikel definerer han vagt tilgangen som værende en fusion af “vand” med hensyn til kravene, “opbygning”, der udføres ved hjælp af Scrum, og “fald” er den sjældne frigivelse af software i slutningen af processen. Dave West beskriver ”vand-Scrum-fald”, så han kan advare:

“Det er bydende nødvendigt, at applikationsudviklings- og leveringsprofessionelle skubber tilbage på ”vand-Scrum-siden” af modellen. At bruge for meget tid på forhånd vil ikke øge kvaliteten af udgivelsen; tværtimod er det spildt.”. Om “efterårsdelen” af modellen advarer Dave West: “Applikationsudviklingsprofessionelle bør udfordre status quo for sjældne udgivelser og skubbe på for bedre at integrere frigivelsesprocesser i udviklingsteamet.”

Jeg vil opsummere hans argumenter som “det er ikke agilt”, og det stemmer ikke godt overens med en “DevOps” -tilgang – to ret grundlæggende drivkræfter for de fleste organisationer i dag.

Ved at undersøge dette indlæg er jeg stødt på en række forskellige definitioner af ”vand-Scrum-fald” med forskellige mængder “vandfalds-formalitet”:

Andre definitioner er mere som denne.

Uanset hvordan du ser på det, ligner det stort set vandfald i forklædning. De har alle de samme problemer, som Humphreys lov: “Brugere ved ikke, hvad de vil have, før de ser fungerende software”, Wegners præmis: “Det er umuligt fuldt ud at specificere eller teste et interaktivt system designet til at reagere på eksterne input”, og Zivs lov: “Softwareudvikling er en iboende usikker proces, og derfor kan det være svært (umuligt?) at definere en specifikation fuldt ud på forhånd”, for blot at nævne nogle få.

Du er også prisgivet Kahnemans/Tverskys planlægningsfejl, du undervurderer, hvor lang tid projekter vil tage, og du overvurderer, hvor hurtigt du kan ændre tingene, og Hofstadters lov: “Det tager altid længere tid, end du forventer, selv når du tager hensyn til Hofstadters lov”.

Hvorfor findes det?

Fra hvad jeg har oplevet, så er hovedårsagen til at anvende en ”vand-Scrum-fald-tilgang” det kontraktlige aspekt af at skulle rette leveringsresultatet. Dette kan skyldes en række årsager, herunder en ældre tilgang til indkøb af it-systemer, begrænset tilgængelighed af brugerfællesskaberne, en produktbaseret levering eller et komplekst systemintegrationsjob og/eller manglende viden om moderne leveringsteknikker.

Kunne vi blive ramt af det?

Det er baseret på et dårligt fundament, nemlig vandfald

Vi er nu to årtier inde i det enogtyvende århundrede, og argumenterne omkring vandfaldets mangler er blevet gravet frem de sidste 50 år. Gennem anvendelse af logik, sund fornuft eller fratrædelse støder jeg på færre og færre mennesker inden for branchen, der nu vil gå ind for en sådan tilgang. Heldigvis synes kollektiv visdom at have sejret, og traditionelle ledelsestilgange i it og bredere industri ser ud til at være i kraftig tilbagegang.

Meyer siger: “Vandfald… fungerer som et skoleeksempel på, hvordan man IKKE organiserer et softwareprojekt”. I takt med at vandfald og traditionel ledelse fortrænges, så gør Agile og Lean indhug i det bredere erhvervsliv, for eksempel Management 3.0, Holocracy.

Jeg er glad for, at Royces og den bredere it-industris kritik af den klassiske vandfaldslivscyklus som værende “risikabel og inviterer til fiasko” med rette har ramt støtte til vandfald. Fremme af sen feedback er en uundgåelig konsekvens af livscyklusmodellen, og selv dem, der kan være mere forsigtige med Agile, vil sandsynligvis stadig være motiverede for gentagen og trinvis levering – en tilgang Royce foreslog. Med udviklingen til SaaS og DevOps bør vandfald og andre sekventielle tilgange betragtes som “ældre” tilgange fra en svunden tid, der ikke passer godt til nutidens behov og udfordringer.

Nøglefortalere i 80’erne for vandfaldsmetoden var Yourdon og DeMarco, hvor sidstnævnte skrev skelsættende bøger som “Struktureret analyse og systemspecifikation” og “Styring af softwareprojekter: Ledelse, måling og estimering.” I 2009 reflekterede Tom DeMarco over de råd, der blev givet i 80’erne, og bemærkede, at han nu er:

“… fortaler for en ledelsestilgang, … det kan meget vel styre teamet mod agile metoder, i det mindste mod de inkrementelle aspekter af den agile skole”.

Og senere …

“Softwareudvikling er og vil altid være noget eksperimenterende. Den egentlige softwarekonstruktion er ikke nødvendigvis eksperimentel, men dens opfattelse er. Og det er her, vores fokus bør være. Det er der, vores fokus altid burde have været”.

Spot på DeMarco!!

I betragtning af at branchens konsensus er, at vandfald ikke er den bedste idé, den nogensinde er kommet op med, hvad får folk til at tro, at ”vand-Scrum-fald” er bedre?

”Vand-Scrum-fald” er simpelthen ikke defineret!

Efter min erfaring er det at være “vag” en fantastisk måde at undgå kritik, men du savner også muligheden for konstruktiv vurdering. ”Vand-Scrum-falds” vaghed er uden tvivl det bedste forsvar. Inspektion og tilpasning er kernen i forbedring og er bestemt i centrum for agile metoder.

Det kan ikke siges om ”vand-Scrum-fald”, som tilsyneladende ikke har nogen endelig og formel definition – derfor er den vanskeligt at kritisere effektivt. I betragtning af det investeringsniveau, der kræves for at “udfylde de tomme felter” omkring ”vand-Scrum-falds” definition, hvorfor skulle nogen gå til det problem i stedet for at vælge et bedre defineret alternativ?

Scrum Express forbyder at blive anvendt på en begrænset måde

På trods af en klar definition af tilgangen er det ikke svært at se, hvordan vandfaldsfusionen med Scrum kan bringe visse aspekter af Scrums frameworks i fare. Med opmærksomhed på sådanne omdømmemæssige farer er det ikke overraskende, at Scrum Guide udtrykkeligt forbyder tilpasninger, der bryder dens kerneretningslinjer:

“Scrum er gratis og tilbydes i denne guide. Scrums roller, begivenheder, artefakter og regler er uforanderlige, og selvom det kun er muligt at implementere dele af Scrum, er resultatet ikke Scrum.”

Der er en betydelig risiko for, at ”vand-Scrum-fald” underminerer rettighedshavernes forrang, bemyndigelsen fra udbyderne og tilgangen til at levere forretningsværdi i brugbare trin. Brugen af Scrum i bestemte, afgrænsede miljøer er blevet diskuteret som problematisk siden Scrums tidlige dage, som Ken Schwaber bemærker det i 2003.

“… tilføjelse af en vandfaldsfase til forsiden af Scrum …. var forfærdeligt, og hvilken mulig fordel kunne Scrum give, efter at det var blevet så ødelagt!”.

Schwaber fortsætter med at gå ind for at sælge den konkurrencemæssige fordel ved Scrum i stedet for at arbejde på en sådan ”vandfaldsmåde”; hans oplevelse af “vand-Scrum” overlader ikke meget til fantasien.

Et nøgleaspekt for Scrum er team-selvstændiggørelse til at levere forretningsværdi. Vandfaldselementet i ”vand-Scrum-faldet” binder i sidste ende teamet og begrænser mulighederne for at levere ægte forretningsværdi. Stillet over for foruddefinerede og tidsafgrænsede begrænsninger, en andens design og i sidste ende ikke at bære det fulde ansvar for at levere det færdige produkt, er det usandsynligt, at noget team ville føle sig fuldt engageret, modigt eller respekteret. Det er bestemt ikke helt den “konkurrencefordel”, som Schwaber/Sutherland gik ind for.

Der mangler empirisme
Empirismen er stor, og Scrum er eksplicit om sin troskab til empirisk proceskontrol, en tilgang baseret på kemiteknik – dette er helt klart et positivt skridt fremad for dem, der ønsker at se en mere disciplineret og kontrolleret tilgang til softwarelevering. Scrum handler om at levere forretningsværdi hurtigere, mere pålideligt med de empiriske principper om gennemsigtighed, inspektionsevne og tilpasningsevne, der fremmer en mere gennemtænkt og gentagen tilgang.

I modsætning hertil er det svært at se, hvordan man effektivt kan integrere gennemsigtighed, inspektionsevne og tilpasningsevne i ”vand-Scrum-fald” uden at gå på kompromis med den forenklede, sekventielle livscyklus. Mens ”vand-Scrum-fald” i det mindste tilføjer en vis empirisme til byggefasen (ved at kapre Scrum), er det fra et kohærenssynspunkt stadig langt bag tilgange som den 25 år gamle Unified Process.

Illusion af kontrol, rollebeskyttelse og uvidenhed

Det er min erfaring, at de typer projekter, der ofte anvendes til ”vand-Scrum-fald”, typisk indebærer en betydelig grad af tids- og/eller omkostningsrelateret kommerciel risiko for leverandøren. Disse risici kan antage mange former – omfangskrybning, komplekse afhængigheder og omkostninger. Reaktionen er at øge styringen og tilsynet med disse projekter. Dette er et meget naturligt svar, men det rejser spørgsmålet: “Hvorfor stoppe ved ”vand-Scrum-fald”?” Hvis du virkelig tror på vandfaldets livscyklus – hvorfor ikke anvende en fuldfed vandfaldstilgang, så du kan få illusionen om absolut kontrol?

”Vand-Scrum-fald” giver ikke kun denne følelse af at være i kontrol – i det mindste illusionen om det – men det giver opgaver til fordrevne vandfaldsforvaltere. Sidstnævnte punkt er noget Craig Larmans lov (del 2) advarer os om:

“Ethvert ændringsinitiativ vil blive reduceret til at omdefinere eller overbelaste den nye terminologi til at betyde stort set det samme som status quo”

Så er der almindelig gammel uvidenhed. Ledere kender vandfald / klassiske projektledelsesteknikker, og de kender måske endda Scrum (Scrum Certification-kurset), men de har ikke it-erfaringen til at arbejde uden for disse to polære, modsatrettede tilgange.

Derfor kan de efterligne – men de kan ikke innovere. Scrum er ikke den eneste trinvise og gentagne udviklingstilgang, og hvis “byggefasen” er egnet til en gentagen måde at arbejde på, skal “vand” og “fald” delene også være det?

Det er min erfaring, at mange projektledere ser Scrum Masters som et springbræt for dem, der ønsker at blive junior PM’er. Dette i sig selv demonstrerer en grad af uvidenhed om de grundlæggende forskelle mellem Scrum og vandfald.

Det tackler ikke risiko

Softwareudvikling opererer i et rum domineret af Conklins “Wicked problems”. Med de ondskabsfulde og uregerlige problemer fungerer traditionelle forudplanlagte leveringsmetoder ikke godt – for eksempel påpeger Rittel og Webber, at udgangspunktet er en opskrift på katastrofe – risiko er uundgåelig.

Hvis risiko er en vigtig drivkraft for anvendelsen af ”vand-Scrum-fald”, vil det være fornuftigt, at det centrale i ”vand-Scrum-fald-tilgangen” er risikoreduktion – risiko bliver den primære erklæring om forretningsværdi i mangel af anden forretningsværdiprioritering. I den forbindelse bliver mekanismerne bag prioritering af efterslæbet tydelige, nemlig prioritering af arbejde efter risiko. Men da ”vand-Scrum-fald” ikke er defineret, er dette enormt vigtige hensyn ikke dækket. Mens jeg er glad for, at andre metoder tackler risiko som en central bekymring, forbliver ”vand-Scrum-fald” uvidende om det.

Der er meget bedre alternativer!

Siden Royces artikel fra 1970’erne har it-landskabet været fyldt med mange bedre definerede leveringsmetoder, og de fleste med meget bredere branchestøtte. Skalerede agile tilgange som LeSS, Nexus og SAFe har alle klare strategier for at levere komplekse og risikable projekter, herunder dem med betydelige afhængigheder og risici. De tidlige trinvise og gentagne tilgange i Unified Process og DSDM har ligeledes bedre leveringsmodeller til at håndtere risiko tidligt i komplekse projekter. Derfor er der mange bedre alternativer at bruge uden at skulle smide 50 års it-procesforbedring væk ved at genindføre vandfald ad bagdøren.

Konklusion – hvor efterlader det os?

Hvis Alex Issigonis, investoren i Mini, i 1959 havde beskrevet sin bil som “lyd – men med nogle store fejl, så brug den kun til et par ture”, ville Mini stadig være et succesrigt mærke i dag? Det tror jeg ikke, men det var i bund og grund budskabet fra Dave West, der i vid udstrækning krediteres for at navngive den brede “vand-Scrum-fald-tilgang”. Vandfald nægter simpelthen at dø – og ”vand-Scrum-fald” virker som det seneste forsøg på at holde det i live.

Jeg kan ikke se tiltrækningen af ”vand-Scrum-fald”. Det er en dårligt defineret tilgang baseret på en tidligere, dårligt defineret og miskrediteret livscyklus. Det kræver et nyt navn, da det sandsynligvis bryder Scrums velartikulerede regler. I sin vage definition er der ikke noget begreb om forretningsværdi, som jeg hævder burde være “risiko”, og derfor er det uklart, hvilke fordele man vil få ved at bruge tilgangen til at guide sit arbejde. Mange af disse problemer kunne afhjælpes med en større indsats omkring formalisering af ”vand-Scrum-faldets” definition, men hvorfor gide det? Der er mange bedre dokumenterede, afprøvede og erfarne tilgange derude. Bortset fra på grund af uvidenhed eller for at fremme illusionen om kontrol er det svært at se appellen af ”vand-Scrum-fald – især i en verden hvor andre for længst har omfavnet konkurrencefordelene ved Agile og er godt på vej til DevOps.

For nogen er uønskede kontraktlige begrænsninger en dagligdags kendsgerning. På trods af de bedste intentioner og råd kan disse begrænsninger undertiden ikke undgås, hvilket resulterer i en verden med faste målskiver, faste omkostninger og faste tidsbegrænsninger. Det er netop i disse mere udfordrende miljøer, hvor vi ikke bør overveje at opgive bedste praksis for løftet om “slangeolie”. Mens trinvise, agile og metoder med gentagelse ikke tilbyder noget kvikfix, tilbyder de bedre kontrol, hurtigere reduktion af risiko og repeterbarhed gennem empirisme. Dave West råder til at stille følgende spørgsmål om ledelse omkring brugen af “vand-Scrum-fald”: “Vil du have teknologien til at hjælpe os med at tilpasse os hurtigt til trusler og muligheder?” Hvis svaret er ja, så “indstil tilgangen til at favorisere opdagelse og handling frem for planlægning og udførelse” – det vil sige: brug trinvise og erfaringsbaserede metoder med gentagelse i stedet for vandfald eller ”vand-Scrum-fald”. Hvis svaret er nej, sender du muligvis dig selv og din virksomhed ud i historiens glemsel.