Når en virksomhed vælger at organisere arbejdet på en ny måde, er det naturligt at kigge på hvilke kompetencer, der er behov for, for at kunne arbejde efter de nye metoder. Som nævnt i et tidligere indlæg, er effektiviteten af et agilt team afhængig af teamets beslutningskompetence. Det stiller krav til ledelsen af disse teams, men det stiller også krav til de enkelte team medlemmers kompetencer.
Her er det naturligt at kigge på, om de faglige kompetencer er på plads, for at teamet kan løse de opgaver, de forventes at løse, men det er mindst lige så vigtigt at kigge på de personlige kompetencer. Hvis de rigtige kompetencer ikke er til stede, kan det forhindre teamet i overhovedet at træffe beslutninger, eller de kan risikere at træffe beslutninger på et forkert grundlag. Sådanne situationer kan føre til, at ledelsen mister tilliden til et team og derfor vil forsøge at tage kontrollen tilbage f.eks. ved at kræve, at der igen lægges detaljerede projektplaner, hvilket jo modarbejder den agile tankegang.
Faglige kompetencer varierer alt efter organisation og opgaver. Derimod går de personlige kompetencer på tværs af organisationer, og her er det særligt interessant at kigge på de nye roller, som introduceres i forbindelse med indførelse af agile udviklingsmetoder.
For at sikre at de rigtige kompetencer er til stede i et team, er det vigtigt, at ledelsen på forhånd har tænkt over hvilke forventninger, de har til de enkelte roller både fagligt og personligt. Desuden er det vigtigt, at disse forventninger kommunikeres til teamet, så alle ved, hvad der forventes af den rolle, man har påtaget sig. Det kan være svært at definere præcis, hvad der forventes, specielt for de nye roller. Det er derfor vigtigt, at der følges op undervejs og forventningsafstemmes med teamet.
I det følgende vil jeg kigge på de nye roller som introduceres i forbindelse med agile udviklingsmetoder, hvilke kompetencer man bør have fokus på, og hvilke udfordringer det kan give, hvis kompetencerne ikke er til stede.
Scrum master
Scrum master rollen defineres lidt forskelligt fra organisation til organisation, men generelt beskrives Scrum masteren som en rolle, der skal facilitere teamet og sikre, at udfordringer ryddes af vejen. At ”facilitere teamet”, er et relativt bredt begreb. Der lader dog til at være generel enighed om, at Scrum masteren skal hjælpe teamet med selv at finde løsninger på udfordringer, som forhindrer dem i at komme videre med deres opgaver. Det kan f.eks. være at mægle i interne konflikter, hjælpe med at finde kompromiser på komplekse problemstillinger eller hjælpe teamet med at erkende interne udfordringer, de ikke selv har identificeret endnu.
Fordi teamet selv har ansvaret for at planlægge og prioritere deres opgaver, kan de risikere at blive fanget i samme krydspres, som mellemledere ofte bliver fanget i. På den ene side organisationens behov for at få leveret hurtigt, og på den anden side medarbejdernes behov for at gøre arbejdet ordentligt.
Hvis dette pres bliver for stort, kan det blive til en frustration i teamet, som kan være svær at håndtere. Når frustrationen bliver for høj, vil teamet have behov for at få hjælp til at håndtere dette. Hvis denne hjælp ikke kommer fra ledelsen (som beskrevet i foregående indlæg), kan teamet have en forventning om, at Scrum masteren kan løse problemet. Udfordringen kan være, at der i Scrum master rollen ikke ligger en magt eller autoritet til at afhjælpe pres, der kommer udefra. Det er derfor alene op til Scrum masterens personlige autoritet og evne til at rumme frustrationen og hjælpe gruppen videre. Det kan f.eks. være ved at hjælpe teamet med at identificere, hvad frustrationen kommer af og dermed finde en måde at adressere problemet. Det kan også være ved at henvende sig til interessenter i organisationer, som kan hjælpe med at nedbringe presset. Mange Scum mastere, som føler, at de lykkes i rollen, trækker på deres erfaringer fra tidligere roller f.eks. som udvikler, til at give dem den nødvendige respekt og autoritet.
Hvis en Scrum master ikke har den nødvendige respekt og personlige autoritet, kan denne risikere at føle sig presset af gruppen til at gøre noget, selvom dette ligger uden for rollens magt, og de kan derfor føle sig magtesløse. Magtesløsheden kan lede til, at personen søger sin autoritet i sit kendskab til metodeapparatet, hvilket kan komme til at virke meget rigidt og ikke særlig agilt.
Product owner
Product owner rollen defineres også forskelligt fra organisation til organisation, men fælles er, at de skal agere forretningsrepræsentanter i gruppen. Det er derfor vigtigt, at den person som indtager rollen, også har den nødvendige forretningsmæssige viden og erfaring, da rollens autoritet ellers risikerer at blive undermineret i gruppen. Hvis Product owneren enten ikke selv har nok viden til at tage beslutninger eller er nødt til at søge godkendelse uden for teamet på de fleste spørgsmål, vil personen miste sin autoritet i gruppen. Det kan gøre prioriteringen af forretningsbehov ineffektiv, og man risikerer, at prioriteringen af opgaver ikke lever op til ledelsens ønsker.
Det er vigtigt også at have fokus på, at Product owneren vedligeholder sine forretningsmæssige kompetencer. Man bør derfor overveje at stille muligheder til rådighed for Product owneren, så denne kan komme tilbage i forretningen for at få genopfrisket forretningsviden.
Opsamling
-
- Det er vigtigt at sikre sig, at de enkelte teams har de rigtige kompetencer, både faglige og personlige, for at teamet kan løfte de opgaver, der forventes, af dem.
-
- Der bør være en særlig opmærksomhed omkring de nye roller, da det kan være svært på forhånd at definere hvilke kompetencer, der bliver behov for.
- Ledelsen bør have en særlig opmærksomhed på de personlige kompetencer, det kræver at varetage rollerne som Scrum master og Product owner, da det kan have stor betydning for, om teamet fungerer effektivt.