BLOG
DIGITAL

Blog: Agil releaseplanning med mindmaps

Hvis man er så heldig at arbejde i et projekt som bruger en agil tilgang til at styre projektet, så er der super mange ting der bliver nemmere, alene fordi projektet fra start er gearet til at kunne håndtere ændringer. 

[14. april 2015] Det er muligt for kunden/forretningen at skifte mening efterhånden som de bliver klogere og mere erfarne inden for deres område, og projektet vil kunne håndtere disse ændringer uden at der er tale om at det store ændringsanmodnings-maskineri fra vandfaldsmodellen skal bruges. I det hele taget er det en win/win :) 

Der er imidlertid et sted hvor denne agilitet og den konstante flydende tilgang til hvad der er i scope kan blive lidt af en udfordring, og det er i forbindelse med release planning. Hvis vi ydermere skalerer dette op sådan at vi ser på det med program øjne i stedet, så har et scenarie hvor interessenterne er 2+ udviklings teams, driftsorganisation, bestyrelse/programledelse og muligvis et antal forrentningsanalytikkere.

Alle disse folk skal helst være informeret om hvad planen er lige nu og så snart der er en ændring, så vil de gerne se hvad det gør ved planen. Det der specielt er udfordringen her er at selv om teams er agile og projektet er funderet på en agil tankegang, så vil der være interessenter der ikke er agile og aldrig bliver det. Jeg har f.eks. aldrig set en programledelse der har forstået hvad det agile betyder, og derfor slet ikke hvilke krav de kan stille i forhold til svar på fremskridt og jeg har heller aldrig set en driftsorganisation som er OK med at de først får en driftsvejledning og eller en releasenote lige inden go live. Jo de kan blive tvunget til at acceptere det, men generelt har de ikke lyst til at være agile, hvilket nok er forståeligt hvis man ser på deres arbejdsområde.

En måde at sikre sig at det hele glider bedre mellem den agile del af projektet og den ikke agile del af projektet er at lave det der hedder continious release planning hvilket betyder at man i programmet laver opfølgning på selve release planen, med et fast interval, som f.eks. én gang om ugen, plus efter behov. Det er ikke specielt svært, men det der godt kan blive lidt udfordrende er at kommunikere dette til alle interessenter på en nem og overskuelig måde og som, vigtigst af alt, ikke tager lang tid. Det er her jeg finder at en mindmap er sagen. Man kan lave et sådan mindmap og hænge det op som en information radiator eller man kan uploade det til sit projektstyringsværktøj, eller begge, alt efter hvad der er muligt og giver mening i projektet. Herunder er et eksempel på et sådan mindmap.

 

Releaseplanning med mindmaps

 

Dette giver mulighed for nemt at give et overblik over hvilke sprints der er til næste release, hvilke datoer der er specielle, f.eks Påske. Det giver også mulighed for hurtigt at give overblik over hvad der leveres som en del af denne release samt hvis der er nogen datoer der er vigtige i forhold til enten go live sikring eller andre deadlines. Man kan lave en hurtig reference over hvilke krav der adresseres i denne release samt hvilke systemer eller delsystemer der er omfattet af releasen.

De fleste mindmapping værktøjer giver også mulighed for at relatere de enkelte grene af et mindmap sammen sådan at man kan lave en oversigt over hvilke stories der kommer fra hvilke krav, og hvilke systemer/delsystemer der bliver ændret af de enkelte stories.

Herunder er det f.eks. samme mindmap fra før, men her er der lavet relationer mellem krav og de stories der er i første sprint for hvert team.

Releaseplanning med mindmaps

 

Man kan også forestille sig relationer mellem krav og delsystemer hvis det giver mening, eller begge dele måske. Langt det meste af mindmapping software som jeg har arbejdet med, giver også muligheden for at vise eller skjule detaljer, såsom relationer, sådan at man kan have forskellige views på samme mindmap alt efter hvad ens rolle er.

De fleste mindmapping softwares giver også mulighed for at annotere de enkelte grene i et mindmap med ikoner. Dette kan bruges til f.eks. at angive prioriteter eller rapportere fremgang for hvad den enkelte gren nu repræsentere. Dette kan også bruges til at lave en alternativ gruppering, på linje med hvad vi kender fra de forskelligt farvede flag man kan sætte på meddelelser i Outlook. Faktisk har alt det mindmapping software jeg har prøvet givet muligheden for at bruge forskelligt farvede flag, prioritetsikoner fra 0-9, samt fremgangs ikoner som minimum er delt op i 0%, 25%, 50% og 100%.

Hvis du går rundt med nogle udfordringer der ligner dette, vil jeg anbefale at du prøver denne ide af, det er meget effektivt :) 

todo todo