– PÅ ÈN TIME
I løpet av de siste ti årene har agile verdier og prinsipper stadig fått større innvirkning på programvareutvikling. I Norden er normen blitt å bruke agile prinsipper, og det er kun få bedrifter som bare bruker den klassiske fossefallmodell.
Vi ser likevel at det finnes mange forskjellige måter å implementere «agile» på, og mange bedrifter ser seg selv som agile selv om arbeidsmetodene deres ikke følger alle de agile prinsippene.
Implementering av nye arbeidsmetoder i en organisasjon kan være utfordrende, men i Right People Group har vi erfart, basert på samtaler med hundrevis av kunder gjennom de siste ti årene, at overgangen til agile prinsipper ofte blir en suksess. Det blir da en suksess både fra et ledelsesperspektiv og fra programvareutviklernes perspektiv. Implementeringen fører til mer tilfredse medarbeidere og en mer effektiv programvareutvikling.
Denne videoen gir deg en beskrivelse av agile prinsipper og tankene bak agile programvareutvikling:
SCRUM – DEN MEST BRUKTE AGILE METODEN
Scrum er en av metodene som er basert på agile prinsipper. Det er den mest utbredte metoden innen agile prosesser. Vår erfaring, basert på samtaler med våre kunder, er at valget av en dyktig product owner er avgjørende for at det agile prosjektet skal bli en suksess.
Nøkkelroller og konsepter fra Scrum, som er nyttige å kjenne til er:
- Product Owner
- Scrum Master
- Sprint / Sprint planning
- Daily Scrum
- Retrospective
- Sprint backlog / user stories
- Product backlog
Du kan få en oversikt over definisjonene her og videoen under vil gi deg en introduksjon til Scrum:
INTRODUKSJON TIL KANBAN
De fleste organisasjonene starter med Scrum også fortsetter noen av dem med å implementere Kanban. Kanban er et meget populært rammeverk innen agile programvareutvikling. Alle de forskjellige oppgavene som ulike teammedlemmer jobber med blir visualisert på en Kanban-tavle, som gir hele teamet mulighet til å følge utviklingen av prosjektet hele veien. Vår generelle erfaring fra kundene våre er at denne tilgangen er nyttig og optimaliserer prosjektet. Mange av de beste selvstendige konsulentene, som jobber som agile coaches, anbefaler denne metoden.
Kanban blir introdusert og sammenlignet med Scrum i denne artikkelen og i videoen under:
MINIMUM VIABLE PRODUCT
Minimum Viable Product (MVP) ble populært da Eric Ries ga ut boken «The Lean start-up» i 2008. Hovedkonseptet i MVP passer godt inn i filosofien bak agile programvareutvikling. Denne filosofien er blitt veldig populær de siste årene – særlig blant tech start-ups.
Vi ser dyktige start-ups som følger denne filosofien truer mange av de kjernekompetansene som tidligere var i sikre hender hos enterprise virksomheter, eksempelvis innen finans sektoren. De kan gjennom MVP-tilnærmingen levere nye løsninger til markedet svært kjapt. I frykt for denne trusselen adopterer også enterprise virksomhetene denne filosofien for å forbli konkurransedyktige.
Videoen under gir en god introduksjon til MVP og illustrerer filosofien med tre eksempler:
”TECHNICAL DEBT”
I vår første video så vi hvordan utvikleren valgte å kun utvikle den delen av databasen som var nødvendig for å levere den relevante funksjonaliteten. I visse situasjoner kan en slik beslutning være riktig, særlig fra et MVP-perspektiv, men da er det også en risiko for at en ender opp med mange uferdige og uhensiktsmessige deler i den helhetlige systemarkitekturen. Dette må man betale for i fremtiden, som en slags teknisk gjeld eller bare «technical debt».
Technidal debt er et konsept som ble introdusert av en av Agile Manifest forfatterne, Ward Cunningham. Dersom man ønsker å få et produkt raskt på markedet, kan det som nevnt være nødvendig å ta snarveier. Man må likevel være klar over at man da, som metaforen beskriver, må betale tilbake gjelden før eller siden. Den raskeste løsningen er nemlig sjeldent den beste.
Dersom det ikke er noen grunn til å snarveier og den raskeste løsningen ikke er implementert for å oppnå forretningsmessigverdi, men fordi teamet ikke er ambisiøst eller dyktig nok, så har «technical debt» ikke noe med agile metoder og forretningsforståelse å gjøre. Da er det rett og slett dårlig arbeid!
Vår erfaring er at den største årsaken til «technical debt» er lite dyktige programvareutviklere som ikke fokuserer på kvalitet. Vi har også sett at «rentene» som man betaler ned på «technical debt» kan bli svært store. Større og større «technical debt» gjør det vanskeligere å oppdatere programvaren, som i vår tid er drepende for produktet, da en statisk programvareløsning ikke kan overleve.
Her kan du se en introduksjon til «technical debt»:
HVA AGILE PROGRAMVAREUTVIKLING IKKE ER
I det agile manifestet, er det ting som blir prioritert over andre. Det betyr likevel ikke at de nedprioriterte tingene ikke er viktige eller strider mot den agile filosofien. Eksempelvis hevder noen programvareutviklere at deres programvareløsning ikke trenger å dokumenteres og at en slik dokumentasjon strider imot agile prinsipper. Det stemmer ikke.
Denne korte artikkelen forklarer godt hvordan det agile manifestet skal forstås:
https://www.linkedin.com/pulse/what-agile-isnt-patrick-becka
SAFE – SCALED AGILE FRAMEWORK
Det er utfordrende å oppnå suksess med programvareutviklingsprosjekter og det er SVÆRT utfordrende å oppnå suksess med de mer komplekse prosjektene. I takt med at flere store organisasjoner og enterprise virksomheter har begynt å følge den agile filosofien er det behov for en metode for hvordan man skal utføre de svært store og komplekse prosjektene, som vi ser i denne typen organisasjoner.
«SAFE» er den mest brukte agile metoden for store og komplekse prosjekter:
HVORFOR AGILE FEILER
Slik som alle andre former for organisatoriske prosesser har introduksjonen av agile prinsipper en risiko for å feile. Vår erfaring viser at programvareutviklere generelt er ivrige etter å bruke agile prinsipper i programvareutvikling, men da må ledelsen være villig til å gi slipp på visse kontrollmekanismer. Det krever også at den forretningsmessige delen av organisasjonen stadig må involveres. Dette betyr i praksis at de er nødt til å allokere tid til det.
Typen her (og hans t-skjorte) sier det godt:
DERSOM HITLER VAR EN AGILE COACH:
I programvareverdenen vil mange kategorisere en «agile coach» som litt av en «hippietype». Men hva om du lagde et tankeeksperiment og forestilte deg at Hitler var en agile coach:
Hva er Right People Group University
Om Right People University
ER DU SELVSTENDIG KONSULENT ELLER AGILE EKSPERT?
Meld deg opp til vårt prosjekt-nyhetsbrev og få tilsendt selvstendige konsulentoppgaver via e-post innenfor de kompetanseområder og regioner som er relevante for deg.
MANGLER DU EN AGILE EKSPERT?
Send en mail til [email protected] for en CV og timepris på en agile ekspert, som matcher dine behov. Du kan lese mer om våre tjenester og typer agile eksperter vi kan levere her: Agile utvikling eller Agile prosjektleder.
