Hvorfor lykkes nogle teams uden detaljerede krav?

Hvorfor er det, at nogle teams kan have succes med upræcise krav, mens andre fejler på trods af lange specifikationer? Hvad er det der driver behovet for detaljer i kravspecifikationer?

Der er udviklingsteams som har kunnet udvikle og videreudvikle løsninger med stor succes uden at skrive krav ned i detaljer. De har kunnet lave løsninger i årevis uden enkeltstående acceptkriterier. De har muligvis bare haft en featureliste, som de har arbejdet ud fra. Så hvorfor kan alle vi andre ikke gøre det samme? Hvorfor skal vi bruge så meget energi på at afdække og beskrive krav?

En fortælling om implicit fælles forståelse

Jeg startede mit arbejdsliv i et team, som sjældent skrev krav ned i detaljer, uden at det havde en nævneværdig negativ indvirkning på vores succes. Konsekvensen var også at vi havde meget begrænset dokumentation. Dengang havde jeg ikke prøvet andet, så jeg tænkte ikke over det. I dag så kan jeg konstatere at jeg ikke har oplevet den situation siden. Mangelfulde kravbeskrivelser har bare siden været et diskussionsemne som har været centralt i alle teams jeg har arbejdet i.

Så hvad gjorde netop mit første team unik? Vi var et lille stabilt vedligeholdelsesteam med en kerne af medarbejdere, som havde arbejdet med produktet i årevis. Der var næsten ikke den afkrog af systemet, som teamets mest erfarne udviklere og forretningsanalytikere ikke kendte. Vi havde ingen dedikerede testere. Specificerede du løsningen, så testede du den også.

Beslutningstagerne var en afgrænset gruppe som havde arbejdet med produktet i årevis og havde en høj grad af forretningsmæssig viden på området. Og så var det et produkt hvis brugergrænseflade udelukkende skulle servicere en begrænset gruppe af brugere.

Vi havde relativt høj grad af implicit og sand fælles forståelse i teamet og med vores nærmeste interessenter. Graden af fælles forståelse faldt i takt med at dele af driften og vedligeholdelsen blev outsourcet. Manglen på dokumentation var en gæld der for alvor blev synlig, og var medvirkende årsag til at de driftsforstyrrelser som vi blev ramt af, blev mere alvorlige.

Hvad er fælles forståelse?

Martin Glinz og Samuel Fricker satte i 2015 ord på det mit første team oplevede [1]. De skelner mellem den eksplicitte fælles forståelse, som vi finder i nedskrevet dokumentation, kravspecifikationer, modeller og prototyper, og implicit fælles forståelse som består af den viden, antagelser og værdier, som vi deler uden at have skrevet den ned.

En vigtig skelnen er hvorvidt vores fælles forståelse er sand eller falsk. Sand fælles forståelse betyder, at vi reelt forstår det samme. Falsk fælles forståelse betyder, at vi tror vi forstår hinanden, men faktisk tager fejl eller har misforstået hinanden. Falsk fælles forståelse er farlig for os som teams, da det er den der betyder, at vi arbejder i forskellige retninger eller misforstår behovet.

I mit første team havde vi en høj grad af sand implicit fælles forståelse. Problemet opstod, da vores outsourcingpartnere begyndte at tage beslutninger baseret på antagelser, som viste sig ikke at holde. Med denne oplevelse i bagagen kunne jeg se hvordan jeg selv begyndte at bruge mere energi på at lave detaljerede specifikationer.

Glinz og Fricker gør op med illusionen om at vi kan specificere os ud af problemet. Det er hverken praktisk muligt eller økonomisk rentabelt at arbejde os frem til fuld eksplicit fælles forståelse. Derfor bliver vi nødt til at læne os op ad en vis grad af implicit fælles forståelse. Spørgsmålet er altså ikke om vi benytter os af implicit fælles forståelse, men hvor stor risikoen er og hvilken risiko vi vil acceptere.

Hvad betyder det for moderne produktudvikling?

Når vi samler midlertidige teams for at udvikle et nyt produkt, så har vi altså brug for at sætte noget andet i stedet, når vi ikke har en høj grad af implicit fælles forståelse at læne os op ad. Derfor kan vi have behov for at dokumentere krav mere eksplicit og i flere detaljer. Det gør sig især gældende jo mere vi deler rollerne op og jo flere mennesker vi involverer.

Betyder det så, at vi skal have alle vores krav beskrevet i detaljer? Nej, det gør det faktisk ikke. Vores udfordring er at skabe mere sand fælles forståelse. Det er mindre vigtigt om den er implicit eller eksplicit. Hvis vi kan skabe en højere grad af implicit fælles forståelse igennem samtale, så er det mindst lige så valid en fremgangsmåde som detaljerede specifikationer.

Samtalen var en af Ron Jeffries' pointer med de 3 C'er: Card, Conversation og Confirmation [2]. Her er samtalen den ingrediens der flytter os fra behovet til en løsning der kan implementeres. Det er ikke nødvendigvis en samtale som klares på et enkelt refinementmøde, det kan kræve flere iterationer, afprøvninger og observationer, inden vi når frem til den fælles forståelse.

Udviklingen mod lange user stories som bliver til specifikationer med detaljeret krav, er ikke en udvikling Ron Jeffries er begejstret for [3]. Hvilket jeg godt kan forstå. Det er min personlige erfaring, at det nogen steder har udviklet sig til en kontrakt, som vi slår hinanden i hovedet med. Værst bliver det når alle ændringer minutiøst logges i selv samme user story. Det er ikke ligefrem godt for samarbejdet, og det ligger meget langt fra det simple format som opstod hos Connextra omkring 2001 (ofte krediteret til Rachel Davies), og som Mike Cohn siden populariserede [4].

En risikobaseret tilgang

Glinz og Fricker lister de faktorer, der muliggør implicit fælles forståelse. Fælles domæneviden opbygget over år, et stabilt team med en historik af fælles succeser, gensidig tillid, nærhed i både geografi og kultur, og en lille, afgrænset kreds af beslutningstagere. Sjovt nok så er der flere sammenfald med beskrivelsen af mit første team.

Tilsvarende er deres liste over forhindringer en beskrivelse af, hvad der siden skete. Udskiftning i teamet, opdeling af roller, flere involverede mennesker og outsourcing af opgaver til folk uden den delte historik.

Faste skabeloner eller en Definition of Ready er altså ikke vejen frem, for de behandler alle krav ens, uanset hvor meget fælles forståelse der allerede findes.

Så i stedet bør vi vurdere de parametre der påvirker vores fælles forståelse og vurdere vores risikoprofil. Ud fra de oplysninger kan vi tage stilling til, hvordan vi bedst fastlægger detaljegraden. Dertil kan vi så tilføje, at jo mere af samtalen vi kan sætte i gang og vedligeholde, jo mere kan vi skrue ned for detaljegraden. Det er samtalen der genererer den sande implicitte forståelse.