Daniel Nielsen

  • 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?

  • Helt enig. Den mekaniske del har tekniske folk typisk nemt ved. Det at følge en beskrivelse ala Henrik Knibergs “… from the trenches” serier er nemt i forhold til at have det agile mindset på plads. Den anden dag faldt jeg over Mike Cohn (igen-igen) og han har skrevet http://www.mountaingoatsoftware.com/blog/the-one-true-way-to-be-agile . Det p…[Read more]

  • Det er helt rigtigt set. Vi vil gerne frivillighedens vej. Og som du selv bemærker er ledelsesforankring absolut kritisk for om Agile Excellence(AE) kan lykkes. Generelt i KMD blæser forandringens vinde kraftigt over hele firmaet og ikke mindst i BNS&AM. AE er organisatorisk forankret under ledelsen for BNS&AM. Som med de fleste større vi…[Read more]

  • Min interesse indenfor softwareudvikling har altid været bred. Det er et spændende felt! Hvad fik man valgt til og ikke mindst fra? Kan brugerne hitte ud af systemet? Hvordan sikrer vi at løsningen yder […]

    • Det er helt rigtigt set. Vi vil gerne frivillighedens vej. Og som du selv bemærker er ledelsesforankring absolut kritisk for om Agile Excellence(AE) kan lykkes. Generelt i KMD blæser forandringens vinde kraftigt over hele firmaet og ikke mindst i BNS&AM. AE er organisatorisk forankret under ledelsen for BNS&AM. Som med de fleste større virksomheder kan det være svært at forstå kommunikationsvejene internt i firmaet, men så vidt jeg er orienteret er ledelseslagene på de enkelte forretningsområde orienteret om AE. Det er sket i forbindelse med de samlede strategi seminarer de har haft i starten af året.

      Så for de projekter og teams der ligger i denne del af KMD tror vi på forandringen 🙂

    • Jeg synes det lyder som en rigtig spændende opgave. Belært af forskellige organisationer synes jeg helt bestemt at det giver mening. Mange er rigtig gode til den mekaniske del af de agile metoder, men det halter voldsomt når det kommer til det mere filosofiske. Det er muligt at køre f.eks. Scrum eller Kanban uden at være agile. Ligesom det er muligt at være agil uden at køre selvsamme metodikker.

      Den største caveat, i min optik, er at der skal være “buy in” fra ledelsen således at man ikke ender op i en vandfaldsverden og ønsker at køre agilt. Et af de første symptomer på en sådan defekt er, hvis der kræves stor analyse/scoping der fastlægger 75 % af de efterfølgende arbejdsopgaver. Det er hverken agilt eller optimalt i forhold til at skulle kunne reagere interaktivt på de tilbagemeldinger der kommer fra brugere/kunder.

      • Helt enig. Den mekaniske del har tekniske folk typisk nemt ved. Det at følge en beskrivelse ala Henrik Knibergs “… from the trenches” serier er nemt i forhold til at have det agile mindset på plads. Den anden dag faldt jeg over Mike Cohn (igen-igen) og han har skrevet http://www.mountaingoatsoftware.com/blog/the-one-true-way-to-be-agile . Det passer meget godt overens med det du skriver :-).

        I forhold KMD og ledelsens “buy in”, så afhænger det rigtigt meget af området, projektet og evt kunden hvis vi snakker Application Management. Det kommer jeg forhåbentligt tilbage til når jeg får skrevet indlæg omkring de enkelte områder vi får startet.