En av hovedgrunnene til at Scrum er så populært og robust er nok enkelheten. Rammeverket inneholder veldig få, men ganske rigide regler. Innenfor de gitte rammene er det – for mange – overraskende stor frihetsgrad. Scrum beskriver ikke hvordan du skal gjøre jobben, men gir noen rammer og sørger for at man ved jevne mellomrom stopper opp, reflekterer og gjør små tilpasninger og forbedringer. Dette kalles empirisk prosesskontroll, som da er motsatsen til definert prosesskontroll.
Scrum er designet for å løse komplekse problemer der det er for stor usikkerhet til at det er fornuftig å låse seg til et omfang. Man vil oppdage nye krav og behov mens man gjør jobben og stadig lære av erfaring tett sammen med brukerne. Vi opplever stadig at folk tror / mener at dette rammeverket er begrensende og mangelfullt. I de fleste tilfeller (men ikke alle) beror dette på misoppfattelser om hvordan man skal bruke Scrum.
Noen eksempler på vanlige misforståelser:
«Du kan bare levere en gang per Sprint»
Nei, det er ingen ting i Scrum som hindrer et team i å deploye mange ganger underveis i Sprinten. Når man da kommer til Sprint review vil teamet demonstrere summen at alt som er laget for å få feedback fra brukere. Her gjelder det å være forberedt på at tilbakemeldingene vil vise at enkelte ting bør korrigeres / rulles tilbake.
«Det er bare Product Owner som lager alle User Storiene»
Her er det to misforståelser. For det første er det ikke noe User Story begrep i Scrum. User Story formatet er ofte et velegnet format for Product Backlog Elementer, men andre formater kan også fungere godt. Product Owner vil ofte lage utkast til Elementene i Backlogen, som så skal diskuteres og grovestimeres sammen med utviklerne i Refinement. Ikke noe hindrer utviklere fra å lage elementer.
«Ingen retningslinjer for interaksjon med interessenter og brukere»
Korrekt (bortsett fra at teamet vil møte brukerne i Sprint Review). Det er mange ulike måter å sørge for nok og riktig form for interaksjon på, og ganske umulig for et rammeverk å lage generelle regler for dette. Dette må løses gjennom erfaring og en solid bevissthet på hva som er viktig for hvilke grupper. Direkte kontakt mellom utviklere og sluttbrukere kan fasiliteres på en mengde ulike måter. Ett eksempel er å invitere interessenter på Product Backlog Refinement. Emrpirisk prosesskontroll!
«Manglende fokus på arkitektur»
Korrekt. Dette er helt bevisst, siden det ikke her finnes noe allmen «beste praksis». Alle utviklerteam må ha tilstrekkelig arkitekturforståelse slik at man over tid gjør de nødvendige grepene for at strukturen i produktet harmonerer godt med de fremtidige ambisjonene. I større organisasjoner er det vanlig å ha jevnlige Arkitektur Reviews eller lignende for å sikre konsistens på tvers. Ingen hindre for dette i Scrum.
«Ingen designrolle»
Korrekt og helt bevisst. God brukervennlighet og design er ofte en avgjørende for suksess, men det betyr ikke at man trenger en egen rolle. Utviklerteamet må besitte gode designferdigheter og vil ofte ha en person som er «designer» av profesjon. Men vi må aldri glemme at utviklerteamet er et kollektiv som lykkes som et team der alle hjelper til der det trengs når det trengs.
Oppsummert
Det er gode grunner til at Scrum holdes nede på et minimum av regler og prosess. Det som har skjedd i rundt 20 år med utvikling er i hovedsak presiseringer og at ting er fjernet/forenklet. Eksempler på dette er «Burndown Chart» og «Velocity» som ikke lenger finnes i Scrum.
Ikke la Scrum hindre dere i å ta i bruk metoder og praksiser som er riktig i akkurat deres kontekst. Bruk retrospektivene til å eksperimentere med god praksis så vil teamet over tid fungere bedre og bedre.