02.16.09

Dokument på rätt sätt

Publicerat i Agile tagged , vid 13.01 av Joakim Holm

I mina senaste inlägg har jag velat göra det för troligt att när det gäller att kommunicera, förklara, designa, lösa problem, undervisa och liknande aktiviteter är konversation ansikte mot ansikte vida överlägset att någon skriver och någon annan senare läser ett dokument. Faktum är att vi ofta kan se det sistnämnda som svinn, det vill säga ett slöseri med våra begränsade resurser. Det finns effektivare sätt att kommunicera och få fram det vi vill.

Dokument då, menar jag att de är helt värdelösa? Nej, det är de verkligen inte! Det skrivna ordet har flera fördelar:

  • minne
  • struktur
  • potentiell verifierbarhet

Den viktigaste egenskapen hos dokument är att de utgör ett någorlunda persistent minne. Våra mänskliga minnen klingar som bekant av med tiden och är starkt färgade av vår egen upplevelse och personlighet. Det är till exempel därför vi har för vana att skriva protokoll på viktiga möten.

Dokument har en inbyggd struktur, vilket med fördel kan användas av någon som vill samla sina tankar. Håller mitt resonemang? ”Det luddigt skrivna är det luddigt tänkta”, brukar man ju säga. Jag finner själv skrivandet som ett sätt att tänka igenom och klargöra vad jag tänker och tycker. Dokumentet kan i detta fall givetvis vara en ”mind map”, om man föredrar det.

Till sist kan vissa dokument, uttryckt på formell form, verifieras på ett sätt som inte är möjligt med konversationer. Ett avtal kan till exempel kontrolleras av en bolagsjurist. En testare kan verifiera mot en testspecifikation. Ett dokument i elektronisk form kan användas för att automatiskt verifiera att ett system fungerar som det ska. Vissa dokument kan köras av en dator och kallas då för program.

Hur få ihop detta nu? Det verkar som att jag talar emot mig själv. Min poäng är att vi bör använda dokument på det som de är bra på och slopa dokument på områden där de inte bra. Eftersom dokument är så överskattade råder en kraftig överanvändning av dokument som kommunikationsmedel. Det är ur den aspekten man ska läsa den agila värderingen ”[vi värderar] fungerande mjukvara framför omfattande dokumentation”. Dokumentation är bra (ibland). Överdriven dokumentation är svinn. Svinn kostar pengar.

Inom mitt eget område, systemutveckling, finns tre grundläggande former av dokument:

  1. Arbetsdokument, dokument som tas fram under arbetet för att kommunicera mellanresultat
  2. Leveransdokument, dokument som är del av leveransen till kund
  3. Överlämningsdokument, dokument som krävs för att lämna över arbetet från en grupp människor till en annan, till exempel från ett projekt till en förvaltningsorganisation.

Hur kan vi behandla dessa varianter på ett sätt som utnyttjar vad vi vet om rika kommunikationsformer, men ändå tar bibehåller de goda egenskaperna hos dokument? Jag brukar använda följande tumregler:

  1. Arbetsdokument undviker vi så länge som är möjligt (och lite till). Dessa ersätts nästan helt av minneslappar och konversationer. Här handlar det nästan alltid om att kommunicera och förstå, vilket det finns bättre sätt för.
  2. Leveransdokument behandlas som vilken leverans som helst. Det är en egenskap hos produkten som måste värderas, prioriteras och estimeras som vilken annan egenskap som helst. Fördelen med detta är att det tydligt visar kostnaden av att skriva dokument. Det är inte något som vi bara får ”på köpet”.
  3. Överlämningsdokument skriver vi när vi måste, men den verkliga magin är att aldrig sätta sig i en sådan situation. Om vi inte har några överlämningar behöver vi inga överlämningsdokument. Det här tarvar sin förklaring men det får vänta till en annan gång. Om vi ändå måste skapa överlämningsdokumentation är nästa trick att göra den så rik som möjligt. Varför inte filma den mest erfarne systemutvecklaren när denne förklarar hur systemet fungerar i stället för att låta denne skriva dokument?

Låt mig till sist ge några exempel på hur du kan använda dokument på ett klokt sätt:

  • Om du har en kund som misstror dig eller ditt företag tar du självklart anteckningar på alla beslut, något annat vore oklokt (minne).
  • Skriv ned mål, behov och krav på en superenkel form (1-2 meningar) utan detaljer. Se det nedskrivna som en minneslapp för framtida konversationer (minne).
  • För alla möten som du ska leda eller facilitera, tänk inför mötet igenom målet för mötet, vilka punkter som ska diskuteras och i vilken ordning (struktur).
  • Skriv detaljkrav på system och produkter på en form som kan bindas till systemet självt och exekveras automatiskt av ett testverktyg (verifierbarhet).

Jag önskar bara att jag kunde diskutera detta med dig som har läst ända hit i stället för att skriva det…

02.08.09

Dokument är fattig kommunikation

Publicerat i Agile tagged , vid 15.27 av Joakim Holm

I mitt förra inlägg beskrev jag hur en dispyt lätt kan uppstå vid kommunikation med e-post. Skälet till att det händer så lätt är att vi inte får med oss alla övertoner när vi läser brevet. Vi kan till exempel inte höra personens tonfall eller se dennes kroppsspråk, vilka tillsammans lär stå för över hälften av det som egentligen kommuniceras mellan två parter. På liknande sätt kan vi analysera andra vanliga sätt att kommunicera efter vilka uttrycksmöjligheter som står till buds:

  • Konversation ansikte mot ansikte: Språk, ansiktsuttryck, gester, kroppshållning, tonfall, timing, doft, beröring, spänningsnivå, synkroniserade uttryck, direkt återkoppling, möjlighet till kollaborativt samarbete, med mera.
  • Videokonferens: Språk, ansiktsuttryck, tonfall, timing, direkt återkoppling
  • Telefon: Språk, tonfall, timing, direkt återkoppling
  • Chatt: Språk, direkt återkoppling
  • E-post: Språk, viss återkoppling
  • Dokument: Språk

Med timing avses hur uttryck tidsmässigt passade ihop (t.ex. pauser). Med återkoppling avses mina egna möjligheter att interagera vid rätt tidpunkt, till exempel ställa en klargörande fråga. Kollaborativt samarbete är möjligheten att i stället gå iväg och ställa sig framför en tavla och illustrera tankar för varandra. Doft är kanske inget vi tänker på normalt, men vi vet ju vid det här laget att vi styrs mer av dofter än vi tror. Vi märker det snabbt om någon inte luktar gott.

Ju högre upp på listan, desto fler uttrycksmöjligheter finns det tillgång till. Man kan uttrycka det som att konversation har högre bandbredd för kommunikation än de övriga. Konversation ger möjligheter till en rikare form av kommunikation.

I nedre delen av listan hittar vi kommunikationssätt med lägre bandbredd. Om vi tar bort alla möjligheter (utom språket i sig) som står oss till buds för att skapa en klar och tydlig kommunikation mellan oss hamnar vi på… dokument. Dokument är alltså det sämsta kommunikationsmedlet vi har sett till bandbredd. Det ironiska i sammanhanget är att om vi tittar på vilken status dessa kommunikationssätt har i affärslivet så är ordningen den omvända: Dokument har högst status och konversationer lägst.

Vart vill jag komma med allt det här? Jo, om dokument ger sämst möjligheter att kommunicera kommer vi att få flest överföringsfel på den kanalen. Om kommunikationen till exempel handlar om att förklara något komplicerat för någon annan kommer kommunikation via dokument att leda till flest missförstånd och sämst inlärning. Missförstånd leder i sin tur till omarbete och defekter. Kent Beck har skrivit att man kan spåra de flesta fel i produktutveckling tillbaka till en kommunikationsmiss någonstans. Företaget trodde att kunderna ville ha export till pdf (när de i själva verket uttryckte ett annat behov). Teamet tyckte att produktchefen sa att vi skulle lösa detta med tryckavkänning (när hon egentligen sa att det kunde vara ett sätt att kanske lösa det). Ju rikare kommunikation, desto större chans att vi kan rätta till missförståndet snabbt.

Tillbaka till Roger från det förra inlägget, vilken okunskap uttryckte Roger? Okunskapen sken igenom i denna sats: ”Jag vet att man inte ska skriva dokument när man jobbar agilt…”. Den borde ha lydit: ”Jag vet att man inte ska skriva dokument när det finns rikare sätt att kommunicera…” Det har inte så mycket med agilt att göra eller ej, snarare hur vi kommunicerar med varandra. Hade Roger uttryckt sig på det viset hade han kanske insett att det inte var för att kommunicera bättre som Roger behövde ett dokument i det här fallet utan för att komma ihåg något. Varför skulle Roger inte använda ett verktyg han av erfarenhet vet fungerar?

I mitt nästa inlägg tänkte jag titta lite på några fall där det kan vara motiverat att ta kostnaden för att skriva ett dokument.

02.01.09

Resultat framför dokument

Publicerat i Agile tagged vid 00.38 av Joakim Holm

Jag nämnde i mitt förra inlägg att det är okunskap jag siktar in mig på i mitt förbättringsarbete. Här uttrycker en person, låt oss kalla honom för Roger, en form av okunskap, hittar du vilken?:

”Jag vet att man inte ska skriva dokument när man jobbar agilt, men jag vet också att om jag inte har dokumenterat allt vi beslutat och varför så kommer inköpschefen hacka mig i stycken på nästa styrgruppsmöte. Agila metoder verkar helt orealistiska.”

Låt oss titta närmare på dokumentation och se om vi kan reda ut begreppen.

Många fick tidigt uppfattningen att agila metoder förordade att man inte skulle skriva några dokument vid utvecklingsarbete. Alls. Till detta bidrog ett antal missinformerade artiklar i en kär IT-branschtabloid. Det här är förstås nonsens, agila utvecklare skriver dokument.

Men bakom missuppfattningen finns ändå en kärna av sanning: agila metoder föredrar resultat framför dokument. Stopp och belägg! Är inte dokument en form av resultat? Jo, om du är författare, poet eller journalist, men egentligen inte om ditt mål ligger annorstädes, till exempel att utveckla en produkt eller ett system. Inom områden med stor osäkerhet måste vi leka bergsgetter: Enda sättet att komma uppför berget är att stå säkert, ta små och säkra kliv och ha stort tålamod. I det läget är det konkreta delresultat på väg mot slutmålet som gäller, ett välskrivet dokument är fint men ett på tok för osäkert mått.

Lättrörliga metoder inom systemutveckling ser därför att vi hellre presenterar delresultat av hög kvalitet på väg mot målet i stället för dokument som beskriver hur vi ska göra för att ta oss från A till B. Det här brukar kallas RTF, vilket står för ”Running Tested Features”, ett begrepp som myntades av Ron Jeffries. Att se en del av sitt kommande system exekvera ger nämligen en helt annan och sannare bild av verkligheten än att läsa en rapport. Inte nog med att du som beställare eller användare börjar inse att du faktiskt kommer att få ett system, du får också möjlighet att kommentera det som gjorts och påverka det som ska göras. Ur teamets synvinkel är det nyttigt att tvingas leverera och demonstrera vad man arbetat med och hela processen skapar ett positivt samarbetsklimat.

Det här var ett exempel på hur ett dokument kan ersättas av något rikare, men vad är det då som är så himla dåligt med dokument? I sig är det alls inget fel på dokument. Jag älskar verkligen (fysiska) böcker, till exempel. Jag gillar lukten av dem, känslan att hålla i dem och hur praktiska de är på resan. Problem uppstår när människor använder dokument i fel syfte. Ett exempel: De flesta människor som använder e-post har råkat ut för att hamna i dispyt med en vän eller kollega över något som skrivits i ett elektroniskt brev. Man har skrivit lite slarvigt, tolkat lite fel och svarar med en syrlig kommentar, som i sin tur leder till ett argt svar och så är helt plötsligt cirkusen igång.

Varför uppstår sådant här? Det tänkte jag försöka analysera nästa gång. Då tänkte jag också ge mitt svar på frågorna kring Rogers frustration ovan.