Smidig digitalisering av offentlig forvaltning – video og slides.

Den 3 juni i år arrangerte Smidigkonferansen et ekstraseminar med fokus på offentlig sektor. Det er liten tvil om at potensialet er enormt i denne sektoren. Dette er en oppsummering av seminaret ispedd mine kommentarer. Linker fortløpende til alle foredragene, presentasjonene ligger her.
 
CollaborationSmaller 

Etter at Christina Kjær Seime hadde ønsket velkommen overtok Bjarte Bogsnes podiet og holdt en svært engasjerende og ikke minst viktig tale om hvordan kunnskapsorganisasjoner trenger en smidig styringsstruktur. Det handler om å ta dagens virkelighet på alvor og å slippe opp på kontrollregimet og heller gi medarbeidrne tillit og skape gjennomsiktighet.

Man kan være så smidig og agile man bare vil i et prosjektmiljø, men før eller siden treffer man styringssystemet og hvis det er skrudd sammen etter helt andre prinsipper så har man et problem. Bjarte Bogsnes

Deretter tok undertegnede over og forsøkte å vise hvordan smidig gjennomføring kan bli “raskere, billigere, tryggere og bedre“. Dette høres selvsagt ut til å være for godt til å være sant, men jeg tror ikke det. Tilstanden i de tradisjonelle IT-prosjektene i offentlig sektor er begredelig. Det sløses enormt med kalendertid (særlig i tidlige faser), innsatsen brukes svært lite effektivt, det tas unødvendig stor risiko og løsningene som leveres har ofte dårlig brukervennlighet og bugner av teknisk gjeld. Dette mener jeg er et systemproblem.

Så var det tre ulike miljøer i det offentlige IT-norge som overtok.

Først ut var Mons-Ivar Mjelde som fortalte om hvordan de fikk utnyttet smidige prinsipper til å lage bedre, mer fremtidsrettede løsninger enn opprinnelig specet i OTI-prosjektet. I tillegg konkluderer Mjelde med at utviklingsprosessen har skapt mange ideer for fremtidig utvikling og at smidig støtter opp under innovasjon!

KOMMENTAR: Et godt eksempel på hvordan kunde i tett, tillitsfullt samarbeid med leverandør kan gjøre byråkrati og overhead  unødvendig. Når dette samarbeidet er på plass kan man senke skuldrene og ikke være så redd for å trå feil og heller fokusere på innovasjon.

Så tok Svein Hauge over og fortalte hvordan Statens Vegvesen nå kjører alle utviklingsprosjektene sine smidig. Han begynner med (med glimt i øyet) å fremstille leverandørene som ulver som må holdes i tømmene. Deretter langet han ut mot anskaffelsesreglementet som alt for lett fører til at man kommer skjevt ut. Sannsynligheten er stor både for at man velger feil leverandør og ender opp med et urealistisk lavt budsjett. Og gevinstene har en tendens til å gjemme seg i de kravene som droppes (prioriteres ned). Autosys-prosjektet måtte ofre både gevinstene og kvaliteten for å komme i mål. Hauge hevder at de har vært nødt til å styre etter tradisjonelle PMI-prinsipper, noe som blir erstattet med PRINCE2, mens utviklingsmetodikken er Scrum.

KOMMENTAR: Vegvesenet har her tatt et godt skritt i retning av smidig, men er ikke der ennå. En del av problemene kunne antageligvis vært unngått med en mer helhjertet smidig tankegang. PRINCE2 vil ikke hjelpe til her…

Deretter overtok Mette Gjertsen og fortalte om hvordan Statens Pensjonskasse (SPK) nå forvalter og videreutvikler resultatet av PERFORM-prosjektet. Har for øyeblikket 12 Scrum-team. Dette er tverrfaglige team der noe over halvparten er egne SPK-ansatte. Alle sitter på en flate. Samarbeidet mellom forretning (4 dedikerte forretningsstøtteteam) og utvikling er helt sentralt og fokusert. Har nå sluttet å kjøre egne prosjektteam – dette for å sikre læring; “utviklerne må rette sin egen drit”. De ser at dette fører til bedre kvalitet. Har nå samlet alt arbeid til alle teamene i én kø. “Produkteier bor, lever og ånder i denne køen”. Har stor fokus på løpende prioritering og har klart å løsrive seg fra det tradisjonelle endringsregimet.

KOMMENTAR: Dette er storskala og helhjertet smidig og et eksempel til etterfølgelse!

Etter lunsj startet vi med Ux-designer Sigrun Tallungs som fortalte om det Svenske Pust-prosjektet som klarte kunststykket å gå fra suksess til fiasko. Dette er “polisens nya utredningssystem” som først ble utviklet i Java, et prosjekt som ble kjørt smidig i tett samarbeide med brukerne og som ble tatt godt imot. Etter å ha brukt 100 MSEK på dette ble det brått stoppet fordi Oracle hadde klart å selge inn at det ville bli mye billigere i lengden om de la om til et “standardsystem” basert på Siebel. Etter å ha brukt 200 MSEK på Pust Siebel er nå evalueringen entydig – systemet er nå nærmest ubrukelig! Dette foredraget er en skikkelig tankevekker!

KOMMENTAR: Mye læring å hente her! Rekk opp hånda den som vet om lignende tilfeller i Norge! :-)

Så kom advokat Ståle Hagen opp på podiet for å snakke om kontraktsregulering. Han har hatt en rekke oppdrag de siste årene for å hjelpe til å “rydde opp” mellom kunde og leverandør i “smidige” prosjekter. Hovedproblemet har vært at endringene underveis lett blir uhåndterlige. En typisk feil er at man presser smidig gjennomføring inn i en fossefallslignende kontrakter. Her blir det lett en endeløs tautrekning når det er behov for endring og bruk av advokater for å få avsluttet prosjektet. “Dette er god business for meg, men jeg skulle gjerne tjent de pengene ved å hjelpe til med i starten når kontrakter inngås.” Når det gjelde kontraktsstandarder så har Difis SSA-S alt for mange feil og mangler til at den kan anbefales. Det nærmeste man kommer er dataforedningens SOL-kontrakt men heller ikke denne er god nok.

KOMMENTAR: Det synes som varianter av timebaserte kontraktsformer er det eneste som fungerer godt i programvaretunge prosjekter.

Så var det Sergey Dmitriev sin tur til å fortelle om hvordan Kystverket har lagt smidige prinsipper til grunn helt fra starten av for å utvikle BarentsWatch. Utgangspunktet var at de ønsket å finne leverandører som “er smidige”. Men hva er egentlig dette? Alle sier de er smidige, men det finnes ingen særlig god, målbar definisjon på smidighet. Kystverker med hjelp av Sergey lagde da en halv dags opplegg for å teste leverandørens smidige tilnærming til problemløsning. Når de testet fire leverandører på denne måten viste det seg overraskende nok at ingen hadde en godt, smidig tankesett inne!

KOMMENTAR: Er dette redningen for de kundene som ønsker å sikre seg gode, smidige leverandører?

Deretter overtok Christin Gorman fra Husbanken for å snakke om ansvar. Er det virkelig nødvendig å sette alt utviklingsarbeid ut til konsulentselskaper gjennom tunge anbudsprosesser? Hvorfor ikke ansette flinke, dedikerte folk og gjøre utviklingen med stor grad av egne medarbeidere? Dette kan jo forenkle utviklingsprosessene voldsomt. Hvorfor må leverandørene sees på som sultne ulver? Det må da være bedre å dyrke samspillet og samarbeidet? Uansett kontrakt, så er det kunden som blir sittende igjen med produktet – og vil enten han vil det eller ikke ha ansvaret selv. Staten kan enkelt ansette langt flere utviklere selv og spare penger på det, samtidig som de vil få enklere og bedre løsninger.

KOMMENTAR: På denne måten kan staten sikre seg mye bedre og kvitte seg med byråkratiske, tunge anbudsprosesser.

Sist ut var Lars Nokken fra Difi som redegjorde for Difi sine tanker om smidig. Utgangspunktet til Difi er at prosjektveiviseren kun addresserer det overordnede nivået kalt Prosjekteierstyring og Prosjektstyring. Det utførende nivået er definert som uavhengig av dette og blir ikke adressert. Nokken uttalte veldig tydelig at Difi ER positive til bruk av smidig utviklingsmetodikk. da særlig bruk av Scrum eller DSDM innenfor rammen av Prince2. Utgangspunktet til Difi er prosjektstyring og prosjektlederens vanskelige jobb. Beslutningsvegringen råder i offentlig sektor på grunn av en forsiktighetskultur der det altoverskyggende er å unngå å komme i VG.

KOMMENTAR: I Difi sin verden er prosjektperspektivet rådende mens produktperspektivet er utydelig. Når de i tillegg setter premisset om at topp-nivået skilles fra det utførende nivået, blir det vanskelig å se at dette vil bevege verden i smidig retning. Om Difi ønsker smidig må de kommunisere dette mye tydeligere og synliggjøre dette på høyeste nivå.

Dagen ble avsluttet med 45 minutter paneldebatt. Hovedtema er kontraksformer som passer for IT-prosjekter.

KOMMENTAR: Panelet virket etter hvert ganske samstemte på at Time/Material er overlegent, at kunden ikke kan distansere seg fra produkteieransvaret og at også kunden bør ha en solid andel egne ansatte i utviklingsteamene.

 

 

 

 

Posted on June 12, 2014 at 10:30 am by gamsjo · Permalink · 2 Comments
In: Endringsledelse, kontrakt, prosjektledelse, Samfunn, Scrum · Tagged with: , , , , ,

IT-satsninger ER – og skal være – risikable

En nylig innsatt startssekretær Paul Chaffey uttalte i sin åpningstale på NOKIO 2013:

Den eneste sikre måten å ikke ha mislykkede it-prosjekter, er å ikke ha noen it-prosjekter i det hele tatt. Og det er ikke noe alternativ. Vi kan ikke være så redde for å gjøre feil at vi ikke tar noen risiko og ikke har noe innovasjon.

Den 22 april uttalte NHO-direktør Kristin Skogen Lund:

En offentlig forsiktighetskultur rammer innovasjonen i de offentlige innkjøpene på 400 milliarder kroner: – Mer vekt på innovasjon gir en vinn-vinn-situasjon for alle og vil øke verdiskapingen i Norge.

Begge har selvsagt rett. Å være innovativ betyr å våge å satse nytt. Å tråkke et stykke utenfor det sikre og trygge. De impliserte må utenfor sin komfort-sone – fra tid til annen i hvert fall. Dette stimulerer innovasjon, men ikke bare det; Det er dette som gir utvikling. De involverte enkeltmenneskene hos kunde og leverandør får på denne måten bedre anledning til å erfare, lære og gjennom dette utvikle seg.

Den rådende kulturen

Den rådende kulturen i offentlig sektor i dag er opplagt risikoavers. Det gjelder å ikke bli beheftet med mislykkede prosjekter, og i framdriftsrapportering og evalueringer gjelder det å skjønnmale situasjonen så langt det lar seg gjøre. Dessuten legger hele strukturen i anskaffelsesreglementet opp til å forsøke å redusere risiko gjennom rigide, dyptpløyende analyser og forprosjekter. Dette er en forfeilet strategi om man ønsker innovasjon. Vi taper så mye kalendertid på den måten at verden rekker å endre seg flere ganger mens vi analyserer og planlegger!

Hvordan endre kultur?

Om vi ser på innovasjon som et opplagt gode og samtidig vet at den rådende kulturen er risikoavers, hvordan kan vi da sette i gang en nødvendig endringsprosess? Få har jobbet mer med slike endringsprosesser enn Craig Larman, og han har ganske nylig formulert Larmans law of Organizational Behavior. Jeg tror han er inne på kjernen i det siste punktet “Culture follows structure”. Om prosedyrene og belønningssystemene legger opp til en viss adferd får vi etterhvert en kultur som avspeiler dette. Om vi vil endre denne kulturen bør vi innføre solide strukturelle endringer. Hvis ikke får vi overflatiske “skinn-endringer” som i bunn og grunn er “same shit, new wrapping”. Kulturen er inntakt og forbedringene lar vente på seg.

Smidig kultur

Den smidige fremgangsmåten legger opp til (og betinger) en helt annen type kultur. Nå skal vi sette i gang å lage produktet lenge før vi fullt ut har forstått helheten (Se Kunsten å kjøpe inn det ukjente). Allerede her føler vi oss på tynn is, og den risikoaverse vil etterlyse mer analyse. Men vi motstår denne fristelsen for tryggheten beholder vi allikevel gjennom at vi i tett samarbed mellom brukere og utviklere leverer små inkrementer som vi validerer. Vi løper med andre ord ikke den virkelig store risikoen. Du kan si at vi spiser opp risikoen mens vi jobber! Vi har atså en systematikk som gjør det trygt å feile. Når de involverte oppdager dette, vil de se at det ikke er så skummelt lengre å ta sjanser. Det gir mening å snakke om “Smidig kultur” som er en tillitsbasert kultur det alle er genuint opptatt av utvikling on innovasjon framfor å finne syndebukker når noe går galt. Linda Rising hyller her “Agile Mindset“.

Et ledelsesansvar (selvsagt)

Lederne i offentlig sektor bør snarest ta Chaffey og Skogen Lund på alvor og addressere innovasjonsevne gjennom å finne måter å jobbe på som gjør det trygt å feile. Dette finnes selvsagt, se for eksempel på Scrum. Følger man dette rammeverket etter hensikten bevilger man seg omgivelser der man ikke kommer langt ut av kurs, selv om man forsøker på krevende, risikable ting. Lederne bør gå foran og snakke om unngå de store “big-bang” leveransene og heller levere i små porsjoner. De bør etterspørre – og ivre etter å snakke om – den brutale feedbacken man kan få av brukerne. Jevnlig, også når det går dårlig. Og de bør snakke om utviking og prosessforbedring basert på feedback.

 

Posted on April 30, 2014 at 1:42 pm by gamsjo · Permalink · Leave a comment
In: Endringsledelse, ledelse, Planlegging, Samfunn, Scrum · Tagged with: , , , , ,

Smidigavtale med bonuser fra DIFI

I januar lanserte DIFI ny versjon av sin SSA-S. En avtaleform som jeg flere ganger har karakterisert som “halvsmidig” – et  langsomt skritt i en riktig retning. Noe som sammen med en veileder kan hjelpe offentlige IT-innkjøp et lite skritt på veien mot noe bedre, men heller ikke mer… Potensialet til “helsmidig” er mye større.

Nå har de  introdusert bonuser. Ideen med slike mekanismer er jo å gi en aktør positive incentiver til å gjøre en bedre jobb enn de ellers ville gjort. Man setter målbare mål, samler data og utbetaler en belønning om aktøren oppfyller kriteriene.

Difi skriver: “Leverandøren får bonus hvis de leverer programvare med få feil, hvis de leverer før eller til avtalt tid, og hvis de leverer til avtalt kostnad eller lavere.”

Konsekvensene av incentiver er svært vanskelig å se på forhånd. IT-prosjekter er (svært) komplekse, sosiale systemer så vi må forstå kompleksitet og vi må bruke systemtenkning. I slike systemer vil ”alt påvirker alt” og legger vi  stimuli som bonuser inn i systemet, vil det få sideeffekter. Disse kan være negative. Vi har en del erfaring fra slike ordninger..

 

Bonus for få feil

Dette kan kanskje være OK. Dette er et opplagt gode, og fordi dette er et stort problem i mange prosjekter. Man tar seg ikke tid til å lage solid, korrekt kode som fungerer etter hensikten. Men det som selvsagt blir viktig er å definere “feil” på en slik måte at det blir mulig å telle disse på en fornuftig, objektiv måte, uten for mye skjønn. Når det står pengeutbetalinger på spill, kan vi ikke basere oss på skjønn. Den umiddelbare uønskede sideeffekten jeg kan se her er at leverandøren vil ha interesse av å skjule og bagatellisere feil.

Jeg er spent på hvordan dette skal praktiseres.

 

Bonus for å holde tiden

Dette er ikke OK! Mennesket er i utgansgpunktet dårlig til å estimere, vi er optimister og har vanskelig for å lære av feil (Les gjerne boka Thinking, fast and slow). Dessuten er software-utvikling komplekst, så uforutsette problemer kommer! Så det er normalt å komme på etterskudd. I en slik situasjon, når det er bonus knyttet til fremdrift, vil de som gjør jobben lett kunne ofre det gode håndtverket. Det gode håndtverket tar tid, men er veldig god økononi (for kunden) på sikt. Kunden har små muligheter til å måle og kontrollere den håndtverksmessige standarden som utføres.

Dette er selve oppskriften på å bygge opp teknisk gjeld!

 

Bonus for å levere under kostnad

Dette er ikke OK!  Å levere under avtalt kostnad blir lett uforenelig med ønsket om å lære og finne bedre løsninger mens man jobber. Hva skjer om leverandøren i dialog med brukerne finner ut at ting bør gjøres på en annen måte enn først antatt. Da blir det en vurdering om dette ekstraarbeidet kan komme i veien for bonusen.

Dessuten er dette på akkurat samme måten som bonus for rask utvikling en pådriver for å bygge opp teknisk gjeld. Det gode håndtverket koster tid og penger.

 

Bonus for å nå effektmål?

Om man på død og liv skal gi bonuser må dette knyttes til effektmål (verdi). Dette er uhyre krevende og fordrer stor modenhet både hos kunde og leverandør og man snakker om et regime som dette: http://www.flexiblecontracts.com/. Dette er spennende eksperimenter, men ganske uprøvd. Man bør uansett styre ved å gjøre kost/nytte vurderinger, men dette behøver ikke kobles til kontrakten.

 

Vi må behandle folk som voksne

Agile Manifesto (som definerer smidig) fokuserer på at det er menneskene som gjør jobben som er avgjørende. At du har dedikerte, motiverte folk som tett sammen med kunden finner løsninger underveis. At vi våger å stole på disse. Dette er ikke bare en “vakker tanke” for å gjøre utviklerne til lags. Dette er en nødvendighet hvis dette skal bli skikkelig bra! Vi klarer rett og slett ikke å kvantifisere produktivitet eller kvalitet godt nok. Så vi er henvist til den “kjedelige” virkeligheten at vi må behandle de som gjør jobben som voksne og stole på dem. Gi de ansvar og myndighet. En grad av autonomitet. På den måten får det det aller viktigste: Dedikerte folk som virkelig bryr seg om sluttresultatet.

 

Kunden må engasjere seg

Det finnes realistisk sett ingen andre modeller enn varianter av Time/Material om man virkelig ønsker innovasjon og læring underveis. Og når det gjelder risiko – så sitter kunden med den uansett. Kunden må “dessverre” engasjere seg og ha en viss kompetanse – man kan ikke distansere seg fra det. Jeg vil anbefale alle kunder som utvikler programvare jevnlig å

  1. Sørge for å ha noen egne  ansatte teammedlemmer (programmering test, design etc)
  2. Leie inn resten av kapasiteten på langsiktige kontrakter og bemann teamene med en miks av egne og konsulenter.
  3. Få på plass dedikerte, gode Scrum Mastere og Produkteiere – gjerne fra egne rekker.

På denne måten kan du få dedikerte team som er brennende opptatt av brukernes beste og som vil gjøre håndtverket grundig og bra så vi unngår å akkumulere opp teknsik gjeld.

Programvareutviklingens natur

Når vi skal bestemme oss for hvordan vi angriper problemløsning kan det være en fordel å forstå seg på de særegenhetene som gjelder for det området vi skal inn på. Mange disipliner er gamle og godt kjente og man har mengder av empiri som forteller hvordan det lønner seg å jobbe. Og innenfor veldig mange ingeniørdisipliner finner vi ganske detaljerte forskrifter og regelverk som skal sikre høy kvalitet. Dette finner vi ikke for programvare, både fordi faget er ganske nytt, men også fordi det er for komplekst til at det finnes riktige svar. Jeg mener programvare har en rekke særegenheter som gjør overføringsverdien fra andre disipliner svært liten.
 
Det er nok først og fremst historiske årsaker til at vi vanligvis angriper programvareutvikling med tradisjonelle prosjektstyringsmetoder. Vi drar med oss erfaringer fra samlebåndet, fra andre ingeniørdisipliner og prosjektstyringsfaget. Er dette en god idé?
 

7 typiske særtrekk for programvareutvikling

1. Vi kan velge å levere i små inkrementer

I motsetning til fysiske produkter, kan programvare kuttes opp i småbiter og leveres en for en. Vi kan også i stor grad velge hvilken rekkefølge vi leverer disse i. Vi har disse valgene, men det betyr ikke at det nødvendigvis ligger til rette for det. Mange har store hindringer, bygget opp over tid, som må overvinnes for å klare å levere små inkrementer.

2. Selve produktet er i praksis usynlig

Selve produktet er beskrevet med kodelinjer. Svært få er i stand til å forstå tilstanden på slik kildekode. Er dette “god” kode eller ikke? Dette aktualiserer spørsmålet: Hvordan skal kunden kunne forvisse seg om at hun får “høy kvalitet” – når kvaliteten er gjemt inne i uforståelige kodelinjer?

3. Løsningsrommet er nærmest uendelig

Om du setter 100 programmerere til å løse det samme problemet, vil du få 100 ulike løsninger. Det er en ekstrem frihetsgrad, sammenlignet med de fleste andre ingeniørdisipliner.

4. Nytt hver gang; innovasjon er en opplagt del av jobben

Vi bruker programvare for å løse nye problemer. Hvis det er løst før forsøker vi å bruke andres løsninger. Hverdagen til utviklere er at de må finne løsningen når de står oppe i den. Og man oppdager stadig at i samtaler mellom utviklere og brukere genereres det ideer som man ikke hadde tenkt på før.

5. Stor kompleksitet

Det er lite grad av repeterbarhet i programvareutvikling. Alle omgivelser er litt ulike, rammebetingelser varierer, brukere er mennesker (komplekse vesener) og det er dynamikk. Teamene som lager programvare er også i høy grad komplekse sosiale systemer med flyktig kausalitet. Vi vet at ytelsen kan variere voldsomt mellom individer – og antageligvis enda mer mellom team.

6. Dynamikk

Krav og behov vil endre seg mens vi gjør jobben. Dette varierer selvsagt med typen systemer vi snakker om, men trenden er klar overalt – det blir mer og mer dynamikk. Dynamikken kan også komme av av vi finner bedre løsninger enn vi hadde sett for oss i starten, samt at det i skjæringspunktet mellom utviklere og brukere oppstår en positiv kreativitet.

7. Livsløpskonstnaden avgjøres av vedlikeholdsvennligheten

Hvor mye det koster å gjøre én endring i programvaresystemer varierer med 10-er potenser. I godt strukturerte, vedlikeholdsvennlige systemer med innebygde tester, vil en endring trygt kunne gjennomføres på minutter. I komplekse, monolittiske systemer uten automatikk, ser vi at enhver endring potensielt får alvorlige bi-effekter slik at vi ikke våger å sette i drift uten at en masse regresjonstester kjøres. En begrenset endring kan da koste dagsverk, kanskje ukesverk. Konsekvens: Det er sub-optimalt å fokusere mye på kostnadene til prosjektet som lager funksjonaliteten. Alle programvaresystemer er mer eller mindre gjenstand for videreutvikling og det initielle prosjektet blir etterhvert en liten andel av totalen. Om dette prosjektet etterlater seg dårlig strukturert kode blir økonomien på sikt dårlig.

Konsekvenser

Så, om vi aksepterer at punktene over gir en riktig virkelighetsforståelse, hvilke konsekvenser har det for vår angrepsmåte? Hvilke modeller for organisering, styring og ledelse er best under slike forhold?
PullVsPush
Hva bør vi velge?
I Pull-systemet gir vi et tverrfaglig team fullmakt til å organisere seg på best mulig måte og å utvikle produktet løpende i tett samarbeid med kunden/brukerne. Teamet prioriterer rekkefølgen i samarbeid med kunden.
I Push-systemet forsøker vi å forstå helheten, legger en plan og jobber med hele produktet hele veien mens vi akkumulerer opp hele produktet til en stor leveranse på slutten. De ulike fasene utføres av ulike spesialister eller roller, mens prosjektleder styrer framdrift iht plan og rammer.
NB: Det er ingen premie for riktig svar!
Tips: Se presentasjonen Unngå Teknisk Gjeld på Slideshare

Keiserens gamle, loslitte klær

På tide å kle av prosjektveiviseren!

Følgende artikkel ble i dag 21.02.14 publisert som med tittelen Utdatert Utvikling i Dagens Næringsliv. Signert Benjamin Sommer og Geir Amsjø, Axio Consulting.

———————

Digitaliseringen av Norsk offentlig forvaltning skal få et løft gjennom IT-prosjekter etter en utdatert, standardisert mal. Er Killengreen og Chaffey klar over hva de gjør?

Det er rart hvordan avdanket teknologi og forkastet tankegods kan få noen ekstra leveår i det offentliges regi. Disketten (og maskiner som kan lese disketter) har fremdeles et marked i norsk helsevesen. Bra for de som lever av sånt, men er selvsagt svært ineffektivt.

 

prosjektveiviser

På samme måten er Prosjektveiviseren.no som Direktoratet for forvaltning og IKT (Difi) lanserte ny versjon av rett før jul basert på forkastet tankegods når det gjelder programvareutvikling. Veiviseren institusjonaliserer ”vannfallsmodellen” der prosjekter går igjennom 5 ulike faser, med beslutningspunkter mellom hver fase. Gevinster tas ut når hele prosjektet omsider er ferdig. Dette kan fungere godt for en del typer prosjekter, men er særdeles lite egnet for kunnskapsintensivt, dynamisk og innovativt arbeid som programvareutvikling vitterlig er. Ingen av de store, men fremdeles unge programvarebaserte lokomotivene i IT-bransjen (som Google, Amazon, Facebook, eBay, Yahoo, Salseforce.com, Spotify, FINN.no, for å nevne noen få) benytter denne modellen. Veldefinerte, standardiserte fasemodeller er 90-tallets forsøk på å øke suksessraten til IT-prosjektene. Vi vet i dag hvordan det gikk.

Prosjektveiviseren ble 18 desember 2013 presentert i et 4 timer langt seminar publisert her: http://www.prosjektveiviseren.no/2013/12/digitalisering-gir-gevinster. Ingelin Killengreen innledet og snakket varmt om å ”forenkle, fornye, forbedre”. Paul Chaffey overtok så og holdt et godt innlegg om viktigheten av å realisere gevinstene. Han ville ha fokus på innovasjon, gjennomføringsevne og endringsledelse. Og han avsluttet med å si at ”Difi kommer til å bli departementets viktigste verktøy!”

Den dårlige nyheten er at all erfaring viser at denne vannfallsmodellen fører til sløsing med kalendertid, byråkrati, høy risiko, dårlig kvalitet og er lite egnet til innovasjon. Den er på mange måter naturstridig når vi tenker på hva programvareutvikling egentlig dreier seg om. Vannfallsmodellen ble adoptert og institusjonalisert av US Department of Defence på 1970-tallet og har siden det vært den rådende framgangsmåten. Det er i den forbindelse svært interessant å merke seg at DoD nå synes å ha forkastet modellen og er i full gang med å institusjonalisere ”Agile”! (http://scrum.jeffsutherland.com/2012/04/dod-goes-agile.html)

I 2001 kom startskuddet for det som skulle revolusjonere programvarebransjen; ”The Agile Manifesto”. Dette manifestet definerte helt nye suksessfaktorer og verdier som er tilpasset programvareutvikling. Manifestet sier slike ting som ”Individuals and Interactions over Processes and Tools”. Dette innebærer mao at om de individene som gjør jobben er høyt motiverte, kompetente og samarbeider godt, vil det bety mer for suksess enn verdens beste, veldefinerte prosessbeskrivelser, prosedyrer og sjekklister.

Agile baserer seg på mye av den samme tankegangen som vi finner i Lean. Vi dyrker for eksempel ”pull-prinsippet” der markedet til enhver tid bestemmer hva vi fokuserer på, og at vi tilpasser kapasiteten til etterspørselen. Vi realiserer gevinster tidlig og løpende i tett dialog med interessentene. Det er til syvende og sist vår evne til å lære underveis som vil bestemme hvor godt resultatet blir. På denne måten blir også robustheten til selve produktet langt bedre ivaretatt, og risikoen lavere. Agile representerer mao et annet paradigme, optimalisert for dynamikk, hurtighet , kvalitet og innovasjon. Prosjektstyring er ikke lenger viktig.

”IT-skandalene” er mange i dette landet, og vannfallsmodellen må bære mye av ansvaret. Vi skal ikke ramse alle disse her, men nøye oss med å nevne ett eksempel referert i DN (http://www.dn.no/forsiden/politikkSamfunn/article2546457.ece) som forteller at Estland har kommet i mål med et elektronisk pasientregistersystem for 82 mill kroner. Norge har hittil brukt over en milliard, og har planer om å bruke nye hundretalls millioner.

Det er naturlig at forvaltningen og IT-bransjen har store forventninger til en blå regjering på områder som fornying, innovasjon og effektivisering. Om Difi skal spille en sentral rolle i dette arbeidet må først Difi fornyes! Det ville vært ganske oppsiktsvekkende om den nye regjeringen bidrar til å institusjonalisere en gammel, stiv og forkastet modell.

Posted on February 21, 2014 at 11:32 am by gamsjo · Permalink · 30 Comments
In: kontrakt, Kvalitet, ledelse, Planlegging, prosjektledelse, Samfunn · Tagged with: , , , , , , ,

Kunsten å planlegge det ukjente

Dette er en fortsettelse av forrige post, Kunsten å kjøpe det ukjente. Vi antar nå at vi har fått anledning til å kjøre smidig utvikling av et nytt produkt, og at den utfordringen vi står overfor er å planlegge på en slik måte at vi gradvis bygger opp mest mulig verdi for brukerne.

Den første gangen vi gjør noe slikt føler vi oss på usikker grunn. Vi vet altså ikke helt hva vi skal lage, bare hva vi vil oppnå med det. Hvordan skal en plan for et slikt utviklingsløp egentlig se ut? Hvordan sikrer vi et godt resultat? Hvilken strategi skal vi velge?

Om vi velger Scrum er visse ting gitt

Planleggingsstrategi

Hvilke kriterier vi bruker for å optimaliserer produktutviklingen vil avhenge av mange ting, som for eksempel “nyhetsgraden” av det produktet vi skal lage. Om vi ligger i front å tenker å starte fra scratch med noe kundene ikke har skjønt at de trenger ennå, bør vi legge opp til et løp som benytter Lean Start-up tankegangen. Om vi på den annen side bare skal legge på ny funksjonalitet på et eksisterende produkt med en etablert kundebase, gjelder det å alliere seg med noen representative brukere og å la disse få stor inflytelse på prioritering og utforming.

Men uansett: Planlegging av innovasjon dreier seg om å teste hypoteser. Det som er viktig er å lære mest mulig, billigst mulig. Vi må unngå å låse oss for tidlig, før vi har fått validert vår antagelser om hva brukerne gjerne vil ha. Vi trenger en dynamisk og levende kø av arbeid.

LevendeBacklog

Levende kø

 

Det som til enhver tid ligger på toppen av køen må være brutt ned i ganske små biter og være godt forstått av teamet som skal gjøre jobben. Dette betyr at hver gang en ny iterasjon starter er det enkelt å plukke ut en realistisk mengde arbeid.

Når arbeid tas ut fra toppen blir det plass til mer, hvilket jo betyr at noen av de litt større elementene lenger nede må brytes opp i midre biter og får plass i den øverste delen.

Vi kan gjerne ta vare på større produktideer og hypoteser i en slik kø, men de må bearbeides en del før de innvilges plass lengre oppe.

 

Budsjettering

Det eneste fornuftige er å unngå å låse budsjettet til en spesiell sum per år. Vi vet at vi kommer til å få verdifull ny informasjon etter noen gjennomførte iterasjoner, og denne informasjonen bør vi benytte oss av! Dessuten må vi være forberedt på at uforutsette ting (både muligheter og trusler) kommer til å påvirke vår prioritering. Så vi må være forberedt på å revurdere finansieringen løpende gjennom hele dette produktets levetid – minimum hvert kvartal.

Scenario

La oss si at vi bestemmer oss for å finansiere ett kvartal med utvikling og utviklerne anslår at det bør være mulig å få på plass en stabil plattform med en del kjørbar funksjonalitet etter ca 3 måneder (6 to-ukers sprinter) med et lite team på 5 fulltids utviklere. Her vil det være mulig å vurdere sunnheten til dette initiativet etter hver Sprint (Sprint Review).

OK, etter 6 Sprinter har teamet oppnådd mye og har vist at plattformen duger, og at de kan demonstrere enkel basisfunksjonalitet og at brukerne liker det de ser. Da kan vi velge å øke hastigheten (samt kostnadere selvfølg

Kostnader

elig) ved å sette på 3 til i teamet. Vi bestemmer å kjøre i nye tre måneder med denne bemanningen. Igjen må vi være forberedt på å revurdere denne satsningen etter hver Sprint.

Etter 6 nye Sprinter (totalt et halvt år) har vi fått i gang en aktiv, men liten brukergruppe. Vi ser at teamet nå leverer ny funksjonalitet rutinemessig hver andre uke og at potensialet er der, men vi trenger å skalere opp for å ta markedsandeler. Da kan vi for eksempel velge å sette på 4 utviklere til og dele opp i to 6-manns team. Vi vil tape noe hastighet på å ha to team jobbende på den samme koden, men overheaden behøver ikke være særlig stor.

Etter Q3 har det kanskje dukket opp andre muligheter som gjør at vi må prioritere denne satsningen noe ned, og går ned til det opprinnelige nivået på 5 teammedlemmer. I figuren ser vi hvordan kostnadsutviklingen følger dette forløpet.

Nyttige verktøy for løpende planlegging

Produktkøraffinering: Dette er en løpende aktivitet der interessentene og de som gjør jobben sitter sammen og bearbeider køen av arbeid. Erfaring fra Scrum viser at det er lurt å gjøre dette en gang i uken, til fast tid og sted. Opp mot 10% av teamets kapasitet kan være nødvendig. Her splittes store elementer opp i mindre biter, og teamet grovestimerer bitene.

Visjon: Uttrykk en samlende visjonen klart og tydelig. Det kan være formålstjenelig å både uttrykke en langsiktig visjon som er svært ambisiøs og omfattende, og en kortsiktig visjon som retter seg mot et begrenset produktinkrement. Den kortsiktige er da underforstått et steg på veien mot den langsiktige. Visjonen bør definere interessentene, hvilke behov disse har og hvordan forretningsmodellen ser ut. Det bør også være klart hvordan man har tenkt å måle at man er på vei mot målet. Risiko bør også innbefattes i visjonen.

Måling: Vi må sørge for å skaffe oss solid feedback på det vi leverer. Det er nyttig å få direkte feedback fra brukere på en demontrasjon (Sprint Review i Scrum) men den ultimate valideringen får vi fra markedets respons – som da må sees opp mot den gevinsten vi håpet å få. (Eksempler på målinger: Raskere saksbehandlingstid, flere betalende kunder, øker konverteringsgrad, antall besøk på en web-side, bedre brukervennlighet, høyere kundetilfredshet etc..)

Planleggingsstrategi: Rekkefølgen vi velger å realisere funksjonalitet i vil være svært avgjørende for suksess. Det anbefales sterkt å begynne med å skaffe seg en stabil, men ikke komplett plattform å bygge produktet på. Deretter å lage funksjonalitet beregnet på en liten del av markedet og da prioritere funksjoner dette segmentet ønsker seg. Bruk her gjerne MMF eller MVP. Om det er noen absolutte milepæler i kalenderen vil dette være styrende.

Veikart (Road Map): Det anbefales å vedlikeholde et overordnet veikart som til enhver tid reflekterer hvordan framtiden ser ut. Dette kartet er kun en plan basert på den informasjonen man har på et gitt tidspunkt, og kan ikke betraktes som noe løfte.

Et veikart kan være funksjonsorientert som i figuren, men det kan være formålstjenelig å inkludere andre detaljer slik som avhengigheter, teknologiske milepæler, eller for eksempel opplæringsplan.

 

 

Posted on January 29, 2014 at 12:14 pm by gamsjo · Permalink · Leave a comment
In: Planlegging, produkteier, prosjektledelse, Scrum · Tagged with: , , , , ,

Kunsten å kjøpe det ukjente

Du har identifisert et behov som vil fordre utvikling av et nytt programvareprodukt, og trenger å selge denne ideen inn til de som sitter med budsjett- og innkjøpsansvar. Du har gjort en gevinstanalyse, og den potensielle nytteeffekten er klar og overbevisende. Du har en klar visjon og en ide om den viktigste funksjonalitet du vil trenge. Du tenker videre at om jeg får de rette folkene på laget vil vi sammen kunne utvikle produktet og løse problemene vi støter på underveis. Hva svarer du da på det uunngåelige spørsmålet ”Hva vil det koste?” når selve sluttproduktet er ukjent?

 

En person med budsjettansvar vil selvsagt gjerne vite hva det vil koste å utvikle dette systemet, før beslutningen om å finansiere gildet tas. Dette initiativet må veies opp mot andre gode initiativer og vi trenger å gjøre en kost/nytte-vurdering. Så om du selger ideen din på denne måten kommer du garantert til å bli møtt med: “Du må spesifisere dette systemet og finne ut hva det vil koste!”

Du vet at komplett spesifisering av slike systemer er en illusjon. Det er alt for mye usikkerhet, kompleksitet og dynamikk til dette vil gi noen særlig verdi. All erfaring viser at det systemet du ender opp med er helt ulikt spesifikasjonen, samt at vi vil ha utviklet en masse funksjonalitet som ikke brukerne verdsetter. Og du vet på samme måte at kostnadsestimeringen er illusorisk og egentlig bare en takstisk lek med tall.

Du har nå to valg:

1. Kjøre tradisjonelt; Være taktisk, “spille spillet” og be om finansiering til å kjøre et forprosjekt, slik at du får spesifisert det nye systemet og estimert kostnadene så godt det lar seg gjøre. Deretter be om finansiering til selve prosjektet. Dette vil føles trygt og gjenkjennelig for innkjøperen og du kan regne det som ganske sikkert å i det minste få kjøre forprosjektet eller “konseptfasen”.

2. Kjøre smidig; Insistere på at det er tryggere og bedre å starte utviklingen raskt og å finansiere dette i fortløpende bolker, basert på evaluering av de resultatene som er oppnådd. Du argumenterer med lavere risiko og hurtigere gevinstrealisering samt optimalisering av brukerverdi. Dette vil allikevel føles utrygt og underlig for innkjøpere – en svært uvant måte å tenke på, og det er lite trolig at du vil få “GO”.

For å få muligheten til å gjøre dette smidig trenger du en god argumentasjon. Du må vise hvordan dette kan bli tryggere, raskere og bedre, på en pedagogisk måte. Dette er ingen enkel øvelse, men gitt at du får anledning kommer her noen gode svar på et par opplagte spørsmål:

“Hvordan kan det bli tryggere av å gjøre mindre forarbeid?”

Det blir tryggere ved at vi nå kan finansiere utviklingen løpende, i stedet for å legge store summer på bordet i starten. All erfaring viser at store leveranser er svært krevende, og at vi vil sitte med stor risiko på slutten av prosjektet, når alt til slutt skal integreres og testes.

 

RisikoNorsk

I figuren ser vi hvordan risikoen akkumuleres opp mot den store leveransen. Man vet aldri sikkert hvor vellykket et prosjekt er før det har vært i drift en stund. “The proof of the pudding is in the eating” sier Britene. Ganske riktig, det er sluttresultatet som virkelig teller. Og vi vet av bitter erfaring at når vi måler vellykketheten, må vi i tillegg ta vedlikeholdsbarheten, eller graden av teknisk gjeld med i regnestykket. Så de store, tidkrevende leveransene er per definisjon langt mer risikable enn et smidig løp der man leverer små, ferdige “puddingbiter” fortløpende og dermed “spiser opp risikoen” etter hvert som man jobber. At dette i tillegg gir en helt overlegen gjennomsiktighet og styringsmulighet, gjør ikke gevinsten mindre.

Store IT-prosjekter blir også svært krevende å organisere og styre på en fornuftig måte. Det er vanskelig for en prosjektleder å vite hva som faktisk foregår, fremdriftsmålingen usikker, og koordinering ofte et mareritt mot slutten av prosjektet.

“Hva med bruken av kalendertid?”

Vi vet at i IT-bransjen er de gode ideene “ferskvare”. Om vi ønsker en grad av innovasjon må vi evne å realisere gevinster rimelig raskt. Dette gjelder selvsagt også i ofentlig sektor. Programvare er ikke fysiske produkter slik vi er vant til i de flste andre ingeniørdisipliner. Programvare kan deles opp i små delleveranser, i stedet på å samle alt i en diger “pakke” på slutten av et prosjekt.

I figuren ser vi hvordan et tradisjonelt prosjekt typisk vil bruke svært mye kalendertid på å utvikle konseptet og å planlegge. Det gjelder naturlig nok å skaffe seg best mulig beslutningsgrunnlag for å totalfinansiere en diger leveranse et godt stykke inn i framtiden. Vi har erfaring for at slike prosjekter ofte går langt ut over rammene sine, så vi legger ekstra mye arbeid inn i forarbeidet for å redusere risikoen.

I det smidige løpet vet vi at vi kan senke skuldrene og klare oss med langt mindre analyse i forkant. Vi trenger ikke lenger å legge store beløp på bordet – dette kan finansieres fortløpende og hele satsningen kan evalueres og styres ut fra de resultatene som hittil er oppnådd. Det som blir svært viktig er å velge ut det aller viktigste å jobbe med –  i samarbeid med brukerne – slik at vi kan maksimalisere verdiskapning og læring. Rekkefølgen blir her helt avgjørende.

Gevinster realiseres dermed svært tidlig, og kommer i en ganske jevn strøm. Dette åpner for en løpende, tett dialog med brukerne slik at de kan få direkte inflytelse på de prioriteringene som gjøres og den gevinsten som skapes.

Konklusjon

Skal du kjøpe inn noe komplekst som krever kreativitet og innovasjon og som er utsatt for dynamikk mens vi jobber, bør du velge en framgangsmåte som er optimalisert for nettopp dette. Våg da å insistere på å bruke en gjennomføringsmodell som bygger på smidige prinsipper. Velg for eksempel Scrum som er et gjennomprøvd, enkelt rammeverk skreddersydd for denne virkeligheten.

Posted on January 21, 2014 at 5:23 pm by gamsjo · Permalink · 3 Comments
In: ledelse, produkteier, prosjektledelse · Tagged with: , , , , ,

Sannheter, halvsannheter og prosjektstyring

Jeg har som de fleste gått igjennom en del faser i mitt arbeidsliv. Etter å ha vært programmerer ble jeg raskt prosjektleder, så metodeansvarlig, deretter var det prosessforbedring helt fram til i dag. Prosessforbedringen har også hatt faser. I begynnelsen lå det ferdige “oppskrifter” i bunn som ISO 9001 og CMM og CMMI. Deretter var det Goal-oriented-improvement som gjalt, og i de siste 10 årene har det vært “smidig prosessforbedring”. Det som slår meg er at i hver av disse fasene har jeg hatt helt ulike forklaringsmodeller både når ting går bra og dårlig.

 

Law of the Instrument og Retrospective Coherence

“Har du en hammer vil alt se ut som spiker” lyder et ordtak. I følge wikipedia var dette071111 ep GLASSES 1 LIFE.jpg først uttalt av Abraham Maslow i 1966 og blir ofte omtalt som Law of the Instrument

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail”

Det slår meg at denne fella har jeg ubevisst gått i en rekke ganger opp i gjennom – mine mer eller mindre bastante konklusjoner har vært avhengig av min egen rolle og mitt eget fokus. Man betrakter verden gjennom helt spesielle briller. Jeg har alltid ivret for å lære av erfaring, og verdsetter objektivitet, men innser nå at dette er en svært krevende øvelse, spesielt om vi har å gjøre med komplekse systemer å gjøre! (Se også fotnote *)

Joseph Pelrine skriver om dette i sin blog post On Retrospective Coherence. Om vi har opplevd noe spesielt vellykket, er det da bare å gjenta dette til punkt og prikke? Pelrine skriver om et særdeles vellykket party. Om vi inviterer akkurat de samme gjestene, spiller den samme musikken og serverer de samme drinkene, vil vi da få en like vellykket fest? Nei selvsagt ikke nødvendigvis, i sosialt komplekse systemer er kausaliteten flyktig. Årsak-virkning forholdene utvikler mens individene interagerer med hverandre. Akkurat som innen software-utvikling! Så når vi i ettertid forsøker å resonnere om årsak og virkning, vil alle involverte lete etter svar innenfor sitt eget fokusområde – uansett hvor relevant det måtte være. En konsekvens av dette er jo at det ikke finnes noen såkalt “best practice” når vi holder på med komplekse oppgaver. I sedet må vi finne arbeidsformer som takler dynamikk og kompleksitet.

Som prosjektleder

Når jeg for mange år siden var prosjektleder i utviklingsprosjekter, jobbet jeg hardt for å bryte ned alle kravene, lage Work Breakdown Structures og milepælsplaner. Jeg sørget for å lage Gantt-diagrammer, innhente tidsestimater og synliggjøre kritisk linje. Deretter var det å analysere risiko og “massere” planen og kritisk linje slik at vi hadde godt tro på Planen. Jeg trodde fast og fullt på at prosjektets vellykkethet først og fremst ville være avhengig av godt forarbeid og av Planen. Og i etterkant av et godt prosjekt, i prosjektevalueringen, var det godt forarbeide og en god plan som ofte ble trukket fram som årsaken til suksess. Om prosjektet ikke gikk så bra, husker jeg godt å konkludere med at om vi bare hadde gjort grundigere forarbeide, og bedre planlegging ville det gått bra.

Som metodeansvarlig

Etter hvert ble jeg ansvarlig for metoder og verktøy for programvareutviklingen. Vi skulle følge Cleanroom Software Engineering og vi skulle være ISO-9001 sertifiserte. Fokus på den tiden var å etablere klare, veldefinerte prosesser. Dessuten måtte vi ha et utviklingsmiljø som i størst mulig grad var automatisert. Om vi klarte å gjøre prosessene brukervennlige, repeterbare og automatiserbare kom vi til å få suksess. Planen kunne da lages mye raskere, siden prosjektene “kom til dekket bord”. Og vi lyktes veldig bra med dette på Siemens Forsvarssystemer på 1990-tallet. Vi hadde hjelp fra forskere fra Sintef og andre steder og det ble til og med skrevet en dokoravhandling om prosessene våre. Når vi så klarte å kjøre et par prosjekter med stor grad av suksess, var det selvsagt de modne prosessmodellene våre som fikk æren.

Som prosessforbedrer

Etter hvert ble fagfeltet mitt prosessforbedring og jeg ble involvert i stadig flere forskningsprosjekter – og jeg var i den forbindelse med på en rekke prosjektevalueringer. Vi gjennomførte evalueringer (“Post Mortem analyser”) med stor innlevelse, og vi fant forbedringstiltak knyttet til planlegging og styring. Brukte vi CMM var forklaringen ofte lenger – det var mangel på “complience”, noe som selvsagt i beste fall var en grov forenkling. Det var mye som skurret hos meg på denne tiden. Var det virkelig sånn at en vel gjennomført plan var det samme som suksess? Jeg husker et prosjekt som var hårreisende dårlig gjennomført; Planen ble ikke fulgt, endringer ikke dokumentert og alle rammer sprengt. Evalueringen dømte det nord og ned. Men etter at produktet hadde vært i drift en tid, viste det seg at alle var strålende fornøyde! “Dette var verd alle overskridelsene” var omkvedet. Jeg husker også prosjekter som var kjørt helt forbilledlig, innenfor plan med all dokumentasjonen på plass. Evalueringen var positiv, men etter noe tid i drift var alle enige om at resultatet var elendig, bortimot ubrukelig.

Scrum er optimalisert for å kunne lære av erfaring. Når jeg i 2004 oppdaget dette, fikk jeg en slags oppvåkning. Det å jobbe i korte tidsbokser på 2-4 uker var med å på redusere kompleksiteten voldsomt. Når hver tidsboks var like lang, og det var de samme menneskene som gjorde jobben, fikk vi endelig en grad av repeterbarhet og kort tidshorisont, som gjorde det mulig å trekke noen konklusjoner av erfaringsmøtene. Fremdeles usikkert og vanskelig, men dette ga jo trygge omgivelser til å eksperimentere med prosessene på en måte de strore prosjektene bare kan glemme.

Prosjektsuksess?

Prosjektledere vil i henhold til Law of the Instrument og Cognitive Ressonance definere suksess innenfor de mentale modellene de bruker, med det språket de behersker. Man gransker verden med prosjektlederbriller på. Helt naturlig dette her. Og kunden og andre interessenter lytter selvsagt til prosjektlederne. Men dette gir selvsagt en farlig overforenklet analyse! Ett opplagt moment du mister på den måten er jo at du vil neglisjere vedlikeholdsvennligheten til systemet prosjektet etterlot seg. Vedlikeholdsvennligheten – eller “graden av teknisk gjeld” vil være vel så avgjørende for systemets nåverdi på lang sikt. Dette blir ikke målt i prosjekter og derfor neglisjert – og vi vet positivt at svært mange systemer i den offentlige forvaltning i dag er utsatt for store mengder teknisk gjeld. Det er lett å mistenke at arsaken ligger i at dette ikke får fokus når vi skal definere suksess.

Vi ser stadig at prosjektsuksess defineres som grad av budsjettoverskridelser og tidsoverskrivelser. Dette vil lett forføre kunder, økonomer, sjefer og andre interessenter (som sjelden forstår seg på programvareutvikling) til å tro at planene, prosjektstyring og prosessmodeller er det som virkelig teller.

For det første må vi anerkjenne at det er mange faktorer som er avgjørende og at vi må definere suksess i det rette tidsperspektivet, slik at vi får tilstrekkelig forkus på vedlikeholdbarhet. Dernest må vi snakke om gevinsten brukerne får av systemet og ikke av andre indirekte og irrelevante faktorer. Prosjektlederne og økonomene har alt for lenge fått definere suksess og dermed klart å dreie fokus vekk fra de mest avgjørende faktorene som gjelder i komplekse systemer. Suksess må måles i direkte realiserte gevinster, fornøydhet hos brukerne, vedlikeholdbarhet og hvor raskt endringer kan innføres.

Hva er egentlig avgjørende for suksess?

Alle som forstår seg på programvare og som har vært i bransjen en stund, vet at estimatene er ekstremt usikre, Planen er kun gyldig en liten stund og at vi til tross for grundig forarbeide er nødt til å improvisere en hel del underveis. Dette er helt normalt og helt OK i komplekse arbeidsoppgaver. Så, under slike forutsetninger, hva er det da vi må være gode på? Hvis det ikke er planlegging og prosjektstyring, hva er det da?

Så vidt jeg kan skjønne koker det ned til at vi setter klare effektmål, at de som gjør jobben er engasjerte, motiverte og kompetente, at disse får tillit og store fullmakter, samarbeider godt med brukerne, at vi klarer å dele opp produktleveransene i små delleveranser som evalueres fortløpende, at vi evner å lære av erfaring og at vi klarer å prioritere og sikre at vi bruker tid og krefter på det som virkelig betyr noe for brukerne.

Dette er i hvert fall min evaluering som smidigentusiast. Kanskje kommer det noe etter smidig, vi får se om jeg ser likt på dette i neste fase…

 

*) Oppdatering: Vår trang til å overforenkle er også forklart på en utmerket måte i boka Thinking, fast and slow av nobelprisvinner Daniel Kahneman. Han beskriver her fenomenet WYSIATI (What You See Is All There Is). Vi fokuserer intuitivt kun på det som er synlig for oss, og neglisjerer ubevisst andre faktorer – hvilket fører til overforenklede analyser når vi skal ta beslutninger.

Posted on January 6, 2014 at 12:49 pm by gamsjo · Permalink · Leave a comment
In: ledelse, prosjektledelse, Samfunn, Scrum · Tagged with: , , , , , ,

Endre organisasjonen sa du? Lykke til!

Organisasjoner er optimalisert for produksjon og å få mest mulig effekt ut av det bestående. Samtidig er de fleste ledergrupper i 2013 smertelig klar over at de må klare å takle endringer i markedet på en bedre måte enn de gjør i dag.

 

Organisasjoner av en viss alder er gjennomgående strukturert på samme måte. Vi finner hierarkier med faglig orienterte enheter med en ansvarlig sjef for hvert område. Man måler gjerne sjefene og enhetene separat i et hierarki av KPI-er. I tradisjonelle organisasjoner er det også gjennomgående stort fokus på roller med detaljerte stillingsbeskrivelser. Mange har pekt på at slike strukturer er optimalisert for repeterende produksjon og vil kunne være effektive så lenge det ikke er for mye dynamikk. De er altså ikke optimalisert for å takle endringer i markedet.

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change – Charles Darwin

Vi ønsker altså endringer. Samtidig er det veldokumentert at svært mange endringsinitiativer feiler. Les gjerne John Kotters arbeid på dette området  som peker på de 8 trinnene i figuren. Les gjerne denne også som fokuserer på at vi har mer enn nok ”management” i dag, det vi behøver mer av er ”leadership”.

Kotter8StepModel

Så hva skal til for at sårt tiltrengte endringer faktisk blir gjennomført? Punktene til John Kotter er fremdeles gode rettesnorer. Og så er det selvsagt slik at en uredd og dedikert ledelse må stå bak dette.

A propos ledelse: Kotter peker i artikkelen på at ledelse skjer på alle nivåer. Dette er spesielt dedikerte folk som av ulike grunner får med seg andre, helt uavhengig av formell posisjon i hierarkiet. Disse er helt nødvendige for at endring skal skje. De  leder an, skaper entusiasme og sørger for at alle gode krefter spiller sammen mot målet.

Det diskuteres stadig om endring bør komme ”ovenifra” eller ”nedenifra”. Det riktige svaret er selvsagt ”begge deler”. Man kan ikke pådytte medarbeiderne omfattende endringer og forvente helhjertet støtte til dette. Særlig ikke i kunnskapsbedrifter. Nedenifra og oppover kan fungere i mindre organisasjoner (særlig i Norge hvor skillet mellom ledelse og medarbeider ikke er så påtakelig), men ledelsen må selvsagt involveres for å stake ut retning og sørge for å sette av ressurser til innføring av endringene. Endringer har alltid en kostnad.

 

Nå vi er hos kunder er ofte oppdraget ”å hjelpe til med å innføre Scrum” eller ”vi trenger å bli mer smidige”. Det er ikke alle ledergrupper som er klar over hvor mye endring dette innebærer. Selv om Scrum er en fantastisk fin modell, vil vi alltid insistere på at vi må vire hvorfor vi gjør dette. Hvilket problem skal vi løse med Scrum? Er dere helt sikkert på at Scrum er det rette? Scrum er et svært enkelt rammeverk med veldig stor frihetsgrad. Man må gjøre en mengde valg selv og for å gjøre gode valg trenger vi å vite hvor vi vil! Hvorfor setter vi i gang med disse endringene? Hva er intensjonen. Hva er visjonen?

Jeg har skrevet en del om dette tidligere og her er en presentasjon fra Smidig 2013 om temaet.

I Axio bruker vi en enkel modell for smidig omstilling. Denne støtter Kotters 8 punkter, samtidig som vi kan se to typiske ”PLan-Do-Study-Act” sykluser. SmidigOmstillingQIP3Fokuset er å innføre nye modeller og arbeidsformer i sykler og å evne  trekke ut erfaringer underveis. Modellen har to sykluser på hvert sitt nivå; organisasjonens læring og iterasjonslæring på operativt nivå. Modellen er inspirert av Quality Improvement Paradigm (QIP) av Prof. Vic Basili ved Univ. of Maryland.

Prosessen går som følger:

  1. Forstå situasjonen. Vi bruker tid i starten på å sikre at alle involverte har et felles, klart bilde av situasjonen. Har vi konkrete problemer å løse, eller ønsker vi endringer fordi det er forretningsmessige ambisjoner som vil kreve endring? Hva sier kundene/brukerne? Hva sier utviklerne? Her gjennomfører vi en workshop med ledergruppa, samt gjennomfører en del fokuserte intervjuer med representative medarbeidere i ulike funksjoner.
  2. Sett mål. Basert på 1. må vi konkretisere visse målsetninger så vi er sikre på at alle jobber i samme retning. Her lager vi gjerne et ”strategikart” som har målet i midten, suksessfaktorene rundt målet og nødvendige betingelser på utsiden av suksessfaktorene.
  3. Her gjør vi visse valg. Skal vi innføre Scrum overalt eller kanskje en blanding av Scrum og Kanban. Hva starter vi med? Samle alle køene i én produktkø kanskje? Etablere produkteierrollen? Hvordan deler vi opp i feature team? Skal vi kun kjøre en pilot med ett team – og så høste maksimalt med erfaringer fra dette før vi går ut i større bredde? Hvordan skal vi måle om vi beveger oss mot målet?
  4. Så gjelder det å lære så mye som mulig fra iterasjonene vi kjører. Her samler vi data, høster erfaringer, fjerner hindringene vi støter på og sikrer at vi får maks utbytte av retrospektivene. Her vil Scrum Master rollen være uvurdelig. Om man virkelig ønsker endring vil en dedikert, entusiastisk Scrum Master som våger å utfordre Status Quo når det er nødvendig kunne utgjøre en vesentlig forskjell.
  5. Når vi har samlet erfaringer må vi sjekke ut dette mot de organisasjonsmessige målene og gjøre noe analyser av resultatene.
  6. Vi gjennomfører her gjerne en tverrgående workshop der vi diskuterer resultatene så langt og sjekker ut at alle er enige om vi faktisk er på vei mot en forbedring eller ikke.

Så er det å gå til 1. igjen og revurdere situasjonsbeskrivelsen, sjekke ut om målene fremdeles er de rette og så videre.

 

Posted on November 10, 2013 at 4:22 pm by gamsjo · Permalink · Leave a comment
In: Endringsledelse, ledelse · Tagged with: , ,

Smidig kontraktsstandard på 3 uker

Vi har gjennom de siste årene samlet mye erfaring med smidig systemutvikling – både nasjonalt og internasjonalt – og vi vet i dag mer enn nok til å lage en kontraktsstandard som legger til rette for å kunne høste alle gevinstene smidig gjør mulig. Det gjenstår bare å gjøre det.

 

La oss tenke oss at vi ga et lite team på la oss si 4-5 ildsjeler muligheten til å jobbe på nærmest full tid med å lage en slik tekst. Da ville de kunne fullført denne jobben på svært kort tid – omkring 3 uker bør være nok. (Nå vil et slikt estimat selvsagt være svært avhengig av hvem som skal gjøre jobben, så tidsplanen vil ha en ganske stor usikkerhet knyttet til punkt 0. under i planen. Vi må her ende opp med et team der ingen har andre interesser enn å ende opp med en best mulig smidig standardkontrakt.)

Planen kunne se omtrent slik ut:

0. Samle sammen noen få smidigentusiaster med tverrfaglig bakgrunn
1. Gjennomgå smidig og bli enige om en felles forståelse. Vær eksplisitte på dette. (2 dager)
2. Bli enige om hvorfor vi trenger en smidig kontraktsstandard og vær ekspisitte på dette (1 dag)

Hint:
Ta vesentlig bedre vare på IT-investeringene gjennom å
* Halvere tiden fra behov til tilfredsstilt behov
* Dramatisk minske teknisk gjeld
* Redusere risiko
* Øke styringsmulighetene
* Minske sløsing (waste)

3. Kast (evt brenn) de gamle standardene under en enkel videodokumentert seremoni (1 time)

4. List opp de egenskapene vi ønsker oss av en ny kontraktsstandard (1 dag)

Hint:
* Gjennomsiktighet
* Læring underveis
* Unngå teknisk gjeld
* Ikke sløse med tid i oppstartsfasen
* Minske risiko
* etc..

5. Lag kontraktsstandard basert på tydelige smidige prinsipper og pkt 4. (2 uker)

Hint:
* Åpent Scope med én publisert, grovestimert og sortert produktkø
* Time & Material basert
* Tidlig førsteleveranse
* Hyppige leveranser med læring og aksept for å feile
* Tverrfaglig ende-til-ende-samarbeid
* Enkel, rask exit-mulighet

Vips, ny kontraktsstandard!

Når standarden så foreligger begynner jo det egentlige arbeidet – den smidige standarden er naturlig nok svært forskjellig fra det man er vant til, så her må det endring til. Endring skjer som kjent ikke helt av seg selv.

En plan for denne endringen kan se omtrent slik ut:

1. Kjør noen pilotprosjekter basert på kontraktsstandarden (1-2 år)

* Definer piloter
* Velg leverandører / utviklere med solid smidigerfaring
* Gjennomfør opplæring i smidig
* Gjennomfør piloter med coaching underveis
* Mål effekter underveis

2. Oppsummer piloter (noen uker)

* Lag/oppdater veileder og kursmateriale basert på pilotene

3. Institusjonaliser ny arbeidsform basert på smidig (en del år)

 

Som mange lesere av denne bloggen kjenner til finnes det i dag et par kontraktstandarder som hevder å være smidige. Dette er SSA-S som Difi har jobbet på siden 2005 samt PS 2000 som også ble påstartet på midten av 2000-tallet. Ingen av disse er eksplisitt smidige med åpent omfang, aksept for å feile, fokus på hyppige leveranser med læring. Etter 7-8 år…

 

Posted on November 1, 2013 at 4:33 pm by gamsjo · Permalink · Leave a comment
In: kontrakt · Tagged with: , ,