Som mange klassiske, uendelige konflikter raser debatten om hvordan utviklingsteam skal organisere og selvstyre. Foreløpig virker det nesten som om det er flere kritikere enn fans av Scrum. De tre vanligste klagene er:

1. Prosessen kan være sentralt i løpet av arbeidet.
2. Det kan lett forveksles for micromanagement med et annet navn.
3. Den daglige stand-up kan føles som et møte der man må rettferdiggjøre sin eksistens.

I andre tilfeller er ikke Scrums roller representert riktig. Noen ganger vil produktseieren ha for mange ting inne i en sprint, eller ønsker å endre prioriteringer midt på sprinten - a Scrum master som er obsessivt fokusert på å opprettholde hastighet og vedta hver nye Scrum-seremoni de lærer. Etter litt tid med rammeverket ser det ut til at et vanlig spørsmål kommer opp: 'Er det oss eller metoden?'

The False Hopes of Scrum

Selv om det er mange dysfunksjoner som de som er skissert ovenfor, er en enkel grunnårsak for de fleste av dem at Scrum ikke var designet for å løse underliggende problemer i en organisasjon ved bare å følge prosessen. Unnlatelse av å gjenkjenne dette kan sette nye lag i fare nesten så snart de starter.

False Hope # 1: Scrum får lagene til å fungere raskere

Scrum bruker terminologi som høres ut for en utenforstående som om den kommer til å akselerere prosessen uten å legge til flere ressurser. Det er lett å sette seg fast i terminologien som en nytt team til Scrum (f.eks. hva er en Scrum-mester? Hva er forskjellen mellom en produkteier og en produktansvarlig? Hva er historiepoeng og hvordan tildeles de?)

Mer bekymringsfullt er at mange ser begreper som hastighet og sprint og tenker 'fart'. Imidlertid formålet med noen Agile metodikk, inkludert Scrum, er å levere et ferdig produkt. Etter hvert som teamet ditt blir mer kompetent med Scrum, vil du kunne levere ny funksjonalitet raskere. Fart er imidlertid ikke nødvendigvis det primære målet. Dette skillet skal formuleres i Scrum-teamet ditt, og også når du bygger bevissthet i selskapet ditt for å støtte Scrum-metoden.

Du selger ikke fart; du selger ferdigstillelse.

Falsk håp nr. 2: streng overholdelse av Scrum vil løse bedriftskulturproblemer

Alle har forskjellige arbeidsstiler. Noen mennesker liker møter. Andre bruker setninger som 'arbeid hardt, spill hardt.' Det er viktig å erkjenne at uansett hvilken arbeidsstil bedriften din verdsetter, aksepterer du både fordeler og ulemper. Et selskap som verdsetter møter, vil sannsynligvis slite med den daglige stand-up. Aggressive og fartsorienterte lag kommer til å ha problemer med omfanget som kryper inne i en sprint.

Noen ganger er det lett å miste det store bildet av syne, spesielt for nylig dannede lag. Det som betyr noe er å levere et ferdig produkt i stedet for å følge hver eneste bit av prosessen. I stedet for å skylde på metodikken, må du alltid se etter måter å avgrense arbeidsstilen din for å oppnå dine mål.

Falsk håp nr. 3: Kritiske bidragsytere kan sende delegatene sine til møter

Når du starter metoden, er det avgjørende at det opprinnelige teamet deltar i stedet for delegater. Hvis det er en nesten universell klage jeg ser fra utviklere, er det at Scrum-mestere og produkteiere ikke var tilgjengelige når det var nødvendig, og deres delegater ikke fikk fullmakt. Ingen liker å komme til et møte og forventer at en beslutning bare blir fortalt at personen som kan ta avgjørelsen ikke er tilgjengelig.

Delegering kan være en vanlig praksis, men i Scrum må du også styrke deltakerne.

Falsk håp nr. 4: Daglige stand-ups vil tvinge alle til å være mer fokuserte

Det daglige stand-up-møtet bør ikke bare fokuseres på det alle gjorde det siste døgnet. Det er langt viktigere å prioritere overflatebehandling av veisperringer eller nye tilnærminger for å løse et problem.

Scrum krever at visse roller, spesielt Scrum-mesteren, er påståelige, men ikke overveldende. Det er viktig for Scrum-mesteren å skape et positivt miljø som fører til ferdige produkter.

Falsk håp nr. 5: Vi vil lykkes med første forsøk

Scrum innebærer gjetning, deduktiv tenkning og feil. Folk får det sjelden rett ved første forsøk. Scrum er iterativ i alle henseender: ikke bare i hvordan du når et ferdig produkt, men også i hvordan du styrer og driver prosessen. Scrum er designet for å ha en lav inngangsbarriere for team å adoptere, men det krever også en forpliktelse til å iterere og kontinuerlig forbedre deltakelse i rammeverket.

Hvordan fikse en ødelagt prosess

Scrum er motstandsdyktig mot den sunkne kostnadssvikt. Scrums iterative natur skaper muligheter for å tilpasse eller forkaste ineffektive prosesser. Vurder noen av de følgende forslagene hvis Scrum-prosessen ikke er så effektiv som du forventet.

Avgrens forventningene dine

Enten det er å redusere tiden til markedet, lage overbevisende produkter eller hjelpe teamene å samarbeide, suksess krever engasjement og tid. For nye lag er en rimelig milepæl å oppnå om du etter hver sprint kunne introdusere fungerende, testbar kode i produksjonsmiljøet ditt.

Avanserte team kan måle suksess etter deres evne til å bygge, teste og distribuere on-demand. Er du i stand til å instrumentere og kvantifisere brukerreaksjoner på nye funksjoner? Er den bredere organisasjonen klar til å støtte endringene teamet gjør på produktet?

Gi deltakerne dine styrke

Det er viktig å veilede teammedlemmer offline når det gjelder hvordan de kan øke verdien for teamet. Hvis de blir bedt om å ta avgjørelser, kan du øke tilliten deres ved å coaching dem om når og hvordan de skal inkludere andre teammedlemmer. Ledere må være klare til å fjerne sperringer og støtte teamet når det trengs.

Løs problemer

Scrum er ikke designet for å gi din bedrift en makeover. Hvis du har latt problemer ikke adresseres, vil du mer enn sannsynlig finne disse problemene i produktutviklingsprosessen. Scrum-mestere kan introdusere rammer designet for å skape en positiv måte for teammedlemmer å strukturere tilbakemeldinger for å redusere følelsen av konflikt.

Et slikt eksempel er rammen 'Jeg ønsker, jeg lurer på, hva om'. Under teamdiskusjoner eller tilbakeblikk , kan et teammedlem gi tilbakemelding ved å åpne uttalelsen med en av disse tre setningene. For eksempel kan de si: 'Jeg skulle ønske at stand-up-møter kunne sette mer fokus på veisperringer jeg måtte trenge å være klar over den dagen.' Du kan også bruke din egen åpner som 'Jeg liker ...'.

En annen strukturert tilbakemeldingsløsning som kan være nyttig under møter er Triage-metoden fra Holocracy, laget av Brian Robertson og brukt av selskaper som Zappos. For eksempel bygger deltakerne en agenda med 'spenninger' for å diskutere. Hver deltaker beskriver problemet sitt ved å si 'Jeg har en spenning' og lister deretter opp menneskene og ressursene de trenger for å løse det. Ved å oppmuntre deltakerne til direkte å ta opp spørsmål som 'spenninger', gjør Holokrati deltakerne i stand til å kommunisere fritt uten å skape en atmosfære av konflikt.

Bruk retrospektiver for å løse problemer og gjenta prosessen

I mange selskaper gis ikke tilbakeblikket ordentlig oppmerksomhet. Dette er først og fremst på grunn av frykten mange har for at retrospektivet er et sted for gamle argumenter, konflikter og klager. Det er viktig for teamet å utvikle grunnregler som gjenspeiler teamets verdier og selskapskultur.

Like viktig er behovet for å unngå å investere i statiske prosesser. Det som fungerte en gang, fungerer kanskje ikke for alltid. Mange lag sliter med deltakeromsetningen. Dette er vanlig i mange selskaper, ettersom deltakerne overføres til andre lag, blir forfremmet eller forlater selskapet helt. Når teamets sammensetning utvikler seg, er det viktig å ikke være forpliktet til at alt er iterativt i Scrum. Feil vil oppstå, men forhåpentligvis vil de være kortvarige når du gjentar det.

Scrum fungerer best når rektorene er til stede

Å være på laget må du forplikte deg til å være til stede og tilgjengelig. Produktutvikling er sannsynligvis den mest avgjørende prosessen din bedrift kan gjennomføre for å forbedre den langsiktige veksten. Derfor er det viktig at Scrum-prosessen, som den primære veien til utvikling av nye produkter, får den oppmerksomheten den fortjener. I mange miljøer jobber utviklerteamet ofte løsrevet fra beslutningene og diskusjonene som driver selskapets mål. Scrum er annerledes. Scrum er der beslutninger, retning og utvikling kommer sammen som en enkelt prosess. Det er for viktig av en prosess å sende delegater eller å utelate teammedlemmer fra møtene som foregår innenfor Scrum-metoden.

Sammendrag: Du kan fikse en ødelagt prosess

På grunn av sin iterative natur, hjelper Scrum til å beskytte virksomheten fra å komme for langt nedover veien og forpliktet til det som kan ende opp med å bli en dårlig idé eller dårlig implementert prosess. Å følge dette prinsippet kan hjelpe deg med å slappe av fra tidligere feil og forbedre it-prosessen.

Det er viktig å fokusere på individene og teamet du har. Teammedlemmer endres. Alle prosjekter er forskjellige. En streng overholdelse av en prosess gir ikke alltid de beste resultatene. Det du investerer i teammedlemmene dine utenfor prosessen er like viktig som hvordan du oppfører deg i prosessen.

Scrum kan være fleksibelt. Hvis noe ikke fungerer, bør du vurdere å innlemme elementer fra andre rammer både innenfor Agile og utenfor. Identifiser og vedta strukturerte kommunikasjonsstiler som konfronterer diskusjoner.

Scrum er gunstig for langsiktig avkastning ved å la teamene bygge komplette produkter som svar på skiftende kundebehov. Scrum er sannsynligvis den beste metoden for å forhindre at du overforplikter deg til dårlige ideer mens du gir gode ideer litt plass til å utvikle deg videre.

Forstå det grunnleggende

Hva er Scrum i enkle termer?

Scrum er et rammeverk for produktutvikling. Teamene frigjør produktforbedringer annenhver uke og oppsøker tilbakemeldinger fra kunder. Denne tilnærmingen minimerer sløsing og skaper muligheter for kunder å gi tilbakemelding tidlig.

Hvordan fungerer Scrum-metoden?

Et Scrum-team leverer trinn i fungerende produkt i to-ukers sprints. Hver sprint har en planleggingsøkt, der teamet bestemmer hvor mye arbeid det skal kunne gjøre på to uker. En produkteier prioriterer arbeid basert på bruker- og markedsundersøkelser.

Hvorfor bruker vi Scrum?

Scrum brukes som et alternativ til Waterfall-utvikling, der en klient bare grensesnitt med et produkt på slutten av utviklingssyklusen. I Scrum tester klienten kontinuerlig nye produktsteg og gir tilbakemelding til utviklingsteamet. Denne tilnærmingen minimerer avfall og maksimerer klientverdien.

Hva er forskjellen mellom Agile og Scrum?

Scrum er et rammeverk innen Agile metodikk. Agile skisserer hovedprinsippene for hvordan programvare skal utvikles. Scrum tilbyr et konkret system for hvordan Agile-prinsipper skal implementeres.