I de to første blogindlæg om det agile manifest har vi dækket de to punkter: “Individuals and interactions over processes and tools” og “Working software over comprehensive documentation”. Nu er tiden kommet til den tredje i rækken “Customer collaboration over contract negotiation”.
Set i kontekst lyder det:
Through this work we have come to value:
– Customer collaboration over contract negotiation.
That is, while there is value in the items on the right, we value the items on the left more.
Vi skal værdisætte kundesamarbejde højere end kontaktforhandlinger – og hvad betyder det så?
Kontrakter er den måde vi aftaler et samarbejde, men både detaljegraden og hvordan vi håndterer afvigelser fra kontrakten kan variere. Man kan gøre som mange advokater og tolke bogstavelighed eller man kan gå i den anden grøft og snakke om “ånden bag aftalen”. Ofte tror den ene part at man har aftalt en ting og den anden part forstår aftalen en grad anderledes. Den slags kan man nok aldrig helt komme uden om.
IT-projekter består ofte af arbejde i uudforsket land. Det er ikke gjort før – i hvert fald ikke af samme team. Ingen kan med sikkerhed vurdere sådanne projekter og især for større projekter er der så stor usikkerhed at alle vurderinger af omfang og indhold vil have imponerende fejlmarginer, og derfor er impulsen at lave grundigt forarbejde for at komme nærmere et klart billede. Desværre går udviklingen så hurtigt at dette forarbejde nemt kan blive spildt arbejde, når verden har ændret sig undervejs. Den agile verdens måde at håndtere det på er at påbegynde arbejdet på et smalt grundlag og så håndtere ændringerne undervejs.
Uanset hvordan man vender og drejer det så bliver kontrakter ofte noget med et modsætningsforhold. Modsætning mellem parternes interesser. “Du skal levere det, så udløser det at jeg leverer det (når jeg har godkendt at du har leveret din del af aftalen)”. Detaljer i en kontrakt betyder rigiditet – mangel på detaljer kan betyde uenighed om hvad der egentlig er ment og inkluderet i kontrakten. Uanset fører det til et ønske om at afvige fra eller forhandle en bestemt fortolkning af kontrakten.
Hvis vi skal undgå at dette bliver ødelæggende for projektet skal vi holde det på et minimum. I den agile verden forsøger vi f.eks. ved korte iterationer at holde mængden af kunde-ubeset produkt til et minimum. Vi siger at kunden skal stole på os til iterationen er færdig – til gengæld for den tillid vil vi i løbet af iterationen have fokus på at levere færdig værdi og så snart iterationen er færdig vise frem hvad vi laver og fortælle hvordan det går. Efter iterationen har kunden så (teoretisk set) mulighed for at stoppe projektet eller fortsætte med næste iteration.
Hver gang vi går tilbage til kunden for at vise hvad vi har lavet i sidste iteration har de mulighed for at komme med feedback, så vi ved om vi er på vej i den rigtige retning eller ej. Misforståelser kan hurtigt rettes op inden de får følgevirkninger på det næste der skal laves. Den slags “demo’er” får kunden involveret løbende og gør at de har kontinuert fokus på projektet.
Min oplevelse er at den agile verden især møder virkeligheden hårdt på dette punkt. Kontrakten er stadig det sidste ord selv om vi i ånden ønsker tillid mellem parterne. Stemmer det overens med dine erfaringer?
Hej Therese,
Spændende med en serie af posts om agile – tak for det 🙂
Jeg oplever, at der er mange real-life benspænd som man kan løbe ind i. Nogle skud fra hoften:
– En kontrakt kan ikke bare blive det sidste ord, det kan også være det første. Så at sige: Det kan være en udfordring at lande en ordre, hvis kunden ikke kan lave en kontrakt mht., hvad der skal leveres. Dette er karakteristisk, når kunden skal have projektets indhold og budget godkendt internt.
– At arbejde med iterationer og demoer kan være en udfordring for kunden. Af flere årsager – måske har kunden ikke tid, måske har kunden ikke kompetencerne, måske er kunden hands-off i forhold til at involvere sig i detaljerne og/eller træffe beslutninger.
– Et meget sjovt fænomen er de projekter, hvor kunden vil have lavet en beskrivelse/kravspec som bilag til kontrakten. Så de har hånd i hanke med, hvad de køber. Den bliver lavet, men så snart kunden får en lillebitte demo, afstedkommer den mange nye og gode ideer hos kunden, der alle afviger fra oprindelige kravspec.
Mit mantra er blevet “forventningsafstemning”, og min oplevelse er, at agile teknikker virkelig har noget at bidrage med i forhold til dette.
Hej Christopher.
Jeg sidder og nikker fordi jeg genkender de ting du nævner… og kan tilslutte mig dit mantra om forventningsafstemning.
Især punktet om at kunden ikke har kompetencerne/interessen/tiden til at være en del af projektet løbende, synes jeg er en af de store udfordringer jeg møder. Der er ingen tvivl i mit sind om at produkter bliver bedre, når vi får feedback tidligt og ofte. En intern Product Owner kan løse noget af problemet – i hvert fald hvis det er kompetencerne der halter… et ekstra led til at vejlede og oversætte. Desværre kan en sådan PO ikke stille meget op overfor en kunde der ikke har tid.