Scrum-overblik - en sides "cheat sheet"

Nu er det ikke fordi jeg vil gå min nye med-blogger Bent i bedene (velkommen til Bent), men forleden faldt jeg over en interessant Scrum-resource: Et såkaldt Scrum Cheat Sheet.

(Klik på billedet for at se en større version)

Det en-sides hurtige overblik over Scrum kan være meget nyttigt i forhold til at starte en snak om Scrum, både i selskab med Ikke-Scrum-folk og i selskab med etablerede Scrum-teams, som også nogle gange har godt af at få genopfrisket Scrum og at have et grundlag til at diskutere processen.

Mit udgangspunkt da jeg først læste den igennem var, at jeg egentlig var meget enig i vigtigheden af de fleste punkter derpå i forhold til at formidle Scrum, men samtidig at der var et par enkelte punkter jeg ville fremhæve specielt.

Baseret på personlig erfaring ville jeg fremhæve pointerne omkring produktejerens ansvar og arbejdsrolle (PO'ens rolle er efter min mening et problemfyldt emne i Scrum i praksis), behandling og opbygning af backloggen (eks. at alle kan sætte et punkt på backloggen er en ofte overset pointe) og at delvist færdig funktionalitet IKKE er en del af sprint-demoen (ingen delvise point kan tildeles og det handler om at få produktet gjort potentielt shippable).

**Dette Scrum Cheat Sheet fremhæver særligt to pointer: "Visibility+flexibility = Scrum" og "DONE? = potentially shippable. Selv om den sidste minder lidt om en af mine pointer, så synes jeg at netop disse to er så løst formuleret, at de ikke er værd at fremhæve som noget særligt, men det kan være at Cheat-Sheet-forfatterens egne Scrum-erfaringer gør netop disse pointer vigtige. Det er min erfaring at mange hurtigt får deres egen vinkel på hvad der er vigtigt i Scrum ud fra hvad der trænger til at blive forandret i deres organisation og arbejdstilgang.

Hvad ville du selv fremhæve?

Kan du bruge sådan en "cheat sheet" til noget?

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Kasper Sørensen

En af de ting som jeg lige bider mærke i ifht. min daglige omgang med Scrum er, at de lægger vægt på en ting som jeg synes er svært at gøre muligt i det praktiske arbejde, nemlig "User stories are NOT dependent on other stories".

I det projekt jeg pt. arbejder på sker det relativt ofte at der er afhængigheder ml. user stories. Eksempelvis skal der måske en grundlæggende ændring til før en række andre stories kan løses. Denne grundlæggende ændring laver vi så en story der ikke direkte bidrager med værdi for PO'en, men som visualiseres som afhængig story for de mere PO-værdi-orienterede stories. Et eksempel-scenarie:

Grundlæggende story: (A) "som udvikler er ændret således at jeg kan <gøre noget nyt der kan tjene flere formål>". Estimation points: 8.

Afhængige stories: (B) Som kan jeg , hvis (A) er done. Estimation points: 4. (C) Som kan jeg , hvis (A) er done. Estimation points: 2.

Hvis man vil løse (A) "koster" det altså samlet 12 estimation points. Hvis man vil løse (B) "koster" det altså 10 estimation points. Hvis man vil løse dem begge to koster det 14...

Er dette bad practice eller en rimelig "tilpasning" af metoden, synes I?

  • 0
  • 0
#2 Bo Frese

Hej Therese,

Fint indlæg.

Om Cheat sheetet kan bruges? Jeg tror det ville være fint som 'hand-out' efter et kursus - som reminder om hvad man har lært. Men det kan naturligvis ikke stå alene.

Jeg tror en af de ting der tit går galt med implementeringen af Scrum er at folk prøver at adopterer det ud fra en ret overfladisk forståelse af Scrum. Så derfor tøver jeg naturligvis også med at formidle det i form af 'bullet points' der opsummerer praktikkerne.

Jeg ser det faktisk gå skævt i begge retninger. Der er dem der 'tilpasser' metoden uden at forstå konsekvensen af deres 'tilpasning', og dermed misser hele den potentielle gevinst af Scrum. Der er også dem der fastholder alle praktikkerne - og laver noget der på overfladen ligner Scrum. Men de stiller ikke spørgsmålstegn ved det. Det følger blot noget de har set i en bog.

Et klassisk eksempel er faktisk illustreret i dit Cheat sheet. Hver gang jeg ser en Backlog fyldt med User Stories der alle sammen starter med 'As a user I would like to ....' får jeg lyst til blot at slette de første 7 ord i hver User Story. Det er jo redundant 'spild' der ikke tilføjer nogen som helst værdi til beskrivelsen. Som jeg engang hørte Gertrud bjørnvig sige - "Problemet med de fleste User Stories er at de hverken har en 'User' eller en 'Story'... ".

En User Story skal som udgangspunkt besvare 3 spørgsmål. Hvem? Hvad? og Hvorfor? De fleste misser Hvem og Hvorfor. Hvem? Har meget at gøre med Usabillity. Typisk har man en række persona beskrivelser at forskellige typer af brugerer. Hvem er de, hvad der deres typiske brugs context, hvad er vigtigt for dem, hvor stort IT kendskab har de, hvor tit bruger de systemet? O.s.v. Hvorfor? Hvad er det egentligt personen forsøger at opnå? Jo mere præcist dette er, jo lettere er det for udviklerne at komme op med en implementering der giver brugeren præcist hvad de har behov for. Det skal gerne inspirere til at finde på andre, bedre, hurtigerer, billigere måder at opfylde behovet.

Hvad jeg ellers selv ville fremhæve?

Tja- Jo flere teams og organisationer jeg har arbejdet med, jo mere er jeg overrasket over hvor forskelligt det er hvad der er vigtigt at ligge vægt på, og hvad der er helt naturligt og sker af sig selv.

De første teams jeg arbejde med bestod af fantastisk dygtige udviklere, hvor selvorganisering, fælles ansvarsfølelse, høj teknisk kvalitet, god arkitektur, automatisk test altsammen var helt naturligt. Desværre er det ikke altid sådan - og det kan tage tid, og være et større kultur skifte at bygge det op. Jeg tror ikke det kan koges ind til et enkelt punkt i et Cheat sheet :-)

Jeg er enig med dig i at Product Owneren (PO) er super vigtig. Selv om jeg ikke vil omtale det som 'et problemfyldt emne'. Det får det jo til at lyde som PO'ere er nogle mærkelige størrelser :-) Scrum er en metode der i ekstrem grad sætter PO i førersædet. Vi kører i præcist den retning som PO vil. Det er jo en fantastisk mulighed for forretningen. Derfor er jeg også lidt forundret når jeg hører Scrum omtalt som en mere 'nørdet' metode en andre? Jeg kender ingen anden tilgang til projekter der i lige så høj grad binder foretningen og udviklerne tæt sammen i et fælles lærings og udviklings forløb. Forudsætningen er naturligvis at forretningen er klar til at benytte sig af tilbudet, og er istand til på deres side at udnytte den flexibilitet og læring som Scrum muliggør. PO er personificeringen af dette, og dermed at det naturligvis ekstremt vigtigt at finde en person med de rette kompetencer, erfaring, og ikke mindst mandat til at tage hurtige beslutninger.

Men skal jeg fremhæve en enkelt ting - et enkelt princip - som efter min mening er det vigtigste, så er det : Kaizen - eller konstant forbedring.

Al erfaring har vist os at man ikke på forhånd kan opstille en detalieret og effektiv krav spec. der i detalier beskriver alle krav til et system. Og man kan heller ikke på forhånd og i detalier lave en detalieret process håndbog der præcist beskriver hvordan vi skal arbejde i projektet for at garanterer success.

Jeg kan godt li' Ken Schwabers bramfri citat : "Scrum does not produce excellence - it exposes incompetence!".

Scrum er bygget op som et lærings loop, der giver præcis feedback ved slutningen af hvert Sprint. En lejlighed til at lære om vi laver de rigtige ting, og om vi gør tingenen rigtigt. Hvis organisationen og kulturen ikke er klar til at håndterer og udnytte dette, er man ikke klar til Scrum endnu.....

mvh Bo Frese AgileCoach.dk

  • 0
  • 0
#5 Therese Hansen

Jeg er ikke helt sikker på at jeg forstår din løsning på problemet med afhængige stories, Kasper. Mener du at det koster 12 for at løse (B) og 10 for (C)?

Uafhængige stories er helt klart et problemkrav i Scrum - og det er noget der er meget svært at forstå for en PO.

  • 0
  • 0
#6 Therese Hansen

Det var nu ikke for at få PO'er til at fremstå som nogle mærkelige størrelser ;-) - men i Scrum virker det som om de skal være "supermænd/kvinder" og det er problemfyldt. Jeg har længe haft planer om at skrive en "guide to product owning" fordi jeg mener der ofte er alt for lidt fokus på Produktejeren, når Scrum skal udføres i praksis.

Og jeg er 100 % enig med dig i at Kaizen og at udstille inkompetence er kernen af Scrum.

  • 0
  • 0
#10 Bent Jensen

Hej Therese,

Tak for velkomsten og du går mig bestemt ikke i bedene. Jo mere debat og oplysning om Agil tankegang, jo bedre efter min mening.

Jeg kan godt se, at "Snydearket" ovenfor, kan være praktisk til at starte en samtale, eller kort forklare Scrum for nogen som ikke har hørt om det før.

På den anden side er det jeg sædvanligvis forbinder med "Cheat-sheets" en mulighed for hurtigt at få en information, som ikke er til at misforstå. Det være sig matematiske formler, regler i et udviklingssprog, eller i gamle dage: tastekombinationer i word-perfekt. Til denne type information er den en genial form. Men for Scrum og andre "bløde" ting kan det give et indtryk af, at der kun er ét svar, der ikke står til diskussion.

F.eks står der under "Sprint Retrospective":

"Attendees: SM and Team PO is optional."

Jeg tror at det er meget sjældent, at det er en god idé at PO'en ikke deltager i et retrospective. Jeg har ofte set, at en fraværende PO bliver genstand for fingerpegning, mens det at PO'en er tilstede fremmer forståelsen og giver mulighed for at reflektere og forbedre hele processen.

Et eksempel på et punkt som i høj grad er til diskussion - hvad en oplysning som "F7 = Spell Check" ikke er.

  • 0
  • 0
Log ind eller Opret konto for at kommentere