Read this blog post in English
Vi skal have noget mere ud i den ene ende, så vi kaster da bare noget mere ind i den anden ende, ik’?!?
Det er en gennemgående tendens, at man vil forsøge at optimere processer ved at ressourceoptimere, og i mange tilfælde, begynde at kaste flere ressourcer ind i kampen. Behovet vi forsøger at indfri med ressourceoptimering, er dog ikke nødvendigvis relateret til vores medarbejders udnyttelsesgrad, men mere et ønske om at skabe flow i vores udviklingsproces. Eller som det oftest vil blive italesat – vi vil gerne se flere resultater og gerne hurtigere. I denne artikel, vil jeg argumentere for at ressourceoptimering ikke nødvendigvis er vejen frem, hvis du vil sikre et godt flow for din produktudvikling. For at kunne fokusere på flow, er vi dog først nødt til at forstå forskellen mellem ressourceoptimering og flowoptimering.
Udfordringen er at vi glemmer det primære kundebehov, vi forsøger at indfri, og i stedet fokuserer vi på, at alle tandhjul kører med fuld kraft.
Som nævnt fokuserer mange organisationer på ressourceoptimering, hvilket indikerer at vi bruger megen energi på at sikre, at vi får størst mulig udnyttelse ud af vores ressourcer. Selvom den tanke lyder yderst attraktiv, er det ikke nødvendigvis et succeskriterie at stræbe efter. Udfordringen er at vi glemmer det primære kundebehov, vi forsøger at indfri, og i stedet fokuserer vi på, at alle tandhjul kører med fuld kraft. Paradoksalt skaber for stort et fokus på ressourceoptimering merarbejde, lange gennemløbstider og tab af kontrol.
Dette er også kendt som effektivitetsparadokset,som netop beskriver hvordan ressourceoptimering ser attraktivt ud fra et virksomhedsperspektiv, men kan skabe større problemer fra et kundeperspektiv.
Flow-optimering handler derimod ikke om vores ressourcer, men om vores evne til at optimere gennemløbstiden for den kundeværdi vi ønsker at skabe med vores udviklingsproces. Flow-optimering sætter altså kundeværdien i fokus. Tænk på et kundebehov som en flow-enhed der skal gennem vores udviklingsproces. I flow-optimering fokuserer vi på, hvordan vi hurtigst muligt kan indfri et kundebehov. Det handler altså ikke om at alle vores medarbejdere har nok at lave, men at vi sikrer et flydende flow i at levere værdi til vores kunder. Med andre ord, vi kaster vores fokus på at optimere gennemløbstiden for en flow-enhed i vores udviklingsproces.
Der er selvfølgelig en balance mellem ressource- og flow-optimering. Vi ønsker ikke at medarbejdere sidder på deres hænder, men vi skal også sikre at en flow-enhed faktisk bliver fulgt til dørs. Det er en balance vi kontinuerligt skal være opmærksomme på, når vi produktudvikler.
Et produktteams evne til at skabe flow i en udviklingsproces handler i høj grad om deres evne til at stabilisere en proces i et uforudsigeligt miljø.
Produktudvikling er komplekst, og involverer typisk at man skal tage hensyn til mange forskellige mennesker, teknikker og omkringliggende afhængigheder. Et produktteams evne til at skabe flow i en udviklingsproces handler i høj grad om deres evne til at stabilisere en proces i et uforudsigeligt miljø. Nedenfor finder du en række initiativer, der kan hjælpe dig og dit udviklingsteam med at skabe flow.
Værdistrømmen udgør de handlinger der finder sted ud fra et behov, som bliver registreret indtil behovet er indfriet. Det kan virke overflødigt at skulle udpensle ens værdistrøm, for den kender vi jo alle sammen. Men der sker noget magisk, når vi investerer tiden i det. Pludselig bliver vi opmærksomme på unødvendige handlinger i vores udviklingsflow, som vi i virkeligheden helst ville være foruden.
I nogle tilfælde bliver vi også opmærksomme på handlinger, som faktisk mangler for at vi kan indfri det ønskede behov. Øvelsen handler om at skabe en selvindsigt, som gør os i stand til at optimere vores flow. Rent lavpraktisk kan udforskningen af værdistrømme udarbejdes i workshops med repræsentanter fra hele værdistrømmen. Husk dog, at dette ikke nødvendigvis er en engangsting.
Det kan være værdifuldt løbende at genbesøge værdistrømme, da vores omverden hele tiden ændrer sig. Man bør stræbe efter at sikre, at der ikke opstår unødvendige variationer for vores udviklingsteams. Fx ved at ændre teamsammensætningen bare fordi det ser godt ud på papiret, hvor der står at vi har sikret høj udnyttelsesgrad af vores ressourcer.
Variationer er faktorer der enten påvirker vores betjeningstid eller vores leveringstid. Årsagen til variationer kan være uendelig, og næsten umulig at forudse. Variationer opstår især, når der er mennesker involveret, da vi tænker og handler meget forskelligt. Samtidig er variationer også svære at undgå, når man ikke kan forudse hvad der kommer til at påvirke vores udviklingsflow. Et eksempel på variation under produktudvikling kan være stor udskiftning af fagligheder i dit udviklingsteam.
Hver gang en profil enten forlader eller tilføjes til et udviklingsteam, skal der opbygges nye dynamikker, viden og praktikker som alt sammen påvirker gennemløbstiden af den kundeværdi vi ønsker at levere. Et andet eksempel, der kan give tilbagevendende hovedpine, er eksterne afhængigheder. Det er tæt påumuligt at undgå denne form for afhængighed, men vi kan sikre at der ikke opstår unødvendige eksterne afhængigheder. Så udforsk gerne din værdistrøm for at finde de steder, hvor du måske har unødvendige eksterne afhængigheder.
Som nævnt ovenfor er det næsten uundgåeligt at blive ramt af variationer i udviklingsprocessen, ligemeget hvor gode vi har været til at reducere dem. I disse tilfælde handler det om vores evne til at håndtere de variationer der måtte komme, og sikre en minimumpåvirkning på vores flow. For at sikre en minimumpåvirkning af variationer, så er det vigtigste at man har etableret rutiner. Rutiner sikrer en stabilitet i vores miljø og proces, men vi skal være opmærksomme på at vores rutiner er i et format, der kan håndtere variationer.
Det gode ved procesrammeværktøjer, såsom Scrum, er at de skaber en naturlig rutine i vores flow, men samtidig tillader at variationer bliver håndteret. Scrum giver f.eks. teamet mulighed for at arbejde med teamdynamikker og -praktikker løbende, så der opstår et stærkt fundament, som kan håndtere pludselige ændringer i teamsammensætningen. En af de måske mest velkendte variationer i produktudvikling, er ændringer i omfanget af de opgaver, vi har forpligtet os til fra start. Scrum kan ligeledes være med til at sikre at pludselige ændringer i opgaveomfang bliver håndteret, uden at det har en stor indvirkning på vores flow.
Dette skyldes at man kører i iterationer, og med korte intervaller er man i stand til at skifte retning. Om man kører Scrum, Kanban eller noget helt tredje, så handler flow-optimering om at skabe et stabilt miljø for dit udviklingsteam, som samtidig kan håndtere de uforudsete variationer der måtte opstå. De ultimative rammer for et stabilt miljø er rammer, hvor vi er i stand til at tage ved lære løbende, når vi håndterer uforudsete variationer, så det får endnu mindre indflydelse på vores flow i fremtiden.
Der er en gennemgående tendens, at vi er overambitiøse med vores tid og fokus. Sjovt nok, er det ikke kun lederne der ønsker at vi har mange bolde i luften samtidig, men realiteten er at vi også selv ret slemme til det. Vi bør forsøge at fokusere på en begrænset mængde opgaver ad gangen. I sidste ende, er det bare nemmere at jonglere 3 bolde end 30 bolde.
En dejlig bivirkning ved at holde fokus på lidt ad gangen, er at vi faktisk får færdiggjort vores opgaver, og dermed sikrer flowet i værdistrømmen. Et initiativ kunne være at arbejde med en Work in Progress (WIP) Limit, der skal sikre at dit udviklingsteam ikke sætter for mange opgaver i gang, før de har færdiggjort de allerede igangsatte opgaver. Hvis du vil læse mere om WIP limits, så kan jeg anbefale denne side: Work in Progress Limits.
For nogle medarbejdere er det næsten en del af deres DNA, at afvente at nogen kommer og fortæller hvad de skal lave. Og for mange managers er det set som en af deres vigtigste opgaver at delegere opgaver til deres udviklingsteam. I virkeligheden er denne form for push af opgaver meget ineffektiv, når vi forsøger at lave flow i vores udviklingsproces. Med push skaber vi flaskehalse, siloer og unødvendige ventetider – eller sagt med andre ord: det skaber ineffektivitet.
Push opbygger en kultur hvor medarbejderne bliver handlingslammede, og er bange for at tænke selv. Gå hellere efter at skabe en kultur og en rutine, hvor teamet selv trækker på deres opgaver – pull-baseret udvikling. En effektiv måde til at gøre dette i praksis er ved at opsætte en Produkt Backlog, hvor teamet selv er ansvarligt for at oprette og modne deres opgaver, baseret på den kundeværdi de forsøger at indfri. I virkeligheden er teammedlemmerne de bedste kandidater til netop den opgave, da det jo er dem der er specialisterne og skal udføre arbejdet.
Som managers skal man ”bare” sikre at prioriteringen er på plads, og at den prioritering og retning er tydelig for teamet. Når et teammedlem er færdig med et stykke arbejde, så trækker vedkommende den næste opgave fra produkt backloggen ind i udviklingsprocessen. Og ved du hvad? Det kommer til at føles helt naturligt for teammedlemmet, da det er dem selv der har været med til at oprette og modne opgaven, så vedkommende ved præcis hvor de skal starte og hvordan.
En af de helt store forhindringer, når vi snakker om flow, er overleveringer eller afhængigheder mellem forskellige fagligheder. Ofte er organisationer opbygget i siloer af fagligheder, hvilket helt naturligt skaber overleveringer og afhængigheder på kryds og tværs. Og hvis organisationen samtidig har fokus på ressourceoptimering, så er disse afhængigheder også faretruende skrøbelige.
Hvis udnyttelsesgraden er 100% hos alle medarbejdere, så er der stor risiko for at forskellige fagligheder slet ikke er i stand til at håndtere overleveringer. Stræb i stedet efter at sammensætte de nødvendige fagligheder der skal til, for at levere en ønsket kundeværdi. Det er ikke nok, at vi får opbygget gode relationer mellem de fagligheder. Vi skal sørge for at faglighederne bliver en del af samme produktteam som arbejder sammen på en værdistrøm. I samme omgang får du også skabt nogle synergier mellem fagligheder, som sikrer at udviklingen flyder mere naturligt.
Et sidste tip er at synliggøre vores opgaver, så det er helt klart og tydeligt hvad vi arbejder på, og hvornår vi arbejder på det. Denne form for transparens gør det muligt for udviklingsteamet at koordinere løbende om igangsatte opgaver og sørge for at initiativerne hele tiden er i gang. Den nemmeste måde at skabe fremdrift på udviklingsopgaverne er ved brugen af et Kanban board. Det gør opgaverne synlige, og gør os i stand til at følge gennemløbstiden. Samtidig kan vi pludselig også arbejde meget aktivt med en Work in Progress Limit. Og lad os bare indse det...Det føles jo ret fantastisk at flytte en opgave over i ‘done’, når man er færdig med den.
Nu vil jeg gerne udfordre dig til at prøve minimum én af ovenstående initiativer.
Nu har du læst lidt om nogle forskellige initiativer, som i min optik kan være med til at skabe flow i produktudvikling. Nu vil jeg gerne udfordre dig til at prøve minimum én af ovenstående initiativer. Du behøver ikke nødvendigvis at starte med alle initiativerne på én gang, men du kan måske starte med en enkelt som passer til din situation, og efterfølgende evaluere om det gav værdi.
Men sørg for at komme ind i en rutine med initiativerne, så det bliver en naturlig del af jeres udvikling og mindset. Først når det virker naturligt for jer, vil I kunne se den fulde effekt af initiativet. Og husk, et forsøg eller to for at optimere på ens flow, er der sjældent nogen der vil se som en dårlig idé.