Udviklingsteamet er en gruppe af uafhængige fagfolk. Dog afhænger succesen af det projekt, de implementerer, af deres fælles indsats. Og dette kræver en stor grad af modenhed og teamwork-færdigheder. Hvad er de mest almindelige fejl blandt udviklere? Hvilke af dem gør jagten på produktmålet vanskelig eller endda umulig?
Almindelige fejl blandt udviklere – indholdsfortegnelse:
- Almindelige fejl blandt udviklere
- At være alt for knyttet til sine idéer
- Selvstændighed
- Tilbagetrækning af udvikler
- Uafhængighed
- Begrænsning af ansvar til myndighedsområdet
- Sprint Backlog Rod
- Sammenfatning
Almindelige fejl blandt udviklere
Mange af fejlene hos udviklere, der arbejder i Scrum, har deres oprindelse i deres tilgang til teamwork. På den ene side er det misforstået uafhængighed og forsvar af egne idéer mod teamets interesser. På den anden side er det at stole på andre og manglen på uafhængighed. En anden kilde til problemer kan være en misforståelse af teamansvar.
At være alt for knyttet til sine idéer
Udviklernes daglige ansvar inkluderer at finde innovative løsninger på komplekse problemer. Den indsats, der lægges i at udvikle løsninger, kan få dem til at blive alt for knyttet til deres idéer. Dette får dem til at miste fokus på produktmålet og bruge for meget tid på at udvikle sideløsninger, der ikke er nyttige fra et forretningsperspektiv. Og de er også mindre villige til at lede efter alternative løsninger, hvilket truer teamets smidighed.
Selvstændighed
Hvis en udvikler har svært ved at forstå sin rolle i teamet, vil de forsøge at adskille deres opgaver fra sprintmålet. Endnu værre er det, at de vil udføre dem uden reference til resten af teamet. Det kan også blive et problem, hvis de vilkårligt foretager ændringer i sprintbackloggen. Dette er, hvordan den misforståede uafhængighed hos en af udviklerne kan stamme fra kommunikationsproblemer.
Et overdrevent ønske om uafhængighed kan være rodfæstet i en mangel på anerkendelse for en udviklers individuelle præstationer. Det viser sig, når hans eller hendes bidrag til det arbejde, der udføres af teamet, vurderes ude af proportion til den indsats, der er lagt i, og sværhedsgraden af opgaven.
At arbejde på egen hånd kan blive en kilde til alvorlig konflikt inden for teamet. Derfor er det så vigtigt for Scrum Masteren at reagere og løse det underliggende problem så hurtigt som muligt. Dette skyldes, at det kan vise sig, at fejlen ikke ligger hos udvikleren, men hos en forkert vurdering af deres involvering.
Tilbagetrækning af udvikler
Problemet, der stammer fra de to foregående – at arbejde på egen hånd og at være alt for knyttet til sine egne idéer – kan være et problem med mangel på kommunikation. Så begynder disse udviklere at isolere sig fra teamet. Selvom de udfører deres opgaver i henhold til sprintbackloggen, trækker de sig tilbage fra teamets liv.
I en sådan situation bør Scrum Masteren være særlig opmærksom på de tilbagetrukne udviklere. Vurdér deres bidrag til teamet og opfordr dem til at tage en proaktiv holdning.
Uafhængighed
Selvorganisering er en karakteristik ved et modent, velkomponeret udviklingsteam, som vi beskrev i en tidligere artikel. Det betyder, at på trods af vanskeligheder, stoler udviklerne ikke på andre mennesker til at fortælle dem, hvordan de skal fordele opgaverne imellem sig, hvordan og hvornår de skal udføre dem. Dog kan selvorganisering give anledning til interpersonelle misforståelser.
I sådanne tilfælde er det nødvendigt, at Scrum Masteren er til stede hele tiden for at sikre, at de opgaver, der skal udføres for at nå sprintmålet, bliver fordelt. Det er her, problemet med afhængighed blandt udviklerne opstår.
Igen bør Scrum Masteren komme til undsætning ved at opfordre medlemmerne af udviklingsteamet til at være selvbestemte og tage ansvar for deres opgaver.
Begrænsning af ansvar til myndighedsområdet
Et andet problem, som udviklerne skal stå over for, især i det dannende team, er uvilligheden til at udføre opgaver, der ikke tilhører udviklerens kernekompetencer.
Denne fejl kan føre til en betydelig reduktion i effektiviteten af udviklingsteamet. Ikke alle sprints udnytter kernekompetencerne hos hvert teammedlem. Derfor må de være åbne for at udføre andre, supplerende eller organiserende opgaver, der er lige så relevante for sprintmålet.
Sprint Backlog Rod
En sådan opgave er at holde sprintbackloggen i orden. Det er en nøgleopgave for den glidende drift af udviklingsteamet. Dog er en almindelig fejl at flytte ansvaret for at holde den mellem udviklerne. Dette hindrer ikke kun arbejdet med sprintmålet, men også udviklingen af teamet og dets løbende forbedring.
Almindelige fejl blandt udviklere – sammenfatning
For at opsummere inkluderer de mest almindelige fejl blandt udviklere forsøg på at skære sig selv af fra teamet som helhed: at arbejde på egen hånd, presse deres egne idéer og blive tilbagetrukne. Integriteten af udviklingsteamet trues også af problemer med at udvikle uafhængighed, rod i sprintbackloggen og udviklernes uvillighed til at udføre opgaver uden for deres kernekompetencer.
Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube.
Caroline Becker
Som projektleder er Caroline en ekspert i at finde nye metoder til at designe de bedste arbejdsgange og optimere processer. Hendes organisatoriske færdigheder og evne til at arbejde under tidspres gør hende til den bedste person til at gøre komplicerede projekter til virkelighed.
Scrum Guide:
- Ordbog over grundlæggende termer, roller og begreber
- Hvad er Scrum?
- Scrum værdier
- Hvordan implementerer man Scrum i din virksomhed?
- Scrum Team - hvad er det, og hvordan fungerer det?
- Hvem er en Product Owner?
- De mest almindelige fejl hos Product Owner
- Hvem er Scrum Masteren?
- De mest almindelige fejl hos Scrum Master
- Hvilke statistikker og målinger bør Scrum Masteren følge?
- Udviklingsteam i Scrum
- De mest almindelige fejl hos udviklere
- Scrum artefakter
- Skalering af Scrum
- Sprint Backlog
- Hvad er produktbackloggen?
- Hvad er brugerhistorier?
- At skabe den bedste User Story med INVEST
- De mest almindelige fejl i User Stories
- Brugerhistorie Acceptkriterier
- Estimering og Story Points i Scrum
- Planlægningspoker
- Team Estimeringsspil
- Definere inkrement
- Scrum begivenheder
- Hvad er et Burndown-diagram?
- Fordele og ulemper ved burndown-diagrammet
- Kanban-tavler i Scrum og Scrumban
- Hastighed i Scrum - Udviklingsteamets hastighed
- Daglig Scrum
- Sprintplanlægning
- Sprintgennemgang
- Hvad er en Sprint Retrospektiv?
- Almindelige fejl under en Sprint Retrospektiv
- Produkt Backlog pleje
- Hvordan opretter og fortolker man et burndown-diagram?