Er smidige målprisprosjekter mulig?
The Norwegian computing association has released guidelines for contracts regarding agile projects. Wednesday, November 26th I will be part of a panel debating this work and the combination of agile and contracts. This Norwegian language blog post contains my introductory remarks for the debate.
Kom på debatten på Oslo Lean Meetup på onsdag og delta på debatten!
Jeg er ikke en prosjektleder, en advokat eller en politikker, så jeg kan ikke si så mye om hva som må være med i en slik kontrakt. Jeg er bare en programmerer. Jeg er en programmerer som ønsker å jobbe på gode prosjekter. Jeg håper at det er mulig for meg å jobbe på gode prosjekter som også advokatene og politikerne vil være fornøyde med.
Hva er et godt prosjekt? Den enkle definisjonen er at et godt prosjekt er et prosjekt som både leverandøren og kunden, både utviklerne og brukerne er fornøyde med. For meg som programmerer er dette viktig. Og jeg tror det er viktig for mange andre programmerer. Hva er det som gjør at enkelte mennesker synes programmering er spennende? Jeg tror svaret er enkelt: Programmerer er mennesker som brenner for å skape ting som noen har bruk for.
Jeg ønsker å skape verdi, og for meg er smidige metoder en god rettesnor. Jeg tror ikke smidige metoder er et magisk ord man kan bruke for å få til vellykkede prosjekter, men jeg tror at verdiene smidige metoder beskriver forbedrer sjansene mine for å delta på gode prosjekter. Men bare dersom man forstår verdiene og ikke bare utfører tomme ritualer som man kaller “smidig”.
Jeg har jobbet noen år som programmerer. Og jeg har deltatt både på prosjekter jeg var fornøyd med og på prosjekter som jeg ikke var fornøyd med. Den triste sannheten er at de fleste prosjektene jeg har sett eller deltatt på var ikke gode prosjekter.
Derfor var det veldig spennende for meg når jeg først fikk høre om veillederen. Spørsmålet jeg håper veilederen kan svare på: Er det mulig å forbedre sjansen for at leveranseprosjekter blir gode leveranseprosjekter? Kan veilederen forbedre sjansen for at prosjektene våre blir gode prosjekter?
Jeg har lest gjennom det som har blitt skrevet med en blanding av håp og skrekk. Mitt svar er “jeg vet ikke”.
Men jeg er skeptisk. Det virker som om smidige metoder, som mye annet, er i ferd meg å bli et offer for sin egen suksess. Kan vi risikere å falle i fella at vi tror at fordi vi bruker ord som Product Owner og ScrumMaster og Sprint og Product Backlog så vil alt bli bedre av seg selv?
Det er lett å si “smidig”, men det er ikke alltid lett å gjøre smidig. Så for å forstå hva smidige metoder dreier seg om, gikk jeg tilbake til kilden.
Jeg bladde opp på http://agilemanifesto.org. De smidige verdiene er kjent for de fleste nå. De står på forsiden. Men det ser ut som om mange overser den første linken herfra. Den går til de tolv smidige prinsippene. Jeg har valgt ut tre for dere:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
“Simplicity–the art of maximizing the amount of work not done–is essential.”
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Det jeg har fått ut av smidighet, er erkjennelsen om at vi ikke kan anta perfekt informasjon. Vi er nødt til å få feedback på det vi tror og det vi gjør, og vi er nødt til å endre planene basert på denne feedbacken. Denne grunnleggende verdien ligger bak ønsket om hyppige leveranser og mye annet.
Så jeg står igjen med et siste spørsmål: Er det mulig å lage en leveransekontrakt som verdsetter denne dype verdien om feedback? Det håper jeg å få svar på i denne debatten.
Comments:
Ram Yoga - Nov 24, 2008
“Vi er nødt til å få feedback på det vi tror og det vi gjør, og vi er nødt til å endre planene basert på denne feedbacken. Denne grunnleggende verdien ligger bak ønsket om hyppige leveranser og mye annet.”
Dette er en av grunntesene i brukersentrert design også (Det er riktignok en del designere som IKKE baserer seg på denne tesen, men de designer ut fra egoet, ikke fra brukeren). Dette er også et problem for oss designere, siden kontraktsformene vanskeliggjør iterativ design. Jeg har selv opplevd å selge inn brukertesting som endringsordre, noe som på mange måter er latterlig – men som var den eneste måten å få inn brukersentrerte aktiviteter på når rammene for prosjektet først var satt.
Hvis vi virkelig skal komme oss videre og lage skikkelig gode produkter sammen med kundene våre må kontraktsformene (og anbudsrundene i offentlig sektor) endres.
jhannes - Nov 24, 2008
Viktige tanker, Ram. Håper du har anledning til å komme på debatten.
Håpet ville være at det er mulig å få til gode prosjekter i eksisterende kontraktsformer. Hvor urealistisk er det?
Johannes Brodwall - Nov 24, 2008
Viktige tanker, Ram. Håper du har anledning til å komme på debatten.
Håpet ville være at det er mulig å få til gode prosjekter i eksisterende kontraktsformer. Hvor urealistisk er det?