Agile Manifesto – om den agile metode

I Headfitted arbejder vi agilt. Den agile metode er en integreret i den måde, vi udvikler software på – og leder projekter. Men hvordan karakteriseres den agile metode? 

 Inden for den softwareudvikling, henvises oftest til Agile Manifesto. Et manifest, der beskriver den agile metodes kerneelementer.   

I manifestet fremsættes 8 grundlæggende elementer, som indgår i den måde, vi arbejder agilt på.
Af de 8 begreber er 4 af dem fremtrædende elementer, i forhold til den agile metode. Dermed ikke sagt, at de sidste 4 begreber kan undlades. Det handler om, at de fremtrædende elementersom den agile metode opererer på, ikke kan stå alene – og derfor har de en modpart. 
Det er således i dette spænd, at den agile metode fungerer optimalt. 

Billede2.png

 

Individuals & Interaction vs. Processes & Tools

Ved de første to begreber forstås, at det er de enkelte mennesker og deres interaktion med hinanden, som er vigtigere i den agile metode end processer og værktøjer. Dermed ikke sagt, at processer og værktøjer ikke er vigtige. Man kan have de bedste processer og de bedste værktøjer - men hvis personerne i dit team ikke kommunikerer fyldestgørende med hinanden, er der ingen processer, som kan redde dig. 
Til gengæld kan du få dit arbejde gennemført, hvis dit team kommunikerer fyldestgørende med hinanden, og du har processer som virker. 

 

Working Software vs. Comprehensive Documentation 

Ved disse begreber forstås, det er vigtigere at levere et produkt som virker, end at bruge tid på flere siders dokumentation.
Det er dog blevet tolket af mange softwareudviklere, at de ikke behøver skrive dokumentation – hvilket ikke er korrekt. Dokumentation er essentielt, da udviklingsteamet kan se tilbage på tanker, ideer og kritik, som kan optimere fremtidige udviklingsprocesser. Derudover er det er også vigtigt at have overordnet dokumentation for et projekt. Dog må dokumentationen må ikke være for tung - det passer ikke til den agile metode, hvor kursen under en produktudvikling, kan ændres undervejs. Det betyder, at teamet kan bruge for meget tid til at dokumentere omkring processen, end at udvikle selve produktet. Dette vil vi gerne undgå, idet produktet i sidste ende, skal leveres til kunden. 

 

Customer Collaboration vs. Contract negotiation

Costomer Collaboration er vigtigere end Contract Negotiation. Det er en forudsætning for et samarbejde, at der findes en skriftlig kontrakt mellem virksomhed og kunde. Der skal være en fælles forståelse og godkendelse af vilkårene i et samarbejde, således der ikke opstår misforståelser. Derfor er Customer Collaboration vigtigt, når vi arbejder agilt: 
I det agile arbejde kan kravspecifikationer til et produkt ændre sig over tid, da teamet undervejs i udviklingsprocessen bliver klogere på kundens behov, for et produkts kunnen. Netop pga. dette, kan det ske, at et projekt går over tid. Derfor er det essentielt at samarbejde med kunden, så kunden er indstillet på at projektet går over tid – selvom der er fastsat en deadline i kontrakten. Dog skulle produktet gerne hindeholde flere funktioner, der passer til kundens behov - og dermed får kunden et bedre produkt i sidste ende. 


Responding to change vs. Following a plan

Det er vigtigt at følge en projektplan. Men somme tider forandres virkeligheden, hvilket kan have indflydelse på den oprindelige plan. I agilt arbejde er det derfor vigtigt, at man kan ændre planer, så produktet også har en reel funktion, når det er færdigudviklet. Eksempelvis vil det ikke være ´optimalt, hvis teamet har udviklet et produkt, der ikke lever op til en ny lovgivning – en lovgivning der er blevet vedtaget, mens produktet har været under udvikling. 

 

Opsummering

At arbejde agilt handler om at være omstillingsparat og fleksibel. Som team skal man være klar på, at udviklingen af et produkt ikke sker i en kronologisk rækkefølge. I arbejdet med udvikling af produkter, bliver teamet undervejs klogere på, hvordan produkterne bedst muligt skaber værdi for kunden. Samtidig beror arbejdet også på produktets tekniske formåen, som kan være med til at ændre de oprindelige tanker om produktet. Derfor er kommunikation mellem kunde og udviklere vigtigt, med henblik på, at tingene kan ændre sig i udviklingsprocessen. 

Scrum-processen i praksis

Overblik over interessenter og stadier i en Scrum-proces

Som softwarehus arbejder vi agilt på baggrund af Scrum-metodikken. Kort fortalt er Scrum en iterativ udviklings- og projektledelsesmodel, som er med til at sikre god kommunikation og tæt samarbejde imellem kunde, udviklere og slutbrugere fra start til slut i et IT-projekt. Du kan læse mere om Scrum i en af vores tidligere artikler her.

I dette indlæg vil jeg gøre dig klogere på, hvordan en Scrum-proces fungerer i praksis. Dette er med beskrivelse af de forskellige interessenters roller og opgaver, samt hvordan deres relationer er i en agil arbejdsproces. 

Scrum-model
Til at forklare de forskellige stadier en Scrum-proces indeholder, herunder interessenters roller, vil jeg tage udgangspunkt i Headfitteds egen Scrum-model, som forklarer den proces et softwareprodukt udvikles igennem.

Headfitted’s Scrum-model er illustreret af Mikkel Thormod, CTO i Headfitted ApS

Headfitted’s Scrum-model er illustreret af Mikkel Thormod, CTO i Headfitted ApS

Idémanden
Lad os begynde øverst i modellens venstre hjørne med kunden. Kunden er ikke nødvendigvis en ekstern kunde – det kan også være en intern ’kunde’, dvs. en person i virksomheden som er idémanden til et nyt produkt. Men for udviklingsteamet ses vedkommende som en kunde, man skal udvikle noget for. 

Rent praktisk foregår det således, at kunden henvender sig til Product Owneren og fremlægger sin idé. Product Ownerens opgave er nu at sikre return on investment ved udvikling af produktet. Vedkommende vurderer således, hvor mange timer og penge man skal bruge på at udvikle produktet – og om det kan betale sig. 
Alt efter hvem kunden er, kan Product Owner være CEO, CTO – eller en medarbejder som har fået til opgave at finde ud af, hvordan produktet bedst giver business value. Derfor udarbejder Product Owneren i samarbejde med kunden en backlog hvor der står beskrevet, hvilke funktioner de gerne vil have udviklet i et softwareprodukt. Backloggen sendes til udviklingsteamet. 

 

 Forventningsafstemning
Udviklingsteamet estimerer tiden på de forskellige issues i backloggen. Det kan lyde simplet, men det er det som regel ikke. En backlog er opbygget således, at man beskriver de ting man allerhelst vil have lavet først. Det er dog bedst at beskrive så lidt som muligt i backloggen, så udviklingsteamet stiller spørgsmål til Product Owner. Somme tider er det nemmest at diskutere mundtligt, hvordan issues i backloggen skal forstås.

 

Daily Scrum
Som følge af kommunikationen mellem Product Owneren og udviklingsteamet, bliver parterne enige om hvilke opgaver der skal løses først. Det vil sige, at der oprettes et sprint med opgaver, som udviklingsteamet arbejder på mellem 14 dage og en måned, alt efter hvad estimeringen af opgaverne lyder på.

Udviklingsprocessen styres af en Scrum-Master som holder styr på, om de enkelte opgaver under sprintet følger tidslinjen. Scrum-Masteren fungerer derfor som projektleder der holder styr på, hvornår nye sprints er klar til at blive gennemført, og hvornår udviklingsteamet har et fysisk produkt, de kan sende til test. 
Et af de vigtigste elementer under udviklingsprocessen, er de daglige Scrum møder, også kaldet Daily Scrum. Her mødes udviklingsteamet og Scrum-Masteren, hvor de bl.a. diskutere, hvorvidt der er faktorer som gør, at udviklerne sidder fast i udviklingsprocessen. Hvis dette er tilfældet, er det Scrum-Masterens opgave at gøre således, at udviklerne kan fortsætte deres arbejde.

 

Brugertests
Ved afslutning af hvert sprint, har udviklingsteamet som oftest et Potentially Shippable Product. Det vil sige, at efter hvert sprint har man et produkt man kan ’røre’ ved, og som man kan bygge videre på i efterfølgende sprints. Fordelen ved at have et fysisk produkt er, at man faktisk kan trykke på ’go’-knappen hvis det er det man ønsker. Men i stedet vil man typisk sende produktet til test hos de faktiske brugere af det kommende produkt. 

Her vil brugerne komme med feedback til, hvordan de oplever produktet. Både med henblik på produktets visuelle stil, men også dets funktioner. Det store spørgsmål er nu, om produktet lever op til brugernes forventninger og behov. 
Product Owneren modtager brugernes feedback, og han vurderer igen, hvor mange timer og penge man vil udvikle for evt. nye tiltag. Hvis dette er tilfældet, begynder samme proces igen.

Testningen er primært for, at vi som udviklingshus undervejs bliver klogere på, hvordan et nyt softwareprodukt skal udformes. Det kan ske, at brugernes behov har ændret sig siden Product Owneren og kunden skrev den første backlog - eller at der i mellemtiden er kommet andre krav til produktet udefra, fx ny lovgivning.

 

Retrospektive
En vigtig ting når vi arbejder agilt, handler om at være retrospektiv. Det er den proces, der er skitseret i form af den nederste cirkel i Scrum-modellen.  

 I retrospektive-stadiet er det vigtigt at Product Owner, Scrum-Masteren og udviklingsteamet får diskuteret, hvad der rent procesmæssigt gik godt, og hvad der gik mindre godt.
Oftest besvares spørgsmål som: Hvad kan vi konkret gøre for at forbedre processen? Og hvordan kan vi sikre at det der gik godt, kommer til at gå godt igen?

Opsummering
Det samlede resultat af Scrum-proces er et softwareprodukt, der er tilpasset brugernes behov. Scrum-processen sikrer en løbende udvikling af produktet, både teknisk og visuelt, desto klogere vi som udviklingshus bliver på brugernes og kundens forventninger til softwareproduktets kunnen. Samtidig sikrer processen en tæt kommunikation mellem brugere, Product Owner og udviklingsteam, så der ingen misforståelse er omkring, hvordan softwareproduktet skal udvikles.