Sådan byder du bedst et Scrum Team op til dans

Dette er ikke en klynke-artikel om, at det er synd for IT, fordi folk ikke forstår dem og beskylder dem for at levere alt for lidt. Dette er en konstruktiv artikel, der skal gøre dansen mellem det agile team og resten af organisationen mere rytmisk og knap så akavet. Håber du vil danse med 🕺

Martin Ibsen

Konsulent

mib@syndicate.dk

6

min. læsetid

November 9, 2022


I mange organisationer og virksomheder starter den agile rejse i IT-afdelingen. Her er de begyndt at arbejde agilt og har måske etableret Scrum Teams. Men ofte er resten af organisationen stadig sat op i programmer og projekter, der arbejder ud fra vandfaldsmodeller. Det har jeg set give anledning til mange konflikter, forvirringer og uhensigtsmæssigheder.

Fx kan overdragelser af opgaver fra ’forretningen’ være vanskelig, og man kan være udeforstående og ikke vide, hvad der sker i teamet, og hvad der bliver bygget eller endnu være; om tingene rent faktisk virker forretningsmæssigt.

Når forskellige tilgange støder sammen

Det skaber især problemer, når en projekttilgang møder den agile tilgang, og ofte ser jeg det fylde rigtig meget for disse organisationer, at de to tilgange ikke rigtig passer sammen. Og yderligere at mindsettet til at skabe digitale produkter er så forskelligt.

Stakeholders, eller andre der ikke er en del at teamet, har svært ved at forstå, hvorfor teamet skal arbejde agilt, og yderligere har de svært ved at arbejde sammen med et agilt team. Resultatet bliver et samarbejde, der er sløvt, hvor stakeholders kan få en fornemmelse af, at IT aldrig leverer noget.

Men hvordan skal der så bydes op til dans?

For det første er det altid godt at få en fornemmelse af, hvorfor teamet arbejder, som de gør, og hvorfor det overhovedet giver mening at arbejde agilt. Jeg vil anbefale dig at opsøge viden om det agile og få en fornemmelse af, hvad det betyder at arbejde agilt. Start evt. med at se denne video af Henrik Kniberg der forklarer "Agile Product Ownership in a Nutshell". Agile Product Ownership in a Nutshell

Det næste, jeg vil anbefale, er at tænke over, hvordan du stiller opgaver til det team, du samarbejder med. Altså hvordan arbejder du sammen med teamet for at opnå det, I alle sammen gerne vil - nemlig at få lavet fantastiske digitale produkter, som jeres kunder elsker.

Jeg ser desværre flere steder at stakeholders leverer bestillingslister, lange to do-lister eller specifikke krav på ting, de gerne vil have teamet til at lave. Ofte med lange løsningsbeskrivelser og estimater tilknyttet. Denne måde at stille opgaver på til et team giver flere problemer.

1. For det første bliver teamets kompetencer ikke brugt ordentlig, hvis de ikke kan påvirke, hvordan produktet skal være. UX/UI og udviklerne på de forskellige teams ved faktisk noget om produktet, og de skal ikke bare agere arme og ben – men deres gode hjerner skal også i sving.

2.    Hvis løsningen er defineret, inden opgaven rammer produktteamet, så bliver det svært og meget dyrere at ændre løsningen til det bedre undervejs i udviklingen. Produktet bliver simpelthen bedre, hvis vi kan opdage nye løsninger undervejs i udviklingen og tilpasse produktet.

3.    De fleste teams, jeg kender, vil gerne have ejerskab for produktet og motiveres af at løse problemer i modsætning til blot at tampe kode ind. Er du seniorudvikler bruger du 80 % af din tid på at tænke over den bedste løsning og 20 % på faktisk at kode.

Find de vigtigste problemstillinger (ikke løsninger!)

I stedet for at komme med løsninger til et produktteam, skal du i stedet finde de vigtigste problemstillinger eller forretningsmuligheder, som teamet skal løse. Nedenfor er et helt simpelt bud på en skabelon, du kan benytte til at byde et Scrum Team op til dans, men det kan også være andre artefakter som use case-beskrivelser, prototyper/visualiseringer eller i formål og succeskriterier.

Pointen er, at du ændrer fokus fra at komme til teamet med løsninger til at fokusere på problemer og behov, som teamet i fælleskab skal løse.

Måske skal jeres kunde komme hurtigere igennem et flow, eller I skal minimere churn på jeres hjemmeside eller måske skabe en helt ny funktionalitet, som kunderne kan bruge.

Sidst men ikke mindst skal du stille krav til hvilket outcome/værdi, du forventer, løsningen skal levere. Det kunne være ’Vi vil minimere gennemgang af et kunde-flow med 30 %’, ’vi vil sænke churn med 10 %’ eller ’vi vil have 1000 nye kunder til at benytte vores nye feature’.

Tak for dansen! 💃 🕺

Endnu mere guf til din hjerne og karriere