Unngå disse 4 Agile-fellene: Tips for nybegynnere

Lær de 4 beste nybegynnerfeilene innen Agile som du bør unngå. Basert på over 10 års erfaring.

Agile er den mest effektive måten å bygge innovasjon på

Sammenlignet med andre tilnærminger, inkludert dens direkte motsetning, Waterfall, lar Agile deg minimere tiden brukt på formaliteter og forberede full prosjekt dokumentasjon (før prosjektets faktiske start, som er en svært tidkrevende og kostbar prosess i seg selv); og maksimerer ressursene brukt på faktisk arbeid.

En enkel veikart blir laget, med fokus på kjernemulighetene til applikasjonen. Fordi du utvikler en klar visjon og ryggraden til produktet, så å si, kan de mindre oppgavene tilnærmes med fleksibilitet og gis en annen (skiftende) prioritet.

Fordelene med Agile har blitt mye rost og dokumentert, så du kjenner dem sannsynligvis allerede. Det øker kundetilfredsheten, brukernes lojalitet, det lar deg bygge håndgripelig verdi med produktet ditt, og reduserer risikoen for feil takket være raskere iterasjoner og reaksjoner på endringer i bransjens miljø.

Raskere iterasjoner betyr beredskap for uventede endringer som kan oppstå.

Så du definerer stort sett hva du skal gjøre etter hvert som du går, i stedet for å planlegge i flere måneder, og prøve å forberede deg på ting du egentlig ikke kan forberede deg på (kriser, de nevnte markedsendringene, direkte konkurrenter som oppdaterer sitt verdiforslag, eller stort sett alt annet som er umulig å forutsi i begynnelsen av prosjektet).

Men... Agile er ikke en mirakelkur for alle dine produktutviklingsproblemer

Hvis du oppfatter det slik, kan det hende du nettopp har falt i den første fellen og vanlige misoppfatninger bygget på hypen.

Agile har sine verdier og prinsipper, som, når de ikke følges, kan gjøre produktet til et fiasko, eller i det minste, betydelig hindre utviklingsprosessen.

Hos EL Passion har vi jobbet med Agile i over 10 år, og her er mine tanker om hva du bør forberede deg på for å unngå Agile-nybegynnerfeil, som er veldig enkle å gjøre for nykommere, men også veldig enkle å eliminere når du faktisk vet hva du gir deg inn på.

Felle 1: Når Produktansvarlig ikke har tid til å være Produktansvarlig

En Produktansvarlig (PO) er den viktigste beslutningstakeren i prosessen, ansvarlig for å spre produktvisjonen til utviklingsteamet, maksimere verdien av funksjonene som skal utvikles, og prioritere oppgavene i backloggen for å oppnå en balanse mellom forretnings- og sluttbrukerfordeler.

På en måte som en kaptein på et skip, leder han/hun, eller rettere sagt: veileder mannskapet, slik at de holder seg på rett kurs. Det er ganske åpenbart at hvis kapteinen ikke har tid til å kommandere skipet, kan ting gå fryktelig galt.

Ja, selvorganiserte team kan jobbe noe uavhengig, men prioriteringene må settes, og noen må ha det siste ordet og bestemme hva som skal være med og hva som skal bort.

Grunnlaget for et vellykket digitalt produkt er et team som forstår visjonen.

Mangelen på PO-ens tilstedeværelse i prosjektet kommer med en kostbar risiko. Teamet har ingen tilknytning til produktets visjon eller sluttbrukerens perspektiv, og kan bruke tid på å bygge funksjoner som er mindre viktige for kunden eller designe dem annerledes enn hva kunden hadde forestilt seg.

Begge scenarier er, kort sagt, ikke bare bortkastet tid for alle, men en veldig smertefull bortkastelse av budsjettet.

Løsningen er, som alltid, enkel i teorien og mye vanskeligere å sette ut i praksis (spesielt for folk som ikke er vant til å jobbe i Agile-miljøer). PO-en må sørge for at han/hun kan dedikere omtrent 1–2 timer om dagen til prosjektet (det kan være litt mer i løpet av den første uken etter prosjektstart).

Felle 2: Ikke å forstå hva du betaler for i Time & Materials-kontrakt

Det er en veldig vanlig misforståelse at når man jobber med et programvareutviklingsselskap, betaler man for funksjonalitetene som skal leveres. Men dette er ikke sant i et Agile-miljø, og vanligvis følger det en Time & Materials-kontrakt.

Kjernen i Time & Materials-kontrakten er at du betaler for tiden til det ansette teamet, akkurat som når du ansetter folk internt. Funksjonalitetene de lager er selvfølgelig et håndgripelig resultat av arbeidet deres, og du kan se dem i sanntid etter hvert som arbeidet skrider frem. Men likevel, du blir fakturert for timene, ikke for sluttresultatet.

Denne misforståelsen fører noen ganger til alvorlige misforståelser og i ekstreme tilfeller kan det sette prosjektet i fare.

Løsning: vær klar over hva du egentlig betaler for, og at i alle tilfeller du trenger mer tid fra teamet, vil det være fakturerbar tid, selv om det betyr å jobbe med funksjoner som allerede er ferdige. Du kan også reservere en liten buffer av budsjettet ditt for ferdige oppgaver for små fikser og forbedringer. Hvis du har forventninger til noen former for garantier, vær sikker på å snakke med partneren din så snart som mulig, ideelt sett før samarbeidet starter, da det kan kreve en helt annen oppsett.

En Time and Materials-kontrakt er faktisk den mest effektive måten å måle fremdriften jevnt.

Felle 3: forsinkelse av utgivelsen av applikasjonen

Kontinuerlig levering ligger i hjertet av den Agile tilnærmingen. Du ønsker å lansere appen din på markedet så snart som mulig, selv med et begrenset antall funksjoner, selv i en ufullkommen form, slik at du kan ha et godt grunnlag å bygge videre på, men med appen allerede ute der.

La oss si at produktideen din er omfattende, og utviklingen av hele omfanget vil ta rundt 10 måneder. Den agile tilnærmingen ville være å dele arbeidet opp i mindre biter, prioritere funksjonene og lansere appen tidligere enn senere.

Hvorfor? Med appen din allerede på markedet får du tilgang til tilbakemeldinger fra ekte brukere uten behov for brukertesting, og du kan navigere videre utvikling basert på den tilbakemeldingen. På forretningssiden kan du begynne å bygge din konkurransefordel tidligere, og selvfølgelig begynner du å kapitalisere investeringen din tidligere. En ting å huske på:

Programvareutvikling er ikke en ferdig prosess. Det er snarere en kontinuerlig forbedring av det som allerede er gjort.

Den direkte risikoen ved å glemme “MVP tankesettet” er å forlenge og forsinke den opprinnelige utgivelsen av appen og brenne budsjettet for å polere alt til perfeksjon. Virkeligheten av å jobbe med digitale produkter har lært meg og minnet meg mange ganger om at du ikke kan lære å svømme på kald hard grunn. Du må bare hoppe.

Løsning? Ikke overkompliser den allerede kompliserte prosessen.

Velg en enkel løsning og bygg deretter videre på den. Hold tankesettet og disiplinen for å lansere applikasjonen så snart som mulig, selv om det betyr noen kompromisser. Din programvareutviklingspartner er der for å gi deg råd om den beste teknologien, med alle fordeler og ulemper ved videre utvikling og utvidelse i henhold til forretningsplanen din.

Som Pamela Zave sier: “Formålet med programvareingeniørfag er å kontrollere kompleksitet, ikke å skape den.”

Felle 4: Å stole på den innledende estimatet, mens omfanget endres betydelig 🤔

Den innledende estimatet er utarbeidet for å gi deg en grov idé om hvor mye tid og penger som trengs for å fullføre prosjektet.

Den er basert på forståelsen av omfanget av arbeidet som må gjøres før prosjektet starter. Hos EL Passion skjer dette ofte etter en Produktdesign Workshop. Men dette omfanget av arbeid kan igjen endres under den faktiske utviklingen.
Nye funksjoner kan bli forespurt, omfanget av de opprinnelig diskuterende vil bli spesifisert eller endret, noen funksjoner vil bli droppet eller omprioritert. Alt dette påvirker tiden og budsjettet.

Du må huske at endring av omfanget kan bety to ting. Enten vil sluttprisen og prosjektets sluttdato endres, eller så må du krysse ut noen av elementene i den innledende estimatet før budsjettet går tomt.

Nøkkelen her er bevissthet og forståelse av at enhver endring i prosjektet, ganske naturlig, påvirker den totale utviklingstiden og prisen.

Og løsningen: etter hvert som prosjektet skrider frem og endres, bør du stole mindre og mindre på den opprinnelige estimatet — det er mye bedre å flytte tankegangen din til de pågående projeksjonene basert på teamets hastighet og gjenværende planlagt arbeid. Hver gang du tenker på en endring — snakk med utviklingsteamet ditt om hvordan du skal tilnærme deg den nødvendige endringen, slik at dere er på samme side når det gjelder effektene det medfører.

Fellen er ikke Agile i seg selv, men misbruk av Agile

Agile har revolusjonert måten vi produserer programvare på. Det har blitt rost, og resultatene er dokumentert av de største i bransjen. Det fungerer, og det kan også gjøre underverker for produktet ditt. Men bare hvis det brukes helhjertet og bevisst, med respekt for verdiene og prinsippene.

Fellene jeg nevnte er vanlige for de såkalte Agile nykommerne, drevet av hypen, men ofte ikke godt nok informert.

Men nå som du kjenner dem, hva er det som kan stoppe deg?

Sjekk også ut

1. Vanlige feil å unngå når du utvikler appen din for å se hva du bør og ikke bør gjøre når du utvikler appen din
2. Når du skal ansette et byrå for programvareutviklingen din noen spørsmål å stille deg selv når du er usikker på om IT-outsourcing er veien å gå