Jeg har for nyligt besøgt et team bestående af få udviklere, en projektleder og flere service-konsulenter og forretningsspecialister. Detaljerne i besøget vil jeg ikke komme ind på her, men kort sagt vil jeg nævne at vi brugte god tid på at forstå forretningsområdet og teamets normale hverdag.
Denne diskussion førte til at teamet fravalgte en Scrum process, mens de aktivt tilvalgte en Kanban process. Flere medlemmer af teamet har erfaring med Scrum, der er endda en certificeret ScrumMaster på teamet, så de har en god ide om hvad de har valgt fra. Den valgte process ligner til forveksling den Scrum process vi i Agile Excellence anbefaler, men med en Kanbantavle og fornuftige limits i stedet for sprints med commitment. Den primære faktor til teamets beslutning ligger i typen af opgaver der fylder deres hverdag. Jeg er meget tilfreds med deres engagement i og følelse af ejerskab for processen.
Det vigtigste element i processen for dette team er at kunne dokumentere lead-time på visse typer af opgaver, altså tiden fra at opgaven modtages til den påbegyndes. Det er primært hårde krav i en underskrevet SLA der er til grund for dette. Derfor kan det være meget dyrt hvis en ny, høj-prioritets opgave skal vente til næste sprint. Kanban gør det nemt at dokumentere lead-time; man skriver et tidsstempel på opgaven når den kommer på tavlen og igen når opgaven påbegyndes.
Historikken for teamet viser at disse opgaver modtages ”ofte”, men datagrundlaget for et kvalificeret bud på hvor meget disse opgaver faktisk fylder i hverdagen er ikke alt for godt. Derfor er fornemmelsen at med en Scrum process, vil det ende med for mange afbrudte sprints og det vil teamet gerne undgå.
Agile Excellence gruppen anbefaler Scrum og nok er en Scrum process fleksibel, men som nævnt findes der ingen ”silver bullet”. Erfaringen gjort med dette team siger at måden hvorpå man som team arbejder, kan afhænge af typen af de opgaver man møder. Der er selvfølgeligt mange andre faktorer der også spiller ind, men lad det nu ligge.
Opgavetyper
Groft sagt kan man sige, at de opgaver som teams møder, falder i én af to kategorier: Udvikling og forvaltning.
Et team med primært udviklingsopgaver er typisk dannet som en del af et projekt – som bekendt er projekter tidsbegrænset – og deres mål er sat af de overordnede beslutninger og bevæggrunde som ledte til projektets søsættelse. Bevæggrunde for nye projekter i KMD kan fx være konkurrenternes forspring, lovmæssige ændringer eller vundne udbud.
Teams med primært forvaltningsopgaver er de teams, der står tilbage når produkterne er i drift og projekterne lukket ned. De står for det løbende vedligeholdelse og den tekniske support. Et forvaltningsteam har typisk ansvaret for flere produkter og skifter lystigt imellem disse. Forvaltningsopgaverne er dem hvor der kan være bundet SLA-krav til, og det er dem der kan make-or-breake kundernes dag. Derfor kan det være svært at forudsige hvor mange opgaver der kommer, deres prioritet og hvor meget tid de tager. Det team jeg her har nævnt her, er et typisk forvaltningsteam.
Lesson learned
I Agile Exellence foretrækker vi stadigt at introducere teams for en Scrum process, men hvis opgaverne er overvejende forvaltning og kun begrænset udvikling, præsenterer vi nu gerne alternativer. Som nævnt tidligere er vi ikke interesseret i at diktere processen, der er kun få krav — som jeg håber at komme ind på senere. Det er op til de enkelte forretningsområder og teams af fastlægge detaljerne i deres process, med os som sparringspartnere.
Så vi fandt noget andet end en hammer. Har du prøvet at ende med en anden vinkel på opgaverne end forventet? Og har du et eksempel?