Ranking vs. Rating – Den lille forskel med den store impact

Et af de steder, hvor agil tilgang til projekter adskiller sig fra den traditionelle, er måden, man prioriterer på. Traditionelt sker prioriteringen i projekter og programmer ved rating, f.eks. MoSCoW (must have – should have – could have). Rating-tilgangen giver en række udfordringer i organisationer, der bedst illustreres ved spørgsmålet ”Hvad gør jeg som medarbejder, hvis jeg ikke kan nå alle must haves indenfor den givne deadline?”

Rating-tilgangens 3 faldgruber

Medarbejderen har tre muligheder: 1) Han kan starte på alle opgaver hvilket medfører at ingen af opgaverne er færdige til deadline, 2) Han kan vælge at fokusere på en opgave uden at forstå effekten på hele programmet, 3) Han kan spørge opad i organisationen, hvilken opgave man skal starte på (hvilket giver et massivt pres på beslutningstagere, da beføjelsen skubbes op ad i organisationen). Det skulle gerne stå klart at alle tre valgmuligheder er ineffektive, og faktisk koster noget for organisationen. Og oven på de dilemmaer medarbejderen står med, så er ledere og organisationer, der styres ved rating, ofte kendetegnede ved skiftende prioriteringer, hvilket giver yderligere sunk costs på arbejde, der aldrig færdiggøres.

Ranking sikrer en ærligere proces

Den agile tilgang til prioritering er ranking. I en agil backlog er Epics, Features og user stories rangordnet efter forretningens prioriteringer. Rangordning betyder, at de er ordnet efter rækkefølge. Mange er ikke opmærksomme på forskellen, men det er fundamentet for en anden måde at arbejde på, der løser de problemer, som jeg beskrev ovenfor. En rangordnet backlog betyder, at medarbejderne altid kan ”trække fra toppen” af backloggen. Beslutningen om, hvad en medarbejder skal fokusere på, er transparent og uddelegeret, hvilket betyder at time to market for de enkelte user stories bliver markant kortere, i og med at alle ved, hvad de skal lave, og at man ikke påbegynder en ny opgave, før den forrige er færdiggjort. En rangordnet prioritering skaber også grundlaget for bedre forecasts, idet comittment for en tidsperiode kan benchmarkes mod faktisk leverance i tidligere tidsperioder. Det er med andre ord grundlaget for en ærlig datadrevet proces. Endelig skaber en rangordnet backlog et pres for at skære ind til benet og rangordne efter cost-benefit på hver enkelt user story. Ofte ligger 80% af værdien på 20% af opgaven. Hvis man splitter opgaven i to, vil den mest værdifulde del kunne prioriteres op, mens den mindre værdifulde vil synke til bunds i backloggen.

Det handler om en ny deadlinekultur

Når dette skift er svært i mange organisationer, kan det hænge sammen med et kulturelt fokus på deadlines. I en rangordnet prioritering håndteres deadlines ved at ændre på rækkefølgen af opgaverne. Den sikreste måde at nå sine deadlines er faktisk at justere sit scope løbende efter værdi i en rangordnet backlog. Hvis du holder fast i frosne projekttrekanter og rating, så får du måske nok følelsen af kontrol, men du mister reelt styringen. Ofte opdager styregruppen først den reelle status og kvalitet i projektet for sent til, at det kan rettes op. I mit arbejde som agil coach er forankringen af ranking en fundamental byggesten i at lykkes i en agil transformation. En case kunne være et projekt leveret til en offentlig kunde, hvor kunde og leverandør i fællesskab arbejdede med en rangordnet backlog indeholdende fejl og ændringsønsker. Da projektet blev afsluttet, blev en større mængde fejl lukket, da kunden ikke vurderede, at de var vigtige nok til at blive løst. De ville blive prioriteret efter overgang til i drift. Dette var kunden dog helt indforstået med, da de bevidst havde prioriteret en række ændringsønsker ind i stedet.

Vær social og del dette indlæg

Del på facebook
Facebook
Del på linkedin
LinkedIn

Artikler du vil synes om...

agil estimering
Mette Muxoll Schou

High-level Estimate

Forfatterens kommentar: When product development is funded by larger programs or projects governed by stage-gate models, it can be difficult to fully or partially ripe

Læs nærmere >