Scrum

Scrum er et framework til udvikling af komplekse produkter, defineret af et lille sæt af roller, begivenheder og artefakter, der opererer med en fast kadence. Det specificerer tre ansvarsområder: en produktejer, der er ansvarlig for at maksimere værdien af ​​arbejdet, en scrum master, der er ansvarlig for processens effektivitet, og udviklere, der bygger inkrementet. Dets begivenheder er selve sprintet, sprintplanlægning, den daglige scrum, sprintgennemgangen og sprintretrospektivet.

Frameworket er bevidst minimalistisk og beskriver, hvad der skal ske, uden at foreskrive hvordan. Det er ikke en metode, der leverer tekniske praksisser, estimeringsteknikker eller kravformater; disse overlades til teamet. Denne minimalisme er bevidst, da frameworkets præmis er, at de teams, der er tættest på arbejdet, selv skal bestemme deres metoder, men det betyder også, at et team, der anvender Scrum uden komplementære tekniske praksisser, har en koordineringsstruktur og ingen teknisk disciplin.

Hver begivenhed eksisterer af en grund, der ofte går tabt. Planlægning fastlægger, hvad der vil blive forsøgt, og hvorfor. Den daglige scrum er til for udviklerne at koordinere og afdække hindringer, ikke en statusrapport til en leder. Gennemgangen er til for at inspicere tiltaget med interessenter og tilpasse retningen, ikke en demonstration. Retrospektivet er til for at forbedre, hvordan teamet arbejder. Når disse bliver til rituelle forestillinger med deres oprindelige formål glemt, bruger de tid og producerer ingenting, hvilket er den mest almindelige klage over rammeværket.

Det er produktejerens ansvarlighed, der oftest bryder sammen med implementeringer. Rollen kræver reel autoritet til at bestemme prioritet og tilgængeligheden til at træffe beslutninger løbende, og organisationer udpeger ofte en person uden nogen af ​​delene, som skal eskalere ethvert meningsfuldt valg. En produktejer uden autoritet omdanner rammeværket til en købehandlingsordning, hvor teamet udfører beslutninger truffet andre steder og mister den tilpasningsevne, der motiverede tilgangen.

Den faste sprintlængde tjener et formål, der er værd at forstå, før det opgives. En ensartet kadence skaber en rytme for planlægning, gennemgang og tilpasning og tvinger arbejdet til at blive opdelt i dele, der kan fuldføres og vurderes. Teams, der forlænger sprints, når arbejdet ikke passer, har fjernet den begrænsning, der forårsagede nedbrydningen, og glider typisk hen imod længere cyklusser med mindre hyppig feedback.

Retrospektiven er samtidig den mest værdifulde begivenhed og den første, der droppes. Det er den mekanisme, hvormed et team forbedrer sin egen proces, og uden den gentager et team de samme hindringer i det uendelige. Retrospektiver, der ikke producerer nogen ændret adfærd, er værre end ingen, fordi de fastslår, at det at rejse problemer ikke opnår noget, så det er sporing af, om identificerede handlinger rent faktisk udføres, der holder begivenheden meningsfuld.

Frameworket passer langt bedre til noget arbejde end til andet. Det passer til produktudvikling med reel usikkerhed, et stabilt team og en reel kunde at lære af. Det passer betydeligt mindre godt til uplanlagt driftsarbejde, vedligeholdelse med uforudsigelig ankomst og meget afbrydelsesdrevne kontekster, og teams i disse situationer klarer sig ofte bedre med en flowbaseret tilgang, der ikke kræver forpligtelse til en fast batch.

Da effektivitet afhænger af autoritet, teamstabilitet og organisatorisk støtte snarere end af overholdelse af ceremonier, bør evalueringen fokusere på resultater snarere end overholdelse. I praksis etableres leveringsmetoden inden for produktudvikling, produktejerens beslutninger er baseret på beviser fra produktundersøgelse, og for en små eller mellemstore virksomheder Det er ofte værd at reducere rammeværkets overhead til fordel for en lettere ordning, der er egnet til et enkelt lille team.