kim tiedemann bloghoved

Kan dine forventninger påvirke et Scrum-team?

Af 6

Jeg hørte for nyligt en rigtig interessant podcast fra This American Life

Podcast'en fortæller historier om, hvordan vores forventninger til hinanden kan påvirke, hvordan vi opfører os. Altså hvad jeg tænker om dig, kan påvirke hvordan du opfører dig.

Rotteforsøget

Det starter med en kort fortælling om et sjovt videnskabeligt forsøg: Kan vores høje/lave forventninger til rotter påvirke, hvordan de klarer sig i forskellige tests? En gruppe mennesker fik en mængde rotter, som de fik at vide var ganske almindelige rotter. En anden gruppe mennesker fik rotter, som de fik at vide havde specielle egenskaber. Hvilke rotter klarede bedst forskellige labyrintøvelser? Det gjorde rotterne "med de specielle egenskaber". De klarede sig næsten dobbelt så godt, på trods af, at de var ganske almindelige forsøgsrotter, som var tilfældigt udvalgt. Det var med andre ord de forventninger, som gruppen af mennesker havde til rotterne, der påvirkede deres indsats. Måske håndterede de dem anderledes og dette fik rotterne til at klare sig bedre?

Batman

En anden historie er fortællingen om en blind mand - Daniel Kish, som har lært "at se" ved brug af lyde, som han udsender til det omgivende miljø og får reflekteret tilbage som en slags menneskelig lyd-ekko-lod. Dermed får han et billede af omgivelserne. Fortællingen er at hans mor opdragede ham som en helt almindelig dreng, der ikke blev pakket ind, men fik lov til at kravle i træer, køre på cykel og gøre det, som andre drenge fik lov til.

Selvorganisering i et Scrum-team

Da jeg hørte historierne, kom jeg til at tænke på vores Scrum proces. Hos Schultz bruger vi Scrum processen til alle vores udviklingsprojekter, og det har vi rigtig god erfaring med.

Et af de vigtige elementer i Scrum er det selvorganisende team, som har en meget høj grad af medindflydelse på, hvordan arbejdet organiseres. Det er teamet, som afgiver et commitment i forhold til, hvad de forventer at nå på et sprint. Det er teamet, der bestemmer hvordan de funktionelle krav omsættes til en løsning, og det er teamet, som retrospektivt, kigger tilbage på processen og kommer med kontinuerlige forbedringer.

Hvordan påvirker vores forventninger teamet?

Hvordan kan selvorganisering fungere? Det er her, hvor jeg tror, vi kan lære af podcast historierne: Det er omverdenens forventninger til teamet, der sætter rammen for teamets arbejde. Ligesom rotterne (dette ikke ment som en general sammenligning mellem forsøgsdyr og et Scrum-team :-) ) så kan teamet ikke performe godt uden, at omverdenen har høje forventninger til teamet. Det gælder ikke mindst de forventninger, som man ikke direkte udtrykker. Verden omkring teamet skal udstråle: "Vi tror på jer", "Vi er trygge ved jeres løsninger" og "Vi ved, I kan komme i mål, hvis I selv får lov". Teamets selvtillid kommer både ude- og indefra, og vores forventninger kan hjælpe teamet med at få succes.

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan Ebdrup Blogger

Hos os har vi stor tillid til udviklerne. Så meget at udviklerne selv har ansvaret for en opgave hele vejen fra den startes indtil den er i produktion, og har også ansvaret for opgaven hvis der er problemer i produktion.

Det er udviklerne på opgaven, der bestemmer hvornår der skal deploy'es til produktion, og udviklerne trykker selv på knappen og deploy'er når de mener at kvaliteten er i orden - uden at spørge om lov, det er op til egen vurdering.

Når jeg fortæller om der er mange vantro. "Kan de virkelig det?" - Ja det kan de!

Og de vantro er ved at falde bagover, når jeg så fortæller at otte ud af elleve udviklere lige nu sidder i Ukraine. Så bliver der mumlet noget i skæget om kultur og vi må have et specielt team... Tja, vi har ihvertfald høje forventninger til dem, som bliver indfriet.

  • 2
  • 0
Allan Ebdrup Blogger

Det er fantastisk hvordan forventninger, kombineret med ekstra ansvar, egen bærbar og hjemmearbejdsplads, lige kan presse de 2 ekstra, ikke-fakturerede timer ud af en medarbejder hver dag.


Jeg er ikke helt sikker på at det var mindet mod mig. Men en ting vi ikke gør, pånær i få tilfælde, er at give udviklerne deadlines. Hvis du vil have det færdigt hurtigt - så reducer scope for opgaven.

  • 1
  • 0
Johnny Bahr Jakobsen

Allan, det var overhovedet ikke mindet mod dig.
Ideerne i Scrum er generelt også sunde.
Men har oplevet stand-up møder hvor scrum-master ikke har opfyldt sin rolle. Og så bliver det bare til "nu reddede du jo situationen sidst, så det kan du også lige gøre igen", så sidder udvikleren igen til over midnat fordi der er lavet scope-creep eller tilføjet andre opgaver, som ikke er med i sprintet.

  • 0
  • 0
Martin Kofoed

Et af de mest produktivitetsfremmende tiltag i mit team har været, at vi helt har droppet, at udviklerne gætter på estimater på delopgaver. Det er spild af tid, da opgaven erfaringsmæssigt bliver hurtigere færdig ved helt at lade være. "It's done when it's done", groft sagt. På et højere niveau bliver opgaver dog estimeret af hensyn til forretningen, der jo altid gerne vil vide, hvornår en given feature kan forventes i produktion. Det er fair nok. Derfor inddeler vi alle opgaver på story-niveau i XS, S, M osv. Men altså ikke med deadlines med mindre forretningen kræver det. Alt kan jo overrides fra dén kant ...

Vi kører heller ikke med sprints, i øvrigt. Vi har kontinuerligt flow ind i vores svømmebaner. Det er så teamlederens vigtigste opgave: at identificere og prioritere opgaver med forretningen i et passende flow. Det var et problem i begyndelsen, fordi udviklerne lukkede opgaverne meget hurtigere end forventet. Så der opstod en uges tid med manglende opgaver. Vi valgte at tolke det som et positivt problem ... Mødeaktiviteten i forbindelse med faste sprints er for mange udviklere ligeledes spild af tid, da det oftest mere handler om, at diverse ledere skal opnå en god mavefornemmelse, end at udviklerne flytter sig hurtigere. Ulempen ved at køre uden sprints er, at vi selv skal sørge for at lægge passende fejringer af projektsucceser ind ved forskellige pejlinger. :-)

Jeg tror nok, vores model er Kanban/Scrumban-inspireret. Men det interesserer mig ikke så meget. Pointen er, at jo flere forhindringer, du rydder af vejen for dine udviklere, desto højere produktivitet får du. Jo mere strømlinet dit opgaveindtag snurrer, desto højere produktivitet. Surprise! Det lyder banalt, men det er ikke desto mindre svært i praksis, da det netop kræver høj tillid til udviklerne, som Allan også er inde på. Men hvis du ikke stoler på dine udviklere, har du sikkert helt andre problemer, der skal fikses ...

  • 2
  • 0
Allan Ebdrup Blogger

Ja vi har også droppet at estimere. Og burndowns, vi har ikke engang t-shirt sizes. Vi reducere scope i stedet, alt skal kunne leveres på en uge til produktion. Det er utroligt så meget tid vi sparer, ved ikke at lave alt det nedbrydning og estimering. Scrum er mini-vandfald. Nu er det continuous delivery der bliver talt om. B u

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