HVAD ER AGILE? – PÅ ÈN TIME
I det seneste årti har agile værdier og principper haft stor indvirkning på, hvordan software er udviklet. I Norden er det blevet normen at bruge agile principper, og det er kun få virksomheder, der stadig holder sig 100% til en klassisk vandfaldsmodel.
Vi ser dog mange forskellige måder at implementere ”agile” på, og mange organisationer ser sig selv som agile, selvom deres arbejdsmetoder ikke er tilpasset 100% til de agile principper.
Implementering af nye arbejdsmetoder i en organisation kan være svære, men i Right People Group er det vores erfaring, baseret på samtaler med hundredevis af kunder gennem de sidste 10 år, at overgangen til agile principper ofte bliver en succes – både fra et ledelsesmæssigt synspunkt, men også fra softwareudviklerenes synspunkt. Når implementering er på plads, giver det automatisk mere tilfredse medarbejdere og en mere effektiv softwareudvikling.
Denne video giver dig en beskrivelse af agile principper og tankerne bag agil softwareudvikling
SCRUM – DEN MEST ANVENDTE AGILE METODE
Scrum er en metode, der er baseret på agile principper. Det er den mest udbredte metode i implementering af agile processer. Det er vores erfaring, baseret på dialog med vores kunder, at valget af en stærk product owner er afgørende for at et agilt projekt bliver en succes.
Nøgleroller og koncepter fra Scrum, der er værd at kende:
- Product Owner
- Scrum Master
- Sprint / Sprint planning
- Daily Scrum
- Retrospective
- Sprint backlog / user stories
- Product backlog
Du kan få et overblik over definitionerne her og nedenstående video vil give dig en introduktion til Scrum:
INTRODUKTION TIL KANBAN
De fleste organisationer starter med Scrum og nogle af dem implementerer efterfølgende Kanban. Kanban er et meget populært framework i agil softwareudvikling. Alle de ’lunser’ af arbejde, som forskellige medarbejdere i teamet er ansvarlige for, er visualiseret på en Kanban-tavle, der giver hele teamet muligheden for at følge udviklingen af projektet hele tiden. Vores generelle erfaring fra vores kunder er, at denne tilgang er nyttig og optimerer projektet. Mange af de bedste selvstændige konsulenter, der arbejder som agile coaches, anbefaler denne metode.
Kanban bliver introduceret og sammenlignet med Scrum i denne artikel og i nedenstående video
MINIMUM VIABLE PRODUCT
Minimum Viable Product (MVP) blev populært da Eric Ries udgav sin bog ”The Lean start-up” i 2008. Hovedkonceptet i MVP passer godt ind i filosofien bag agil softwareudvikling. Denne filosofi er blevet meget populær i de seneste år – specielt blandt tech start-ups.
Vi ser, at kerneydelser, der traditionelt har været i sikre hænder hos entreprise virksomheder, f.eks. i den finansielle sektor, trues af dygtige start-ups, der med en ”MVP”-tilgang kan bringe nye løsninger til markedet langt hurtigere. Af frygt for denne meget omtalte, men også helt reelle risiko for ‘disruption’, er også store virksomheder begyndt at arbejde med konceptet for at kunne forblive konkurrencedygtige.
Nedenstående video giver en god introduktion til MVP, illustreret med tre eksempler:
“TECHNICAL DEBT”
I vores første video så vi, hvordan udvikleren valgte kun at udvikle de dele af databasen, der var nødvendige for at levere den relevante funktionalitet. En sådan beslutning kan alt efter kontekst være den rigtige – ikke mindst i et MVP-perspektiv – men der er også risiko for at ende med mange ufærdige og uhensigtsmæssige dele i den overordnede systemarkitektur, som man kommer til at ’betale for’ fremadrettet, som en slags ’teknisk gæld’ eller ’technical debt’.
Technical debt er et koncept, der blev introduceret af en af forfatterne til det Agile Manifest, Ward Cunningham. Som sagt kan det give mening at tage genveje i forbindelse eksempelvis for at få et produkt på markedet hurtigt, men som metaforen beskriver, skal man være bevidst om at der er gæld at betale før eller siden, fordi den hurtigste løsning sjældent vil være den mest optimale løsning på sigt.
Hvis der ikke er nogen grund til at tage en genvej og den hurtige løsning ikke er implementeret for at opnå forretningsværdi, men blot fordi teamet ikke er ambitiøse eller dygtige nok, så har technical dept ikke noget at gøre med agile metoder og forretningsforståelse – så er det blot dårligt arbejde!
Ifølge vores erfaring er softwareudviklere, der ikke er dygtige nok og fokuseret på kvalitet, den største årsag til technical debt. Vi ser også de ’renter’, der betales for technical debt er høje. Stigende technical debt gør det svært at opdatere software, hvilket i vores tid er dræbende for produktet, da en statisk softwareløsning ikke kan overleve.
Her kan du se en introduktion til ’technical debt’:
HVAD AGIL SOFTWAREUDVIKLING IKKE ER
I det agile manifest er der ting, der bliver prioriteret over andre. Det betyder ikke, at de nedprioriterede ting ikke er vigtige og i modstrid med en agile tilgang. Som eksempel hævder nogle softwareudviklere, at deres softwareløsninger ikke skal dokumenteres, og at den slags dokumentation går imod de agile principperne. Det er ikke korrekt. Denne korte artikel beskriver godt, hvordan det agile manifest skal forstås.
SAFE – SCALED AGILE FRAMEWORK
Det er svært at få succes med softwareudviklingsprojekter og det er RIGTIG svært at få succes med de mere komplekse projekter. I takt med, at flere store organisation og enterprise virksomheder er begyndt at følge et agilt mindset, er der behov for at have en metode til at udføre de meget store og komplekse projekter, som vi ser i denne type organsationer.
”SAFE” er det mest brugte agile metodologi ved store og komplekse projekter:
HVORFOR AGILE FEJLER
Ligesom med enhver anden form for organisatoriske processer, har introduktionen af agile principper en risiko for at fejle. I vores erfaring er softwareudviklere generelt ivrige efter at benytte agil principper i softwareudvikling, men det kræver at ledelsen er villige til at slippe visse kontrolmekanismer, som de er vant til at bruge. Det kræver også en vedvarende involvering af den forretningsmæssige del af organisationen, hvilket i den virkelige verden betyder, at de er nødt til at allokere tid til det.
Manden her (og hans t-shirt) siger det meget godt:
HVIS HITLER VAR EN AGIL COACH:
Mange vil opfatte en ”agile coach” som lidt af en ”hippietype” i softwareverdenen. Men hvad nu hvis du lavede et tankeeksperiment og forestillede dig, at Hitler var en agil coach:
ER DU FREELANCE KONSULENT?
Skriv dig op til vores projekt-nyhedsbrev og få tilsendt projekter inden for de kategorier og regioner, der er relevante for dig.
MANGLER DU EN AGILE EKSPERT?
Send en email til [email protected] for et CV og en timepris på en agile ekspert, der matcher dine behov. Du kan læse mere om vores ydelser og typer agile specialister, som vi kan levere her: Agil udvikling.
