Artikkel

Når Agile møter det offentlige

Slik kan kulturbarrieren reduseres

Smidige Agile-metoder og regelbundne offentlige etater går ikke så godt sammen – eller gjør de det? Her er noen forslag til hvordan man kan redusere kulturbarrieren.

Offentlige etater ønsker i økende grad å kjøpe programvare som er utviklet ved hjelp av Agile-metoden. Dette vil kanskje ikke bare kreve endringer i innkjøpsprosessen, men kan også skape en kulturkollisjon mellom en regelbundet offentlig sektor og den mer avslappede teknologileverandøren.

For at et Agile-innkjøp skal lykkes, må brukerne i det offentlige og Agile-utviklerne jobbe harmonisk sammen. Det betyr at kulturbarrieren må reduseres. I alt fra klesdrakt til arbeidstid, fra dokumentasjon til godtgjørelse, har ansatte i offentlig sektor og Agile-utviklere ofte helt forskjellige måter de gjør ting på. Å lære å jobbe sammen til tross for disse forskjellene krever hard jobbing fra begge parter.
 

Språkbarrieren

Agile har bokstavelig talt sitt eget språk. “Hvor mange story points er denne fortellingen?” “Hva er teamets velositet?” I stedet for prosjektledere har man produkteiere og Scrum-masters. Hvis du er gammel i gamet som innkjøper eller leder i en offentlig etat, vil du trolig himle med øynene.

Det var i alle fall slik Alistair Montgomery reagerte. Montgomery er IT-sjef for Transport for London (TfL). Han hadde jobbet i embetsverket i mange år og utviklet IT-prosjekter ved hjelp av fossefallsmodellen, noe som gjorde ham langt mer komfortabel med faste prosjektplaner og tidslinjer. 1 Da TfL først foreslo å bruke Agile-metoden sommeren 2015, var han meget skeptisk.

– Jeg satt fast i gamle mønstre, forteller han. – Jeg mente [Agile-metoden] var en gimmick spekket med moteord, og at det aldri ville fungere. Det fantes ingen Gantt-diagrammer. Ingen plan. Ingen fastsatt leveranse. Og da jeg hørte om “Scrum-masters”, sa jeg: – Kom igjen, dette er latterlig!

Heldigvis, sier Montgomery, ble han nedstemt. – Før det var gått to uker var jeg helt frelst, mimrer han og ler. Hva fikk ham til å forandre mening? – Det var moro, sier han. – Det var ikke noe hierarki – alle var på samme nivå – og jeg kunne raskt se fremgang. Det er derfor folk har blitt omvendt til dette.

Montgomery lærte raskt at det nye språket faktisk speiler en ny måte å gjøre ting på, og Agile er innført i etaten med stort hell. Men for å lykkes, må folk i embetsverket være villige til å lære Agile-språket.

Agile-metoder i det offentlige

Last ned full artikkel her

Regelbarrieren

Offentlige innkjøp har selvsagt også sitt eget språk – se bare på Federal Acquisition Regulation som gjelder for amerikanske føderale myndigheter, Defense Federal Acquisition Regulation Supplement (DFARS) og Procedures, Guidance, and Information (PGI) for det amerikanske militæret, Federal Acquisition Streamlining Act (FASA) for “små” innkjøp – og databaser som Federal Procurement Data System, Federal Business Opportunities (FBO), Integrated Award Environment (IAE) og System for Award Management (SAM.gov).

Denne “alfabetsuppen av akronymer” er språket som hersker i regler, forskrifter og dokumentasjon – en fremmed verden for mange Agile-tilhengere som “bare får jobben gjort”. En del av innkjøperens jobb er å bruke sin kompetanse til å følge reglene på en slik måte at både etaten og leverandøren kan fokusere på sluttresultatet og ikke bare på reglene.

 

Tillitsbarrieren

Tradisjonelle innkjøpskontrakter er utformet for å beskytte det offentlige mot svindel – der den underliggende antakelsen er at enhver leverandør kan være en potensiell bedrager. Agile krever tillit – mye tillit. Innkjøpskontrakter skal legge til rette for Agile-prosessen. Det betyr at advokater og innkjøpere må utarbeide kontrakter som prioriterer godt samarbeid heller enn sanksjonsdokumenter som skaper en ugjennomtrengelig mur av ord som tilsynelatende beskytter klienten. Med den mer samarbeidsvennlige Agile-metoden bidrar derimot tett samspill med kunden og jevnlig demonstrasjon av fremgang til å bygge opp et tillitsforhold til kunden. I tillegg kan kortere tidsrammer flytte makten over til innkjøperne.

For eksempel kan etater som tildeler små, trinnvise kontrakter, bytte leverandør hver gang kontrakten skal fornyes. Selv om det kan virke forstyrrende på etaten, kan dette være å foretrekke fremfor å være “gift” med en passiv leverandør på et langsiktig megaprosjekt. Som regel har offentlige etater forsøkt å formulere kontrakter som er fulle av sanksjoner, men ofte gir dette leverandørene et incitament til kun å levere det absolutte minimum som oppfyller kontrakten.

En godt formulert Agile-kontrakt utnytter konkurransekraften slik at leverandørene hele tiden er på hugget for å og levere programvare som fungerer. Samtidig kan leverandørene tilpasse forventningene trinnvis og luke ut stadig økende krav før de slår rot og informere etaten om hvor mye hver funksjon eller ekstra forespørsel kan komme til å koste.

 

Kontraktsbarrieren

Ved tradisjonelle innkjøp dekker kontrakten alt – priser, leveranser og systemytelse. Men med Agile-innkjøp blir sluttproduktet til gjennom felles innsats i hele prosessen. Kontrakten er egentlig ikke nøkkelen til suksess, det er det kontraktadministrasjonen som er. I mange tilfeller er offentlige etater ikke vant til å komme med den slags løpende innspill og støtte gjennom kontraktsadministrasjon, og det skaper en barriere.

En innkjøper kan ikke bare tildele en kontrakt og forvente en vellykket leveranse. Jevnlig kontakt mellom virksomhetseieren og innkjøperen gjennom hele prosessen er helt avgjørende. For Agile ble jo opprinnelig utarbeidet som en metode for intern programutvikling i privat sektor. Det innebar at “virksomhetsbrukerne” og “IT-utviklerne” jobbet for samme selskap. Man så ikke for seg at Agile skulle være en metode for å inngå kontrakter.

En del av Agile-prosessen er hyppige demonstrasjoner som viser fremgang og utfordringer med programvaren – kanskje så ofte som annenhver uke. Tett og direkte kontakt er avgjørende for å følge med på fremgangen og unngå ubehagelige overraskelser i ellevte time.

Risikobarrieren

Tilsvarende setter tradisjonelle offentlige rammeverk sin lit til kontraktsmessige beskyttelsesmekanismer for å minimere risikoen for skattebetalerne. Selv i dag ønsker de fleste offentlige innkjøperne av programvare en kontrakt som i detalj angir nøyaktig hva programmet skal gjøre, hva totalkostnaden blir og hva som er leveringsdatoen. Disse beskyttelsesmekanismene virker betryggende for alle parter – selv om de sjelden blir brukt.

Innkjøperne står overfor et alvorlig dilemma. Selv om en kontraktsfunksjon er godt kjent med Agile-filosofien, mangler mange ganske enkelt den erfaringen som kreves for å redusere risiko i et Agile-miljø. Det kan være vanskelig å gå fra teori til praksis. Kontraktansvarlige må ha alternativer som lar seg gjennomføre.

De er opplært til å holde leverandørene ansvarlig for mislighold ved hjelp av “kroker” i kontrakten. Strenge definisjoner spesifiserer hva som regnes som mislighold med hensyn til tid, kostnad og omfang. Agile fungerer ikke godt med så mange begrensninger – til en viss grad må du stole på motparten.

Tillit er en risikofaktor. Kontraktansvarlige vil bli rammet dersom prosjektet går skeis. Så selv om kontraktansvarlige jobber med et team, vil de likevel ofte instinktivt skygge unna tilliten som rollen deres nå krever. Noe av det viktigste kontraktansvarlige kan gjøre, er å sørge for at kontrakten blir fulgt opp. En tilnærming bygget på “tillit og verifisering” kan beskytte skattebetalerne og gi programvare som fungerer. Men det stiller nye krav og krever ny kompetanse hos de kontraktansvarlige.

I lys av dette kompetansegapet har United States Digital Service gitt ut TechFAR-håndboken for aktivt å oppmuntre til en mindre streng tolkning av kontraktreglene for å sikre at kontraktansvarlige har fleksibiliteten og ferdighetene de trenger. 2 Kontraktansvarlige kan vegre seg for å snakke med leverandørene om problemer før de skriver anbudsinnbydelsene. De ønsker ikke å fremstå som å favorisere et bestemt anbud. Uformelle samtaler med eksperter kan imidlertid hjelpe kontraktansvarlige med å forstå hvilke muligheter som finnes og skrive bedre kontraktforslag. Det finnes flere verktøy som kan hjelpe kontraktansvarlige å navigere i ukjent Agile-terreng.

Å jobbe sammen med en leverandør for å lage programvare ved hjelp av Agile-metoden krever ekte arbeidsfellesskap. Teknisk utvikling skjer ikke isolert, men i tett og hyppig kontakt med virksomhetsbrukere og eksperter på fagområdet. Å redusere kulturbarrieren mellom det offentlige og Agile-teknologileverandørene er nøkkelen til suksess.

Var denne siden nyttig?