Fra faldgrupper til faldgruber
Jamen vi bruger da Scrum – men…
Agile Scrum er utrolig populært og rigtig mange steder arbejdes der efter Scrum metoderne. Dertil er der ofte et lille ”men..” – Det at køre Agile Scrum er mere sjældent, og svært at få succes med. Det skyldes at mange steder i organisationen kan påvirke, så det ikke er muligt at implementere 100%.
Dette er netop en af de helt store grunde til at man skal sikre opbakning gennem HELE organisationen, og især sikre at ledelsen har fået tilstrækkelig forståelse for konsekvenserne.
Til skræk og advarsel, har jeg her listet en del af de typiske fejl der ses rundt omkring.
Scrum Bommerter
Overdreven forberedelse og planlægning
Forudgående planer og beskrivelse af projekter er ikke nødvendige med Scrum. Typisk kan et team blot starte på opgaven, og gennem konstant feedback under Daily Scrum og især Sprint Review justere på planen. Product Backlog kan og må gerne fyldes af opgaver som projektet skrider frem. Jo mindre det er nødvendigt at forbedre for at teamet kan komme i gang – jo bedre!
Fokus på værktøjer
At finde det rigtige program til at støtte virksomhedens brug af Scrum prioriteres typiske meget højt. Drop det – Det er ofte blot en hindring for at komme i gang – Det er faktisk utrolig lærerigt for alle kun at benytte tavler, post-its, og papirark, og det er den nemmeste måde at komme i gang, da man ikke også skal lære et nyt værktøj.
Daily Scrum bruges til at løse problemer
Dette møde er kun til afrapportering – Ikke til at løse problemer in plenum. Hold mødet så kort som muligt, og snak bagefter om løsninger på eventuelle problemer, så det kun involverer de som har interesse i at deltage i denne efterfølgende snak.
Tildeling af opgaver
Ja det lyder utroligt, men det sker faktisk at et såkaldt selvorganiserende team, ikke selv uddeler opgaverne i teamet, men lader ScrumMaster eller Product Owner håndtere denne del.
Lad være!! – Teamet skal være selvorganiserende, og dermed er det vigtigt dette sker i teamet, og kun der!
ScrumMaster som team medlem
ScrumMasteren er teamets brandmand – Det er helt i orden at denne ind imellem har tid til at observere og vurdere teamets tilstand. Ofte er det desværre tillokkende denne i stedet løser opgaver, når der er ro.
Men dette flytter fokus fra ScrumMasterens egentlige rolle – at sikre teamet følger Scrum metoderne og fjerne forhindringer, og hvad sker der når der skal prioriteres mellem at nå opgaven, eller fjerne forhindringer – begge for teamet, og med konsekvens for om sprintet bliver en succes.
Her kan det være en bedre løsning at én ScrumMaster har flere teams i stedet for en blandet rolle i teamet.
Product Owner er fraværende
Product Owneren er et medlem af Scrum Teamet på lige fod med de øvrige, og bør deltage i alle Scrum møder (Daily Scrum, Planning og Review). Det skal være muligt for teamet at få fat i Product Owner, for at besvare opståede spørgsmål til igangværende opgaver. Product Owneren har naturligvis møder med forskellige interessenter men disse skal placeres så de ikke rammer i Scrum Teamets møder.
Stretched Goals
Udtrykket Stretched Goals er kendt af mange – Det betyder kort og godt, at sætte et mål man ikke umiddelbart kan nå. Dette kan der være mange fordele vel, da det fordrer kreative tanker, og kan får det bedste frem og et team – Men det skal bruges med omtanke, eftersom det lige så hurtigt kan være kraftigt demotiverende på et ellers effektivt team.
Teamet selv er de eneste der må beslutte hvor meget de vil committe sig til i et sprint. Mener de at de vil sætte et stretched goal, så er det naturligvis glimrende, men det skal ikke ske pga pres fra andre, da dette typisk resulterer i dårligere kodekvalitet, og reduceret tillid.
Teamets helt
En enkeltperson på et team bør ikke i væsentligt omfang arbejde over for at redde teamets ære. Scrum er baseret på en team indsats, og teamet bør i fællesskab se nødvendigheden af dette og udføre det ekstra arbejde som det team de repræsenterer.
Teamet ejer Product Backlog
Dette er en meget stor fejl, eftersom teamet ikke har den nødvendige information eller indsigt i behov og prioriteter hos interessenterne. Teamets fokus skal være den tekniske løsning, og kvaliteten af deres kode.
Ydermere er Product Owneren ansvarlig for ROI, og derfor bør han aldrig lade teamet styre rækkefølgen i Product Backlog ud fra tekniske hensyn
Product Owner specificerer løsningen
Teamet skal have beføjelser til at finde på de bedste løsninger til opgaven beskrevet i Product Backlog. Product Owneren må ALDRIG diskutere tekniske løsninger, med mindre det er et direkte krav fra interessenterne.
Vigtige afbrydelser
Afbrydelser skal ikke tillades i et sprint – Hvis det virkelig er så vigtigt, må sprintet afbrydes – Alternativt oprettes emnet i Product Backlog’en.
Er der et forretningsbehov som gør at man skal have plads til disse opståede ting, er der flere mulige løsninger for dette. F.eks kan man allokere et antal storypoints, eller allokere en fast ressource.
”Jeg går ud fra” syndromet
Det ses ofte at temamedlemmer undlader at forventningsafstemme med Product Owneren omkring detaljer i en story/task. Typisk løses opgaven bare, da der måske ikke ses tvivl omkring detaljerne – Men forståelsen behøver ikke være den samme mellem teamet og Product Owner.
Feedback mellem Product Owner og Teamet bør foregår konstant, og hver dag – Daily Scrum er en vigtig kilde til at fange disse ting!
Bliver ikke færdig med opgaverne
Dette vil ske ind imellem – Sprintet afsluttes uden at alle opgaver er lukket. Og det er OK! Men det må ikke blive en vane for teamet at over-committe under Sprint Planning. Moralen styrkes hver gang et sprint lukkes med succes!
Hold øje med at teamet bruger Burndown charts, og at review også holdes selvom ikke alle opgaver lukkes.
Ikke klar til Review
Teamet kan være så opslugte af opgaverne, at de glemmer det tager tid at forberede et Sprint Review.
Hvis dette er tilfældet, kan det forsøges løst, ved at medtage stories til dette i sprintet.
Distribuerede teams
Ingen af Scrums principper siger man skal sidde samme sted for at køre agilt – Men faktum er at hvis teamet ikke er samlet – HELT samlet, så lider dynamik, kommunikation og transparens under det. Afstanden behøver ikke være mere end nogle meter før problemet opstår – Så snart man ikke ”er med”, mistes der værdi i teamet.
Dette kan have en enorm indvirkning på både kvalitet og produktivitet.
Styrende ScrumMaster
En ScrumMaster skal facilitere og ellers være en flue på væggen. Som ScrumMaster skal man aldring blande sig i teamets beslutninger omkring løsning af stories, eller rækkefølge heraf.
Teamets motivation til at være selvkørende, nurses ikke ved at tage beslutningerne for dem.
Ændring at team-medlemmer
Målet i Scrum er at skabe high performance teams – Et team skal have tiden til at formes og skabe tillid, kende hinandens styrker og svagheder og blive et TEAM. Før dette sker, bliver teamet ikke high performance – Man kan ikke justere på medlemmerne, for på kort sigt at øge effektiviteten. Sørg for at teamet er cross funktionelt fra starten, og giv teamet stabiliteten til at vokse som team.
Fastholde Deadline, Scope og ressourcer
Vælger en interessent at pålægge teamet fast deadline, minimum funktionalitet og uændrede ressourcer, så må denne acceptere at kvaliteten falder – hvilket igen er et brud mod Scrum principperne.
Realiteterne er at ingen kender fremtiden, og ovenstående forventning er en fantasi!
Se mere i disse videoer, der har givet inspiration til flere af ovenstående: Scrum Myths
Summering
Hvis opbakningen til Agile Scrum er gennemsyret i organisationen fra top til bund, er det kun Scrum Teamets eller evt. PMO’s evne til at justere og korrigere der kan skabe problemerne beskrevet.
Ofte ses det dog at folk uden for Scrum Teamet, har svært ved enten at forstå eller acceptere Scrum principperne, og ønsker at presse noget ud af Team, Product Owner eller ScrumMaster. Her er det vigtigt at alle er stærke nok i de agile metoder, til at vide hvornår de skal sige fra.
Gør det til en fast rutine at alle sender disse forespørgsler til den samme person i Scrum Teamet – Typisk Scrum Masteren, men i alle tilfælde den som har dybest kendskab og evne til at finde en løsning der fungerer for alle parter.
Husk at Agile Scrum er principper – Man kan og bør tweake så det fungerer optimalt i ens virksomhed. Betyder det at man må gå på kompromis med noget af ovenstående, kan det stadig være den bedste løsning.
Første linie i det Agile Manifest hedder trods alt: Individer og samarbejde frem for processer og værktøjer.