Vanedyrets udfordringer

Vaner er et produkt af forbindelser i hjernen. De forbindelser, som vi bruger ofte forstærkes og kan ende i vaner, mens andre, som ikke bruges, kan visne bort og forsvinde.

Jeg ved, uden at vide det, hvordan jeg cykler. Det er en vane. Jeg gør det bare. Men at afvænne sig med at cykle er slet ikke nemt. Destin fra SmarterEveryDay.com lærte sig selv at cykle på en omvendt cykel, hvor styret drejede modsat end normalt. Det tog ham otte måneder at lære sig denne nye vane.

Det samme gør vi hver eneste gang, hvor vi introducerer nye idéer i en organisation. Nogle er lette og ligetil, man kan kalde dem for aha-oplevelser, hvor alting går op i en højere enhed, mens andre tager tid og tilvænning. At skabe (gode) vaner er ikke ligetil. Det er hårdt arbejde. Det er som at betræde nye stier i Amazonas jungle, hvor ingen før har sat sine fødder. Første gang er det svært, anden gang (meget) lidt lettere, men efter tusinde gange, så det netop blevet en vane.

Vi skal derfor ikke rynke på næsen af dem i organisationen, som vi ikke synes er omstillingsparate. For det er de ganske givet. Det tager dog bare tid. Menneske er og bliver et vanedyr. Og et flokdyr. Så derfor er det vigtigst, at nogen går forrest og baner vejen.

Det er hjælperytteren, som tager det tunge slæb, så det bliver nemmere for alle de andre. Og gør dem til en succes.

Uvaner ved daily stand-ups ​

Vi har alle været der. Elendige stand-ups, som blev brugt på alt og ingenting, på samme tid. Men hvad kan vi gøre for at få mere ud af det mest centrale element i scrum? Jeg har seks ting, som du skal være opmærksom på.

I – Mødet er forsinket
Vi står der, størstedelen af teamet, og vi venter på, at de resterende teammedlemmer dukker op. Allerede der skaber vi idé om, at mødet er ligegyldigt. Mødet er timeboxed, og eventuelle forsinkelser vil påvirke dine teammedlemmers andre gøremål, hvis mødet skrider i den anden ende. Derfor skal mødet holdes til og indenfor tiden.

II – Een person leder mødet
Et af de mest centrale elementer i agil udvikling er at øge selvledende teams. Et problem med de fleste gruppedynamikker er, at det ofte bliver en enkelte person, ofte Scrum Master-rollen, som kommer til at lede daily stand-ups. Mødet er alles møde, og skal derfor ikke ledes af den samme hver gang. Lad det gå på omgang.

III – Daily stand-up som planlægningsmøde
Mødet er ikke et diskussionsforum eller planlægningsmøde, hvorfor det ikke skal bruges til at diskutere, indføre nye ideer eller ændre i eksisterende planer. Problemer, som kræver mere opmærksomhed, bør tages udenfor dette forum. Spild ikke tiden ved at diskutere løsninger. Dette kan gøres efter mødet.

IV – Daily stand-up som statusopdateringsplatform til lederne
Mødet er ikke en afrapportering til lederen og/eller Scrum Masteren. Mødet er til for at fortælle om fremdrift på opgaver og (vigtigst) fremhævelse af evt. problemer, som forhindrer selvsamme fremdrift.

V – Der bliver ikke lyttet, kun talt
Af og til er nogle teammedlemmer så målrettede i deres egen opgaveløsning, at de kun lytter til sig selv. Daily stand-ups er ikke for den enkelte, men for teamet som helhed. Hvis du har et problem, så er det teamets problem. Vi skal lytte og hjælpe, hvor vi kan.

VI – Følg altid samme mønster.
Sidst, men ikke mindst, så er det vigtigt, at mødet forløber efter samme mønster hver gang. Det gør mødet trygt, og vi kommer hurtigere frem til sagens kerne. Mødet er timeboxed. Brug det fornuftigt.

Fake it!

 Fake it till you make it!

Sætningen er en floskel. Men den er fortsat aktuel, især når det kommer til at afprøve nye idéer.

Når du sidder i en udviklingssituation, er hypoteser og fast helt fundamentalt. Du skal nemlig ikke spilde tiden med at udvikle noget, der ikke giver værdi i det lange løb. Du skal fake it!

Hvis dit produkt tager et halvt år at bygge, og 90 % skal være færdigbygget før det kan testes, så vil det tage knap fem en halv måned førend du kan finde ud af, om du har ramt rigtigt eller forkert. Det er er dyrt, ikke smart og giver ingen mening.

Men der skal typisk ikke særlig megen effort til, før du kan teste dit produkt, og det er typisk lettere at bygge end du måske tror. Nogle teorier foreskriver, at du kan bygge en prototype og teste den på blot to dage. To dage! Den har kostet dig ganske lidt og derfor, hvis den fejler, er den ikke dyrt at smide ud.

Derfor er test af en facade vejen frem. Hvis du eksempelvis skal udvikle en webshop, så kan du teste den via PowerPoint- eller Keynote-slides med aktive knapper. Det samme kan lade sig gøre, hvis du skal udvikle en afstemningsrapport for dine forretningspartnere. Den faglige korrekthed i data kan ikke testes via en facadebaseret prototype, men du kan få testet om brugerfladen er som kunden ønsker.

Du kan selvfølgelig sagtens bygge en mere realistisk prototype, men det vil tage meget mere tid, og derved længere tid før du finder ud af, om du er på rette vej. Men lad os være ærlige – ikke alle idéer er vinderidéer. Uanset om du løber en risiko med en fed idé, og du er bare ikke sikker på dit produkt, så er det bedre at finde ud af om idéen virker så tidligt som muligt. At spilde tid på forkerte ting er no go.

Frit fortolket over udviklingsgrafer fra Sprint (2016) af Jake Knapp et al., s. 167