Hvor godt kender du det agile manifest? Du ved måske at det er skrevet af 17 softwareudviklere i Utah i 2001, men har du nærlæst hvad det egentlig siger?
Det agile manifest
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie van Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler, Brian Marick.
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
Men hvad betyder det? Den første del er vigtig. “Vi vil finde frem til gode fremgangsmåder til at udvikle software – og det gør vi ved at udvikle software og ved at hjælpe andre med at udvikle software.” Dette antyder noget eksperimentelt – og ikke præskriptivt. Forfatterne påstår ikke de har svaret på, hvordan vi skal gøre tingene, men at de bliver ved med at afprøve ting og indsamle erfaring: “Learning by doing”.
I dette indlæg vil jeg fokusere på den første af de 4 linjer i kontekst – den del der siger:
Through this work we have come to value:
– Individuals and interactions over processes and tools.
That is, while there is value in the items on the right, we value the items on the left more.
Hov! Stod der lige der at det agile manifests bagmænd ikke går ind for processer, såsom Scrum og Kanban? Næh, faktisk ikke. Der står at der er værdi i processer og værktøjer, men at de ikke prioriteres så højt som individer og interaktioner. Det er jo en lidt kryptisk formulering. Vi er nød til at kigge nærmere på hvad individer og interaktioner dækker over for at forstå hvad de mener.
Interaktioner betyder vores samarbejde. Selv-organiserende teams, god kommunikation, teamaktiviteter såsom parprogrammering og retrospectives, hele teamet på samme lokation og mange andre tiltag falder i denne kategori.
Individer betyder fokus på mennesker. Er den enkelte motiveret? Føler alle sig hørt? Kan alle komme til at bidrage med deres fulde potentiale? Tager alle ansvar for produktet og kvaliteten? Trives teammedlemmerne?
Alt i alt fortæller det agile manifests ophavsmænd os altså at de sætter større værdi i velfungerende kommunikation, velfungerende teams og velfungerende team-medlemmer end i at følge opskriften/metoden og bruge de rigtige værktøjer. De bløde værdier. Det betyder ikke at der ikke er gode metoder derude der kan hjælpe os på vej, men fokus skal altid være på menneskene og deres behov.
Personligt har jeg set mange projekter drukne i proces-diktering. Det er fristende at udtale sig om “den rigtige måde” at køre Scrum/Kanban/Scrumban/* på (jeg er sikker på, at jeg har gjort det ved flere lejligheder) og derfor kan det være godt at blive mindet om at mennesker kommer før metoder. “It depends” er konsulenternes favoritudtryk, fordi der er ikke en klar opskrift, der altid virker – det kommer i høj grad an på dit team, dine folk og dine omstændigheder.
Retrospectives og lignende løbende evalueringer spiller en stor rolle i proces-tilpasning. Det er denne mekanisme, som lader os lære af de mindre hensigtsmæssige ting og som får os til at handle og ændre de ting der ikke virker for os.
En af ulemperne ved at prioritere mennesket over processen er, at det kan bruges som en dårlig undskyldning. Fravælger vi en del af en metode, fordi det er svært, ubehageligt eller et pain point eller fravælger vi det, fordi det ikke bringer værdi eller passer til det team vi står med nu? I praksis kan der være værdi i at lære at følge en opskrift “efter bogen” og derefter tilpasse opskriften til teamets palette, men igen “it depends”…
Kort sagt, så skal vi kæmpe imod instinktet om at hovedløst følge reglerne og acceptere at softwareudvikling ikke er så enkelt at der findes en eneste opskrift der virker. Folkene bag det agile manifest har erfaret at succes i it-projekter ofte hænger sammen med at sætte mennesket over processen og værktøjerne. Vi må ikke blive for rigide og lade værktøjer eller procesregler forhindre os i at tilpasse vores arbejdsgange til teamets styrker og svagheder. Samtidig skal vi holde udkig efter om vores proces-tilpasninger nu også reelt er i projektet bedste interesse og ikke er et udtryk for dovenskab eller konfliktskyhed.
Har I sat teamet over processen? Hvilke fravalg/tilvalg har I gjort for at tage hensyn til de individuelle styrker/svagheder?
I disse tider er vi alle-sammen agile… eller ikke mange vil indrømme at de arbejder ikke-agilt. Som jeg før har nævnt er Scrum populært, men også Kanban eller Scrumban er metoder jeg har set i brug.
Det kan være svært at arbejde agilt og når jeg hører snak om uenigheder om den bedste måde at gøre tingene på, ryger diskussionen ofte tilbage til det agile manifest – på en måde er det jo definitionen af agilt arbejde.
Det agile manifest
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
Men hvad betyder det? Den første del er rimelig tydelig. “Vi vil finde frem til gode fremgangsmåder til at udvikle software – og det gør vi ved at udvikle software og ved at hjælpe andre gøre udvikle software.”
[…] det første indlæg om det agile manifest kiggede vi udelukkende på det første punkt ud af fire “Individer og interaktion over […]
[…] i kontekst lyder det fjerde og sidste punkt i det agile manifest (se også punkt 1, punkt 2 og punkt […]