Jeg har arbejdet med mange forskellige agile teams i de seneste 10-12 år. Der er mange, der bruger Scrum, nogle bruger SAFe og Kanban. Men uanset hvad der er ens egen favoritmetode, er der et nøgleprincip, man ikke kan vælge fra. Det er transparens.

Hvorfor er transparens nu så vigtigt?

Hvis man er ude efter at øge agiliteten i sin organisation, sin afdeling, sit team eller projekt, og hvis man vil have løbende forbedringer og blive mere effektive, så er man nødt til at kunne se, hvad der foregår. Det kræver transparens i den bredeste forstand.

Her får du en række eksempler på områder, man bør have helt op i lyset:

• Er det nemt at se hvem, der laver hvad?
• Kan man se om aktiviteter er blokeret, hvorfor de er det, og hvor længe de har været det?
• Er fremdrift ift. jeres sprintmål, projekt, produktmål m.v. visualiseret?
• Er jeres arbejdsprocesser krystalklare?
• Er jeres regler og politikker eksplicitte og synlige?
• Er jeres backlog synlig og let at forstå for andre end jer selv?
• Brydes aktiviteter ned, så det er tydeligt, hvad der skal til for at gennmføre dem?
• Måler i gennemløbstider (lead times), og holder I styr på fordelingen af dem?
• Måler I i det hele taget noget som helst?

Listen kunne fortsættes, men den vigtigste pointe er, at transparens er så meget mere end bare at have en aktivitetstavle (fysisk eller i noget software). Det er kun et meget lille skridt på vejen til fuld transparens.

Der er nogen, der ikke kan fordrage at være transparente

Når jeg diskuterer transparens med teams og det faktum, at transparens er en forudsætning for forbedringer, så får jeg mange forskellige reaktioner. Jeg har mødt ganske mange, der slet ikke kan se fidusen ved at være transparente.

Her får du nogle af grundene til den holdning:

1. Nogle mener, at det kan være helt ligegyldigt. De argumentere med, at de arbejder med deres ting helt uafhængigt af de andre i teamet. De kan ikke dele deres opgaver med andre, så hvorfor dog være transparente?
2. Nogle kæmper imod transparens med næb og kløer. Ofte er det folk, som ikke får helt så meget sved på panden, som deres kolleger. Det vil de gerne skjule. (Ja, de folk findes – du har sikkert også mødt dem).
3. Nogle bryder sig ikke om at vise eller fortælle om deres fejltagelser
4. Endelig er der nogen, der bare slet ikke kan se formålet med at være transparente, og ingen argumenter – selv de mest rationelle ellerrr metodekorrekte – bider på dem.

Sagen er, at man ikke kan gemme sig i et transparent system. Det kan være intimiderende for nogen. Men hvis man er gået “all-in” på at arbejde agilt, så vil man også være en af dem, der synes at det er helt naturligt at være åben og dele informationer med andre. Man deler bl.a. egne fejltagelser som noget helt naturligt,

Først når man har fået de knap så entusiastiske ombord på transparenstoget, bliver det muligt at få det fulde billede af, hvad der foregår i ens agile system. Har man ikke det, så kan man heller ikke vide, hvad der bedst kan betale sig at optimere.

Man kan ikke forbedre noget, man ikke kan se

Løbende forbedringer er et fundamentalt princip i alle agile metoder og frameworks, og når nu man ikke kan forbedre ting, der er usynlige, så må man gøre, hvad man kan for at få disse skjulte ting og sager ud i lyset. Transparens er helt fundamentalt.

En af de væsentligste grunde til, at virksomheder vælger den agile vej er, at man ønsker at effektivisere og sikre hurtigere “time-to-market”. Hvis det skal ske, er man nødt til at fokusere på flow og gennemløbstider.

Det betyder, at man holder øje med, hvordan opgaven flyder gennem de forskellige dele af organisationen, fra det tidpunkt nogen får en ide, som man vælger at forfølge, indtil det øjeblik hvor man står med varen i hånden.

Set fra fra et time-to-market synspunkt er det eneste interessante, hvor lang tid det tager, at udvikle eller producere den nye vare fra ende til anden. Om et enkelt team i værdikæden er hamrende effektivt, betyder ikke særlig meget for gennemløbstiden, hvis resten eller dele af værdikæden ikke er.

Når man kender sine gennemløbstider, så ved man, hvor effektiv man er. Gennemløbstider er ikke baseret på mavefornemmelser, krystalkugler eller vilde gæt. De viser virkeligheden baseret på konkrete data.

Med andre ord, så er gennemløbstider det mest meningsfulde, man kan måle på, hvis ellers man ønsker at vide præcis, hvor effektiv man er. Og det gør man selvfølgelig, hvis man vil være mere agil.

Når man begynder at måle sine gennemløbstider, så får man som regel nogle uventede overraskelser. Her får du nogle typiske eksempler:

• Du og dit team er måske ikke helt så effektive, som I gik og troede
• Mange aktiviteter bliver blokeret af mange forskellige grunde. Det forstyrrer jeres flow
• Jeres arbejdsprocesser virker ikke optimalt, og understøtter ikke det I arbejder med
• Mange har nogle kedelige vaner. De multi-tasker og hopper mellem forskellige opgaver. Det koster dyrt på jeres gennemløbstider
• Mange flaskehalse resulterer i lange ventetider og (igen) længere gennemløbstider

Sådan er det faktisk mange steder, men nu har I v.h.a. den styrkede transparens mulighed for at vurdere, præcis hvor det bedst kan betale sig at sætte ind og forbedre det, der ikke virker optimalt.

At måle giver transparens over team-effektivitet

Når jeg diskuterer metrikker med agile teams, så er et af de argumenter, som jeg hører igen og igen dette her: “Vores chefer vil jo have, at vi estimerer, og når nu vi gør det, så er der jo ingen grund til også at måle gennemløbstider”.

Intet kunne være mere forkert, og jeg kan simpelthen ikke lade være med hver eneste gang at spørge dem: “OK, men er jeres estimater altid så præcise, at I kan stole på dem?”. Uden undtagelse, så svarer de: “Nej, aldrig”.

Jeg kan sagtens forstå, at det er nødvendigt at have en indikation af, hvor lang tid det vil tage at gennemføre et bestemt projekt eller producere en “klump værdi”, men jeg synes, at det er svært at forstå, hvorfor man bliver ved med at bruge dage og timer på at estimere, hvis ens estimater alligevel altid rammer ved siden af.

Gennemløbstider er ikke et “bulls-eye”, det er en fordeling. Når man har målt sine gennemløbstider selv over en kortere periode, så begynder man at kunne give nogle relistiske løfter baseret på evidens med basis i kolde data.

Når man ser på, hvad man tidligere har præsteret, vil man se noget i denne retning: Hvis intet forstyrrer fremdriften, kan man gøre en given aktivitet færdig på X dage. Hvis alt driller, tager det Y dage. Man kan også regne sig frem til, at med 85% sandsynlighed kan man være færdige på Z dage. Det giver en ganske robust prognose.

Det vil føre for vidt at tage aktivitetskategorier, serviceklasser m.v. op her, men jeg håber, at princippet om at bruge evidensbaserede gennemløbstider i stedet for krystalkuglebaserede estimater står klart frem.

Der er andre ting man kan måle på for at skabe transparens. F.eks.:

• Gennemløb (hvor mange aktiviteter har man gjort færdige i måleperioden)
• Flow-effektivitet (hvor mange timer/dage arbejder vi aktivt på aktiviteten i forhold til den tid det tager at gennemføre den fra start til slut)
• Blokeringer (hvor mange er der, hvorfor opstår de, hvor længe er aktiviteterne blokeret)

Disse målinger fortæller en masse om både team-effektiviteten og hvor effektiv organisationen arbejder på tværs af teams. Og så er det ikke engang særlig besværligt. Men hvis man kun skulle måle en enkelt ting, så er det gennemløbstider.

Der er flere forhindringer for at skabe transparens

Selvom de fleste nok kan blive enige om, at transparens er en nøglefaktor i agile systemer, så betyder det ikke, at det er nemt at opnå. For det første kræver det et vist mål af disciplin, f.eks. i forhold til at følge de agile processer, overholde de regler, man selv har været med til at lave, og ikke mindst følge op på fremdrift. Den disciplin er bare ikke altid til stede.

Disciplin er faktisk altid en naturlig ting i modne teams og organisationer, for hvordan skulle man ellers vide, hvor man var, og hvad der kan forbedres. Det er bare ikke en naturlig ting i mindre modne teams m.v., så det skal der arbejdes med.

Hvis man arbejder med udisciplinerede teams, så er man nødt til at fokusere på at ændre de eksisterende mønstre og vaner, så man kan indarbejde nogle mere modne af slagsen.

Det jeg har set fungere bedst er, hvis man kan blive meget eksplicit omkring, hvad man forventer af folk. Fortæl dem præcis hvad de skal gøre anderledes, hvorfor de skal gøre det, og hvad de selv får ud af det. Det er nemmere at forandre noget, man kan forstå.

Transparens kommer desværre ikke automatisk, men det er noget man skal jagte målrettet. I et transparent system er det nemlig helt indlysende, hvor der ligger forbedringer, der bare venter på at blive samlet op.

Disse forbedringer fører til højere agilitet, og var det ikke det, der var meningen i første omgang?