Dokumentation?

Det agila manifestet för mjukvaruutveckling säger att man bör värdera fungerande mjukvara framför utförlig dokumentation. Slarviga läsare har tagit den raden som skäl att strunta i allt vad dokumentation heter, och ängsliga processmänniskor har tagit raden som skäl att bli oerhört tveksamma till metoder som kallar sig "agila". En process som inte förskriver precis vilka dokument som behövs kan ju inte vara en bra process, eller hur?

Men som sagt: Agilt är ingen process eller beskrivning av en metod. Agilitet är en egenskap ett samarbete kan behöva (tillsammans med slankhet, styrka och uthållighet) för att bli smidigt. För att kunna tackla frågan om dokumentation behöver man förstå varför manifestets undertecknare skrev som de gjorde.

Vad är syftet? Detta är alltid den första frågan. Att undra över hur man gör (t ex med dokumentation) är en signal om att man kanske inte har målet riktigt klart för sig.

Syftet, slutpunkten i alla värdeprocesser, är alltid minst en människa som blir glad över något. Vilka ska använda dokumentationen? Till vad?

När det gäller tjänster (och fungerande mjukvara är en tjänst) finns det två huvudsakliga lägen: du utvecklar tjänsten, och du utför tjänsten. Det agilister och lean-folk har upptäckt är att precis, kortfattad och lättförståelig dokumentation är nödvändig för att kunna utföra tjänsten rätt. En processbeskrivning gör att vi inte brakar ihop när läget blir pressat. Vi vet hur matbiten ska stekas, vi kan söka upp det kodstycke där felet i inloggningsrutan troligen finns, vi vet att krutladdningen som ska spränga bort dörren och blåsa upp flygplanets nödrutschbanor faktiskt är apterad. "Cabin crew: arm slides! Cross-check and report!"

Så dokumentation över hur saker fungerar ingår i tjänsten som utvecklingen levererar. Ingen tjänar på att den är extensiv och sitter i tjocka pärmar eller ligger på ett intranät. Däremot att den är lätt att hitta och hitta i. Planschprincipen, att all processdokumentation ska sitta i form av planscer på väggarna, ett ögonkast bort, är ett sätt. Människan som behöver dokumentationen behöver den fort, i en form som är anpassad för hennes hjärna.

Men hur är det med dokumentation för att utveckla själva tjänsten? Här brukar det finnas mycket att tjäna. Som det heter i den här utmärkta vägledningen för agil dokumentation: "Well-written documentation supports organizational memory effectively, but is a poor way to communicate during a project."

Det visar sig nämligen att tjänster i osmidiga organisationer gärna utvecklas i silos, att olika discipliner sitter på varsin kammare och klurar på sin del. Delarna lämnas sedan över till nästa kammare, och nu måste dokumentationen vara mycket omfattande för att informationen ska kunna klara av denna överlämning utan att sippra bort.

Men ändå sipprar det bort, för information överförs inte bäst med hjälp av dokument. Att utveckla en tjänst är att samla in, raffinera, och slutligen - vid behov - kodifiera denna kunskap. Det gäller mjukvara (mjukvara är kodifierad kunskap) och det gäller arbetsrutiner vid en hotellreception. Bäst på kunskapsraffinering är de som har de effektivaste flödena för att göra gemensamma insikter.

Gemensamma insikter görs i dialog. Riv upp alla silos där det går och svärma runt det som ska utvecklas. Om ni måste ha olika avdelningar med tillhörande överlämningar: ta bort all dokumentation som bara finns där för att stödja överlämningen. Ersätt den enkelriktade överlämningen med täta dialoger, och låt den skriftliga dokumentationen bli till i ett gemensamt avdelningsöverskridande samarbete om samma dokument. Och det är alltid de som ska utföra nästa steg i raffineringen som vet vad som behövs; information ska alltså inte tryckas fram i systemet utan efterfrågas från de som ska göra jobbet.

Ni har själva insikten om vilken dokumentation ni behöver. Det gäller bara att våga nöja sig med den.

Bilden föreställer processdokumentationen hos en av mina kunder, publicerat med tillstånd. Så snart man på ett förbätringsmöte/retrospektiv beslutat om att testa en liten förändring av processen (PDca) sätter man en handskriven post-it med den nya varianten rätt på väggen, där man önskar förändringen. Så snart man beslutat om att permanenta förändringen (pdCA) skriver man ut ett papper och förändrar dokumentationen. Planschprincipen, "Standardized work", och "Visual management" i ett kompakt litet smidigt nötskal.