samarbejdets problem

Sagen med samarbejde er, at det aldrig ser ens ud to gange. To mennesker der renoverer et køkken kører på mavefornemmelse og øjenkontakt, et filmhold på fyrre synkroniserer gennem hierarki, fagsprog og en sund frygt for overarbejde, et udviklerteam på fire kører på pull requests og det vage håb om at alle har læst specifikationen. Hver især en form for samarbejde der ikke ville overleve de andres proces.

form og ramme

Det man lægger mærke til, når man ser efter længe nok, er at formen altid følger konturerne af arbejdet og menneskerne der udfører det. En designer arbejder ikke i tickets, en strateg tænker ikke i sprints, en kunde er ligeglad med dine kolonnenavne. Samarbejdet finder sin egen form, og når den form bliver påtvunget udefra, begynder det egentlige arbejde at finde vej udenom - gennem DMs, emailtråde og “hurtige opkald” der burde have været opgaver.

De fleste projektstyringsværktøjer starter fra den modsatte antagelse, at der findes en korrekt form, en universel én, og at værktøjets opgave er at levere rammen. Det er forståeligt - man kan ikke bygge software til noget man ikke har defineret - men det skaber en underlig effekt hvor værktøjet begynder at generere sin egen slags arbejde. Standups, statusopdateringer, ugentlige rapporter. Ritualer der eksisterer for at håndtere afstanden mellem arbejdet og de mennesker der går op i det.

afstanden

Se på hvordan denne afstand fungerer i praksis. En udvikler færdiggør en feature, en projektleder skriver et resumé, kunden læser det og stiller et spørgsmål, projektlederen videresender spørgsmålet, udvikleren svarer, projektlederen videresender svaret. Hvert skridt er en oversættelse, hver oversættelse mister troværdighed, og hele kæden eksisterer fordi værktøjet holdt kunden på armlængdes afstand fra arbejdet til at begynde med. Rapporteringen koster den samme energi som selve arbejdet, og ingen stiller spørgsmålstegn ved det fordi alle antager at det bare er sådan tingene er.

flydende design

Spørgsmålet ved roden af Balladic var hvad der sker når man nægter at påtvinge en form - når platformen forbliver adaptiv nok til at lade struktur vokse frem af det teamet rent faktisk gør, så en kunde ser arbejdet uden at nogen skal pakke det ind for dem, og automatisering klarer ceremonien mens mennesker fokuserer på vurderingerne.

Det er her kolonneeffekter kom fra, der udløses når arbejde bevæger sig gennem stadier, og hvorfor augments eksisterer til at klikke fast på et projekt når det har brug for dem og forblive fraværende når det ikke har, og hvorfor feedet rangerer efter vigtighed og kontekst fremfor kronologi, da det der skete sidst sjældent er det der betyder mest. Delene har alle eksisteret før; det der ændrer sig er kompositionen, og det underliggende væddemål om at et værktøj der holder sig i baggrunden og tilpasser sig vil tjene flere former for samarbejde end ét der foreskriver en enkelt måde at arbejde på.

ærlighed

Vi bruger Balladic til at bygge Balladic, hvilket er den eneste ærlige måde jeg kender til at teste om et værktøj rent faktisk understøtter arbejde eller blot organiserer udseendet af det. Hvis afstanden vokser mellem det der sker og det der er synligt, mærker vi det med det samme, og den feedback-loop har formet enhver beslutning om hvad platformen gør og - oftere - hvad den nægter at gøre.

Byg det til dig selv, og se så om det holder når andre medbringer deres egen form.