Det verserer mye rykter, myter og rare forestillinger om Scrum. Dette er sikkert naturlig, siden Scrum er så utbredt. Scrum var tidlig ute og har vært en formidabel suksess i snart 30 år. Selve rammeverket har ikke endret seg mye, men enkelte ting i Scrumguiden (https://scrumguides.org/) er endret basert på erfaringer og nødvendige tilpasninger. Endringene har dels vært presiseringer og dels at man har fjernet elementer som har vist seg å være “unødvendige” for å lykkes (eksempelvis burndown chart og velocity). Poenget er at selve rammeverket skal være så enkelt som mulig – intentionally incomplete – og dermed mulig å applisere i svært ulike kontekster.
Scrum teamet består av en Product Owner, en Scrum Master og en rekke utviklere (det generelle begrepet som favner alt man trenger at design, arkitektur, programmering, test, fag etc) Tanken er at Scrum teamet er et ansvarlig team, med de nødvendig fullmakter og kapabiliteter for å skape gode produkter (eller tjenester). Om Scrum teamet sier guiden: “It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”
Scrum blir ofte kritisert for å være en “feature factory” der fokuset er på å “produsere funksjonalitet” framfor å skape verdi. Dette er svært misvisende og langt fra intensjonen! Produktmålet skal jo være et langsiktig, forretningsmessig mål som sier noe om hvilket problem man skal løse for hvem. Dette skal gi en klar og tydelig retning for arbeidet i Sprintene, men behøver ikke å si noe spesifikt om hva man skal lage. Sprintene skal også ha mål (Sprint Goal) og disse kan også utmerket godt være effektmål. Begge målene på kort og lang sikt kan og bør være outcome oriented og ikke output oriented.
Hvert Sprintmål representerer et skritt i retning av Produktmålet. Utfallet av en sprint er jo et produktinkrement. Dette inkrementet settes i produksjon og vil dermed begynne å generere data. Viser disse dataene at vi er på vei mot produktmålet, eller ikke?
Scrum harmonerer utmerket med en rekke andre rammeverk og metoder som har kommet til de senere årene. OKR er et godt eksempel i så måte – det gir veldig god mening å integrere både Objectives og Key Results i målhierarkiet i Scrum. Tight – Loose – Tight (TLT) er også i utmerket harmoni med Scrum. Du finner god støtte for både den første og den andre Tight’en, mens gjennomføringen sett fra ledelsens side vil være veldig naturlig Loose.
Det er heller ingen motsetningsforhold mellom Product Management slik Marty Cagan har definert dette begrepet og Scrum (selv om Cagan i enkelte sammenhenger føler behov for å distansere seg fra Scrum).