Six Sigma, Lean, PMBOK, Scrum vs. Kanban – Der er mange projektledelses jargon og metode debatter, som du måske har svært ved at finde rundt i. Der er dog kun få metoder der er vigtige når du forsøger på at skabe en effektiv projektplan.
Projektledelses metoder skal give projektgruppen et framework eller teori til at basere deres projektplanlægning omkring. De har alle deres fordele og ulemper, men nogle få metoder giver en fordelagtig måde at visualisere din projektplan.
Både Scrum og Kanban falder under den agile metodeparaply, hvilket gør dem gode frameworks til at bryde større, komplekse projekter ned til mindre håndterbare stykker. Lad os tage et kig på forskellene mellem disse to og komme til bunds i debatten om Scrum vs. Kanban.
Hvad er Scrum?
Scrum er et projekt framework til at implementere den Agile projektledelses metode. Det er en populær metode til at håndtere projekter der kræver hurtig udvikling, tests, og udgivelsen af produkter.
Scrum frameworks bryder et projekt ned til korte en- til fire ugers tidsperioder, kaldet sprints. En Scrum projektgruppe, som regel ledt af en Scrum mester, arbejder på at levere en version af det endelige projekt i slutningen af hvert sprint. Scrum projektgrupper har også daglige stående møder for at diskutere fremskridt og øge holdsamarbejde.
Hvad er et Scrum Board?
Et Scrum Board er et værktøj der hjælper dig med at håndtere og overvåge dit Scrum projekt. Det hjælper dig med at visuelt spore hvad arbejder der mangler i dit produkt backlog, hvilke genstande der er tildelt til din sprint backlog, og hvordan arbejder skrider frem inden for dit aktive sprint.
Mens Scrum boards kan være et fysisk board med post-it, er de ofte digitale online boards, som er inkluderet i mange projektledelses platforme.
Der er nogle fordele og ulemper ved at bruge Scrum og Scrum boards til at håndtere dine projekter:
Fordele:
- Fejl kan blive udbedret og potentielle problemer kan undgås
- Ændringer kan nemt blive håndteret på grund af korte sprints med kort feedback
- Du kan ændre udviklingen hvornår som helst fordi denne proces øger fleksibiliteten
- Klienter kan få adgang til en gennemsigtig proces, hvilket tillader dem at følge hele proceduren og måle individuel produktivitet
- Scrum metoden er ofte budget-venlig fordi den er så simpel
Ulemper:
- Den er iterativ, så det kræver kontinuerlig feedback fra projektgruppen for at forbedre processen
- Denne proces kræver meget troværdighed inden for projektgruppen. Hvis styringen er for streng, så kan hele projektet fejle
- Det er ikke nemt for et medlem af projektgruppen at forlade projektet undervejs
- Ændringer i omfanget kan opstå hvis der ikke er nogen deadline
- Det kommer ikke med nogen estimeret tidsbegrænsning og omkostningsevaluering, hvilket kan resultere i mange sprints
- Der er et større pres på gruppemedlemmer og de skal bruge meget tid på projektudvikling
Hvad er Kanban?
Kanban er endnu et populært agilt framework. Med i modsætning til Scrum, så er Kanban mindre tidsbaseret og mere fokusret på at håndtere volumen af work in process (WIP).
Kanban frameworks var designet for at hjælpe med at vedligeholde et kontinuerligt flow af produktivitet og samtidigt sørge for at ingen i gruppen har overarbejde eller er overvældet. Det hjælper projektgrupper med at fjerne flaskehalsproblemer, øger effektiviteten, øger kvaliteten og øger det overordnet output.
Hvad er et Kanban board?
Traditionelt involverer Kanban et planlægnings board, hvor statusser som ”Planlagt”, ”Undervejs”, ”In Review”, osv., alle er skrevet ned.
Hver levering er så skrevet ned på en post-it-note og placeret under den korrekte status. Som leveringen bevæger sig gennem de forskellige stadier, flytter man post-it-noten gennem de forskellige projektstadier på.
Her er nogle fordele og ulemper ved at bruge Kanban og Kanban boards til at håndtere dit projekt:
Fordele:
- Hjælper med at skubbe arbejde der ofte sidder fast gennem til færdiggørelse
- Det er godt for at opdele arbejde baseret på den der skal lave det
- Det er ideelt for leveringer som er meget afhængige af deres status
- Det er nemt at sætte op og implementere hvor som helst
- Arbejdsbyrder er synlige og nemt formbare
- Du kan hurtigt tjekke og evaluere produktivitet over hele din projektgruppe
Ulemper:
- Siden der ikke er nogen tidsbegrænsninger, kan leveringer bevæge sig langsommere
- Forældet Kanban boards kan nedsætte produktivitet
- Hvis du bruger det traditionelle whiteboard organiseringssystem, så er det svært at tilknytte det faktiske arbejde med boardet selv
Kanban vs. Scrum: Hvad er forskellene?
Kanban og Scrum er begge projekt frameworks der er bygget til at hjælpe projektgrupper med at bruge den agile metodiske værdiprincipper. Derfor har de begge mange ligheder. Begge frameworks frembringer procesforbedringer, gruppesamarbejde, og bryder projekter ned i mindre og mere håndterbare stykker. Men, Kanban og Scrum har meget forskellige tilgange i hvordan de vælger at implementere disse principper.
Her er fem essentielle områder hvor Kanban og Scrum varierer:
Roller og ansvar
Scrum har tre specifikke roller, hvor med sine egne foruddefineret ansvar:
- Scrum master: Fungerer som faciliteter og coach. Deres job er at hjælpe med at fjerne flaskehalsproblemer og at holde projektgruppen i en fremadgående retning.
- Product owner: Skaber produkt roadmap og står for at sørge for at kundens behov og ønsker bliver fulgt i produktets features.
- Team member: Scrum projektmedlemmerne gør størstedelen af projektets arbejde. De er et selv-styret hold som er involveret i planlægning, eksekvering og at gennemtjekke projekt sprinter og deres outcome.
Kanban giver ikke roller ligesom Scrum gør. Faktisk, så er en af de fire principper af Kanban, at projektgrupper bør beholde deres nuværende roller og ansvar. Troen bag dette princip er at hold vil tilpasse sig frameworket nemmere, hvis de ikke skal tænke over at ændre jobtitler og beskrivelser.
Delegering og prioritering
Scrum er baseret omkring ideen af selv-håndteret projektgrupper der arbejder sammen om at færdiggøre et projekt. Product owner har muligvis det endelige at skulle have sagt over hvilke features eller opgaver deres er prioriteret højest i produkt bacglog (en liste af alle features, opgaver, og arbejder der skal færdiggøres i projektet), da de virker som en repræsentativ for klientens behov. Men, hele projektgruppen giver inputs i hvilke opgaver der skal håndteres i en sprint.
Scrum gruppemedlemmer har også typisk fuld autonomi når der kommer til at færdiggøre arbejdet inden for en sprint. De kan vælge hvilke dele de arbejder på og hvornår, så længe alt er færdigt i slutningen af en sprint.
Kanban frembringer samarbejde og lederskab ved alle niveauer, men er ikke åbent over for selvstyret projektgrupper på samme måde som Scrum er. Siden Kanban promoverer at projektgrupper beholder deres gamle roller, så plejere gamle gruppestrukturer at diktere hvordan uddelegering er håndteret.
Ofte så vil lederes står for at prioritere arbejde og aktivt håndtere arbejds-flowet. De kan uddelegere specifikke opgaver til specikke individer eller tillade at de bliver håndteret som ”first come, first served.”
Modificering og ændringer
Scrum og Kanban håndtere modificeringer og ændringer på forskellige måder.
Med Scrum er en sprint planlægt før den begynder, projektgruppen eksekvere på arbejdet, og sprinten slutter med en produktlevering og gennemtjek. Enhver kundes feedback, problemer, fejl eller forespurgt ændringer er så tilføjet til den overordnet produkt backlogs og arbejdet ind i fremtidige sprinte baseret på prioriteten.
Ændringer der er identificeret undervejs, vil ikke blive håndteret for nye sprints kommer i gang, med mindre der er en special årsag til at denne skal tjekkes. Det betyder også at sprint tidslinjer ikke ændrer sig, men at flere sprint måske skal tilføjes til det overordnet projekt hvis nok ”change request” opstår.
I Kanban, så kan ændringer laves når som helst, og modificeringer er aktivt opfordret med det samme. Dette kan have en effekt på projektets tidslinje, alt efter hvor stor en ændring det er.
Kanban var originalt skabt af Toyota til bilfremstilling og er ofte brugt til at håndtere mange af de samme opgaver eller stykker arbejder. I dette scenario, hvor produktet ikke kan skifte ejerskab, så er det endnu vigtigere at få leveret en volume i stedet for et lille stykke. Så når er produkt er beskadiget, defekt eller har brug for at blive repareret, er det som regel trukket ud af arbejdsflowet for for at blive smidt ud eller ændret.
Produktivitetsmålinger
Scrum afhænger af faktorer som velocity og burndown rates for at måle produktiviteten.
- Velocity: Sporer mængden af arbejde et hold skal gennemføre gennem en sprint.
- Burndown charts viser hvor meget arbejde der stadig mangler at blive færdiggjort.
Sammen, så hjælper disse frameworket med at illustrere hvor produktiv projektgruppen har været indtil videre, og hvor produktive de skal være for at forsætte med at være for at færdiggøre projektet til tiden.
Kanban overvåger typisk cycle-time, lead time og work-in-progress for at måle produktivitet.
- Cycle time måler hvor lang tid der tager for en opgave at blive færdiggjort. Denne måling tager som regel et gennemsnit om hvor meget af arbejdet der nyder fremskridt.
- Lead time er en bredere faktor der måler hvor langt fra en opgave var identificeret eller tilføjet til dit Kanban board indtil det var færdiggjort.
Forestil dig at du vil tildelt en opgave mandag morgen, du startede selv på den onsdag morgen, og du færdiggjorde den i slutningen af fredag. I dette scenarie var din tid også fem dage og din cyklus på tre dage.
Work-in-progress: Måler gennemsnittet af volumen af opgaver in ”in-progress” stadiet på dit Kanban board.
Forfaldsdatoer og leveringstidslinjer
I Scrum er sprints typisk en til fire uger i længde, og en produktforbedring, eller en version af produktet, er afleveret i slutningen af hvert sprint. Ethvert støttende dokument, som træningsmaterialer, vil også blive leveret på dette tidspunkt. Der er sjældent mid-sprint forfaldsdatoer eller leveringer.
Undtagelsen ville være, når indbyrdes afhængige opgaver begge tildeles den samme sprint. Hvis opgave B ikke kan starte, før opgave A er afsluttet, kan opgave A muligvis gives en tidlig nok forfaldsdato for at sikre, at begge færdiggøres i tide til levering. Imidlertid er der ofte ikke tildelt nogen formel forfaldsdato, og holdet administrerer simpelthen disse afhængigheder i deres daglige stående møder.
Kanban er baseret omkring ideen af kontinuerlige leveringer. Kanban projektgrupper arbejder ofte på uafhængige opgaver, produkter, eller leveringer. Så når et stykke arbejde er færdigt, så kan det blive leveret til kunden med det samme.
Projektgrupper kan vælge at gruppere leveringer, så de ikke konstant sender en ting ad gangen, men måden de gør dette på er op til dem. For eksempel, kan du vælge at sende dem hver fredag eller hver gang du har 20 færdige stykker.
Når det kommer til forfaldsdatoer, er Kanban’s primære fokus ofte cycle time og lead time i stedet for hvilket arbejdet der skal afleveres hvornår. Det betyder at forfaldsdatoer ofte er baseret på målsatte leveringstider i stedet for hvornår kunder kan forvente leveringer.
For eksempel, hvis målet er en gennemsnitlig cycle time af fem dage, så har hvert kort en forfaldsdato på fem dage fra når opgaven er givet, selv hvis det ikke bliver leveret til kunden indtil slutningen af måneden.
Hvilket projektledelses framework er bedst?
Svaret til hvornår du skal bruge Kanban vs Scrum afhænger af typen af projektet du planlægger. Scrum og Kanban er bedst egnet til forskellige projekter.
Men her er en kort analyse:
- Til engangsprojekter der har mange variabler og usikkerheder, er mere deadline-orienteret, og involvere en større projektgruppe, Scrum er et bedre framework
- Til projekter som du har lavet før eller er gentagende, involvere mange leveringer, og kræver at du holder nøje øje med individuel kapacitet, Kanban er et bedre framework
Scrum vs. Kanban: Skal det være enten eller?
Der er en tredje mulighed kaldet Scrumban. Det er en kombination af de to frameworks der forsøger at give en mellemgrund for projektgrupper, som finder Kanban for fleksibelt og Scrum for strengt.
Uanset hvilket projekt du er i gang med, er ændringer uundgåelige. At bruge en agil metode er det første skridt for at forbedre samarbejde, forbedre konsekvente processer, og at have fleksibilitet indbygget, så dig og din projektgruppe er i stand til hvad end der kastes din vej.
Nu da du har landet den rigtige metode for jobbet, så skal du have styr på en at skrive en god projektplan.
