Alle snakker om "Agile Delivery", og du vil ha en rask oversikt, noen eksempler og beste praksis? Du finner det du leter etter i denne artikkelen.
Agile-levering 1x1: Oversikt, beste praksis og eksempler
Hva er Agile-levering?
Agile Delivery er en metode for å levere verdi til kunder og interessenter ved hjelp av smidige prinsipper og praksiser.
Agile Delivery er basert på ideen om iterativ levering, det vil si at vi presenterer ulike trinn av produktet eller tjenesten tidlig og ofte, og lærer av tilbakemeldinger og data fra kundene for å forbedre og tilpasse oss.
Agile Delivery er ikke det samme som "fossefall", en tradisjonell måte å skape verdi på, der planlegging, design, utvikling, testing osv. planlegges på forhånd og deretter gjennomføres etter hverandre.
Du hører ofte at et smidig team har en enorm "backlog" eller oppgavebacklog som vil dominere de neste månedene. Og dette omtales ofte som "Agile Waterfall Delivery". Jeg vil imidlertid presisere at det ikke finnes noe slikt som "Agile Waterfall Delivery". Og når noen hevder å bruke det, blander de sammen noe som ikke hører sammen.
Agile Grunnleggende om levering
Det er tre hovedprinsipper for Agile Delivery som du må forstå og anvende:
- Lever arbeidsoppgaver tidlig og ofte: Sørg for at alle forstår at verdi først skapes når kunden har noe nyttig i hendene. Alt som skjer før det, medfører kostnader og skaper ikke verdi. Uansett hva du jobber med, er det ikke "ferdig" før kunden faktisk kan bruke det. Derfor bør teamene først begynne med nytt arbeid når det eksisterende arbeidet deres blir brukt av kundene.
- Få rask og direkte tilbakemelding fra kundene: Når teamene leverer arbeidsinkrementer tidlig og ofte, kan de samle inn tilbakemeldinger fra ekte kunder og handle på bakgrunn av disse. Dette fungerer bare hvis du har en struktur som gjør det mulig for deg og teamet ditt å få tilbakemeldinger fra virkelige brukere på et tidlig tidspunkt. Vanlig fallgruve: Ikke la ledere fungere som stedfortredere for tilbakemeldinger fra brukerne. Gjør det klart for lederne at de kanskje eier definisjonen av "forretningsverdi", men ikke definisjonen av "kundeverdi". – dette tilhører kundene og bør utforskes direkte av produkteieren og teamene.
- Tverrfunksjonelle team: Hvis teamet ditt må snakke med 10 andre team for å levere noe til en kunde, vil ikke smidig utvikling fungere for deg (ennå). Sørg for å ha team som kan ta eierskap til hele prosessen, ta selvstendige beslutninger og snakke med kundene.
Agile-levering 1x1: Oversikt, beste praksis og eksempler
Agile Leveringseksempler – 2 Agile Organisasjonsmodeller
Det finnes mange ulike agile organisasjonsmodeller som kan hjelpe deg med å implementere agile i din kontekst. Her er to eksempler på populære modeller du kan lære av:
- Scrum: Dette er et smidig rammeverk som hjelper team med å skape verdi iterativt og inkrementelt.
- Scrum definerer tre roller: Scrum Master, produkteier og utviklingsteam.
- Den definerer også fire hendelser: Sprint Planning, Daily Scrum, Sprint Review og Sprint Retrospectives.
- Den definerer tre artefakter: Product Backlog, Sprint Backlog og Increment.
Scrum egner seg godt for små til mellomstore team eller prosjekter som har klare og stabile krav og leveranser.
- Spotify-modellen: Spotify-modellen er en smidig organisasjonsmodell som er utviklet av musikkstrømmeselskapet Spotify.
Spotify-modellen deler teamene inn i Squads, Chapters, Tribes og Guilds.- En squad er et lite tverrfunksjonelt team som leverer en bestemt funksjon eller et bestemt produkt.
- Et chapter er en gruppe mennesker som har lignende ferdigheter eller oppgaver, for eksempel utviklere, testere, designere osv.
- En tribe er en gruppe grupper som jobber med et beslektet område eller domene.
- Et laug er et interessefellesskap som strekker seg gjennom hele organisasjonen.
Spotify-modellen egner seg godt for store organisasjoner eller programmer med komplekse og dynamiske krav og resultater.
Deretter vil jeg trekke frem en klassisk ledelsesmetode som også spiller en viktig rolle i agile sammenhenger: Én-til-én-møter.
Som det fremgår av diagrammet nedenfor, anses de som svært viktige av de ansatte.
Beste praksis: én-til-én-møter med utviklere
Å lede programvareutviklere i regelmessige en-til-en-møter er helt sentralt for Agile Delivery Leads. De er kanskje de viktigste møtene dine. Tar du dem på alvor
Jeg vil gjerne benytte anledningen til å gjøre deg oppmerksom på vår gratis programvare for en-til-en-møter, som er spesielt utviklet for smidige team. Gjør 1:1-møtene dine spennende, mål trender og, fremfor alt, gjør fremskritt i utviklingen av medarbeiderne dine!
Prøv en av malene våre, se nedenfor. Følgende mal er en standardmal for for eksempel én-til-én-møter hver 14. dag. Den inneholder også en målbar "stemningssjekk" til slutt, som du selvfølgelig kan tilpasse:
👋 Velkommen og isbryter
- Hvordan er været i prosjektet/oppgavene dine for øyeblikket?
📕 Temaer Ansatt [navn]
- ...
👈 Lederskapstemaer
- Hva gikk bra?
- Utfordringer?
- Neste prioritering?
⁉️ Mood check (spørreundersøkelse)
Agile-levering 1x1: Oversikt, beste praksis og eksempler
Agile Levering – De beste fremgangsmåtene
For å lykkes med smidig distribusjon må du følge noen beste fremgangsmåter som hjelper deg med å optimalisere distribusjonsprosessen og resultatene. Her er noen av dem:
- Lede selvorganiserte og selvstendige team: Som Agile-leder eller -sjef må du gi teamene dine mulighet til å ta beslutninger, ta ansvar og stå for det de gjør. Du må stole på at de gjør sitt beste uten å være nedlatende eller pålegge dem unødvendige regler eller begrensninger. Du må også støtte dem ved å gi dem de ressursene, verktøyene, tilbakemeldingene og anerkjennelsen de trenger.
- Ha direkte kundekontakt: Som medlem av et smidig team eller som produkteier må du ha direkte og hyppig kontakt med kundene dine. Du må forstå deres behov, forventninger og preferanser og levere verdi som oppfyller eller overgår disse. Du må også innhente tilbakemeldinger fra kundene om produktet eller tjenesten og bruke disse til å forbedre og tilpasse tilbudet.
- Tenk på hver ny funksjon som et eksperiment som du kan lære av: Som medlem av et smidig team eller som produkteier må du se på hver ny funksjon eller hvert nytt krav som et eksperiment for å teste dine antakelser og hypoteser om hva kundene ønsker eller trenger. Du må planlegge eksperimentene nøye, måle resultatene objektivt og lære av dataene og tilbakemeldingene. Du må også være forberedt på å tenke nytt eller gå videre basert på resultatene.
Det er alt du trenger for å få en oversikt. Jeg håper denne artikkelen hjelper deg med å forstå mer om smidig levering, dens grunnlag, eksempler og beste praksis. Gi meg gjerne beskjed hvis du har spørsmål eller tilbakemeldinger 😊.
"Hvorfor tar det meg noen ganger flere timer å forberede et enkelt tilbakeblikk?"
