Teamroller i gruppearbejde#
Læringsmål#
De studerende kan efter aktiviteten:
- arbejde struktureret i teams med klare ansvarsområder
- skifte perspektiv ved at prøve forskellige roller i et professionelt samarbejde
- håndtere faglige uenigheder og beslutninger uden at det bliver personligt
- samarbejde på en måde der afspejler praksis i IT-erhvervet
Forudsætninger#
De studerende forventes at kende til:
- grundlæggende projektarbejde
- git og pull requests (for Tech Lead-rollen)
- begreberne Scrum og agil udvikling er en fordel men ikke et krav
Kort beskrivelse#
De studerende arbejder i teams hvor tre roller - Scrum Master, Product Owner og Tech Lead - fordeles og roterer ugentligt. Rollerne er hentet direkte fra IT-erhvervet og giver hver studerende et klart mandat og klare opgaver. Strukturen reducerer sociale konflikter ved at flytte beslutninger fra det personlige til det professionelle. Det er ikke dig mod mig, det er Product Owner der prioriterer og Tech Lead der har sidste ord teknisk. Rotationen sikrer at alle prøver alle positioner, også dem der ikke falder dem naturligt.
Faglig kontekst#
- Semester/fag: Alle der har gruppearbejde
- Holdstørrelse: Alle
- Organisering: I grupper á 3-5 studerende
Trin-for-trin#
- Introducér rollerne og deres mandater tidligt i forløbet, gerne før grupperne dannes
- Lad de studerende trække lod om hvem der starter i hvilken rolle
- De studerende må gerne være to om samme rolle hvis de foretrækker det
- Rollerne roterer med én uges interval så alle kommer igennem alle positioner
- De studerende dokumenterer beslutninger og diskussioner i en log, hvor de hvem besluttede hvad og hvilke diskussioner der gik forud
- Underviseren holder øje med om rollerne reelt bruges eller om gamle hierarkier overtager
Rollebeskrivelser#
Scrum Master#
Scrum master sikrer at processen kører, at teamet fungerer godt sammen, og at der ikke opstår blokeringer i arbejdsflowet.
Konkrete opgaver:
- sikre at I afholder stand-up møder. Møderne skal være korte. I kigger på jeres Git Project eller hvad I ellers bruger til at holde styr på opgaverne. Alle kommer med en kort status af hvad de laver og om der er nogle forhindringer.
- sikre at gruppekontrakten overholdes. Hvis der er noget, der ikke fungerer, indkalder scrum master til et møde, hvor I får talt om hvad I skal gøre.
- sikre at alle høres, når I diskuterer løsninger.
- sikre at I er klar til vejledning og ved hvad I gerne vil have ud af vejledningen. Det er ikke scrum master, som skal formulere spørgsmål, men vedkommende skal sikre, at teamet har talt om hvad der skal ske til vejledning, hvem der præsenterer for vejleder mv.
- holde styr på planen for ugen og vide hvem der arbejder hvor. I tilfælde af sygdom melder I ind til scrum master.
- tage fat i vejlederen, hvis der opstår problemer, I ikke selv kan klare.
Product Owner#
Product owner er kundens forlængede arm og formidler kravene til teamet. Det vil i praksis sige, at product owner taler med kunden og formidler kravene videre til teamet.
Konkrete opgaver:
- agere kunde, hvis I er i tvivl om noget, der har med kravene at gøre (fx vil kunden mon kunne se alle ordrer eller bare de 10 første?).
- prioritere jeres opgaver. Hvad vil kunden have fokus på?
- tage en beslutning i kraft af sin kunde-rolle. Husk at notere i jeres log hvilke beslutninger, der bliver taget og hvilke diskussioner I havde.
- tage fat i vejlederen, hvis det er en større beslutning, I ikke selv kan tage
Tech Lead#
Tech lead har sidste ord i tekniske spørgsmål og er ansvarlig for kodekvaliteten.
Konkrete opgaver:
- kigge på pull request og acceptere eller afvise dem.
- sikre at kodestandarder er overholdt.
- sikre at DoD er overholdt.
- sikre at der dokumenteres og testes som aftalt.
- tage en beslutning ved diskussioner om design af koden. Husk at alle skal høres. Husk at notere diskussionen og beslutningen i log.
- tage fat i vejlederen, hvis I har brug for input til det tekniske.
Materialer#
- Rollebeskrivelser til print (ovenstående roller)
- Gruppekontrakt (anbefales som separat dokument)
- Git Project eller tilsvarende til opgavestyring
Tidsforbrug#
Introduktion: 20-30 min. Herefter kører strukturen selv med ugentlig rotation. Forvent at bruge 5-10 min. pr. vejledning på at tjekke om rollerne bruges aktivt.
Modtagelse#
De studerende tager godt imod strukturen. I en eksamensopgave beskriver en gruppe det sådan: “Det at vi havde helt klare regler og forventninger for hvem der måtte gøre hvad, minimerede helt klart antallet af fejl og diskussioner.”
Rotationen giver et uventet læringsudbytte. Den studerende, der har siddet løst på sine forpligtelser opdager pludselig hvad det koster scrum masteren når aftaler ikke overholdes. Det er empati gennem erfaring.
Udvidelser#
- Tilføj en Gitflow-struktur med feature branches og pull requests for at gøre Tech Lead-rollen mere konkret
- Lad de studerende skrive et kort rollerefleksionsnotat ved hver rotation. Hvad var svært, hvad overraskede dem?
Noter til underviseren#
Den største faldgrube er at rollerne bliver symbolske og at de studerende nikker til strukturen, men fortsætter som før. Hold øje med om tech lead reelt gennemgår pull requests og om scrum master reelt afholder stand-ups.
Rotationen er ikke valgfri. Hvis de studerende selv må vælge, vælger de det trygge, dvs den rolle de er bedst til eller den der giver mindst eksponering. De uheldige hierarkier cementeres i stedet for at brydes. To studerende må gerne dele en rolle hvis de er usikre, men alle skal igennem alle positioner.
Strukturen er hentet direkte fra erhvervet. Det er ikke en leg eller en øvelse i bløde kompetencer. Det er sådan det fungerer i praksis. Den præmis er vigtig at kommunikere til de studerende.
Læs mere om tankerne bag i indlægget om Stilladsering af gruppearbejde.