# data[].attributes.body
Hver sprint bør levere noe brukbart (som kan brukes) som man kan gi feedback på i en review. I denne gruppen så det ut til å gå flere sprinter før noe brukbart ble levert.

# data[].attributes.body
Hver sprint bør ha et mål som er overordnet topic på standups, det er utfordringer mot sprint goal som bør informeres om, kanskje gjennom spørsmålene: hva gjorde jeg i går? hva skal jeg gjøre i dag? og har jeg utfordringer å fortelle om? Det vil forbedre oppdagelse av problemer og samspill. Standups skal ikke være mer enn 15 minutter lange, uavhengig av antall medlemmer. Diskusjoner ut over dette bør være i egne møter.

# data[].attributes.body
Oppgaver bør tidsestimeres slik at sprinter kan "timeboxes" og fylles med rett mengde oppgaver. Tid brukt på oppgaver bør logges slik at statistikk kan føres, og estimater i fremtiden justeres. Da unngår man at sprinter overfylles og at man jobber seg i hjel

# data[].attributes.body
Retro og review events er en del av feed back loopen og bør være med i enden av hver sprint

# data[].attributes.body
-For mye spesialisering på utviklerne => jobber mye alene => finner ikke mange av sine egne feil i utviklingsprosessen -Mindre stand-ups mot slutten. -For mange møter på starten.  -Mangel på god kommunikasjon på hva de gjør. Kommer blant annet fra at de er så spesialisert i det de driver med => mister troverdighet. -Spesialisering => vanskelig å ha “shared leadership” og et stor, felles, møte når mange av utviklerne ikke skjønner seg på hva som blir sagt

# data[].attributes.body
Hva du ser som hovedutfordringer for teamarbeid ifra beskrivelsen

Lange diskusjoner som ikke førte noen plass

Vanskelig å samarbeide med eksternt team

Utviklere som jobbet med andre ting enn det de skulle og som jobbet med framtidige oppgaver uten å fokusere på backlogen

Innadvendte utviklere som ikke sa så mye på møter

Utviklere lagde egne løsninger uten å diskutere med resten av teamet

Scrum master var for streng med utviklerne og mange turte ikke si noe på bakgrunn av dette

For få tilbakemeldinger på arbeidet som ledet til mye arbeid som måtte gjøres på nytt da utviklerne ikke forsto hverandre sin kode

Finner du igjen utfordringene med faktorer i “agile team effectiveness”- modellen?

Det at scrum master var for streng kommer av at de fikk for mye makt, dette funker ikke når det skal være delt lederskap

Vi ser også at teamet ikke var flinke nok på tilbakemeldinger som går inn i feedback

Gitt det du vet i dag, hvilke råd ville du gitt til teamet for å bedre teameffektivitet?

Dette kunne blitt løst om folk jobbet på hverandre sin kode så de ikke fikk eierskap på koden sin

Kommunikasjonen burde også vært bedre

Scrum master burde ha vært nøyere på å få alle til å snakke på møtene

# data[].attributes.body
Hva du ser som hovedutfordring for teamarbeid ifra beskrivelsen:

Selv om du er i team, så jobber du med din del alene

dårlig kommunikasjon

Finner du igjen utfordringene med faktorer i “agile team effectiveness”-modellen:

Gitt det du vet i dag, hvilke råd ville du gitt til teamet for å bedre teameffektivitet?

parprogrammering når problemer oppstår.

Passe på at alle forstår problemene presentert ved daglige scrum meetings.

fullføre daily meeting, holde av problemer som trenger lengre dialoger.

# data[].attributes.body
PO burde fjernet kundedatabase-feature fra backloggen. PO gjorde ikke jobben sin ordentlig

# data[].attributes.body
Hovedutfordringer for teamarbeid:
Flere utviklere jobbet alene og manglet tydelig kommunikasjon med resten av teamet. Dette førte til at unødvendig arbeid ble gjort. Flere følte at de ulike møtene var unødvendige, og manglet tillit til selve prosessen.

Råd:
Frem problemer for scrum master og PO. Forsøk å bedre kommunikasjon, slik at flere kan se det store bildet. Fokuser på teamets oppgaver, ikke implementer egne løsninger.

# data[].attributes.body
Separert arbeid med egene moduler
Fører til isjolasjon
Mangel på helhets forståelse
Lite kryss kommunikasjon
Feil prioriteringer på daglig møte

# data[].attributes.body
Ærlighet og åpenhet så ut til å være en utfordring. Arbeid ble gjort uten avklaring med resten av teamet, før mange arbeidstimer gikk i vasken som følge av dårlig kommunikasjon.

# data[].attributes.body
Hovedutfordringer
- Dårlig sammarbeid, mye individuelt arbeid
- For lite åpenhet mellom scrum master og team
-For lite feedback

Råd
- Bygg meir åpenhet/tillit/trygghet i teamet
- Skap felles forståelse/kunnskap gjennom samarbeid og diskusjon
- Gi meir Feedback.

# data[].attributes.body
- PO burde være fysisk tilstede
- For stor backlog, må si mer nei
- Holde seg til oppgavene i den inneværende sprinten
- Ha en klar agenda for SCRUM-møtene, både daglige og store
- Ikke være individualister, ha felles eierskap på prosjektet og jobbe mer sammen

# data[].attributes.body
Utfordringer:
- ingen shared leadership slik at alle fikk eierskap til produktet
- mutual trust ble et issue da det var en dude som jobbet videre på en DB for neste prosjekt

Råd:
- Bedre kommunikasjon
- La alle ta del og eierskap til produktet

# data[].attributes.body
Gennerelt er det stor mangel på komunikasjon og liten redundancy, burde hatt lenger daglige møter og et større sammerbeid. Det er også vanskligheter rundt sammlokalisjon.

# data[].attributes.body
Parprogrammering
- da kan det bli lettere å innrømme problemer, blir ikke like personlig kobling til koden
- få hjelp til å oppdage problemer

Mer kommunikasjon og mer tillit til hverandre
- åpenhet
- tør å si ifra om utfordringer/problemer

Rulere på oppgaver

# data[].attributes.body
- Dårlig kommunikasjon innad i gruppen
- Stoler ikke på hverandre
- Dårlig kommunikasjon med PO.
- Ha en tydeligere gjennomgang av den nye smidige modellen.
- Samarbeid mer
- Lederen bør være ærlig og mister all tillit når han ikke stoler på de ansatte.
- Hovedsak ærlighet og tillit

# data[].attributes.body
Lag et kort notat med hovedutfordringer og råd dere ville gitt til teamet.