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.

Smidigavtale med bonuser fra DIFI

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

7 typiske særtrekk for programvareutvikling

1. Vi kan velge å levere i små inkrementer

2. Selve produktet er i praksis usynlig

3. Løsningsrommet er nærmest uendelig

7. Livsløpskonstnaden avgjøres av vedlikeholdsvennligheten

Konsekvenser

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.

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.

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

• Kjernen i planen er bare en liste med grovestimert funksjonalitet, kalt Produktkø
• Produktet bygges “sten på sten” i iterasjoner (Sprinter) av fast lengde (typisk 2-3 uker).
• Produktkøen skal ikke være “komplett” i starten, men må ha nok substans til at vi kommer godt i gang (arbeid for 3 sprinter bør være ganske veldefinert)
• Vi skal i størst mulig grad være styrt av lærdom (empirisk prosesskontroll) så her gjelder det å raskest mylig lage et produktinkrement som er kjørbart og analyserbart som gjør at vi er trygge på at vi er på rett vei.
• Jobben gjøres i utgangspunktet av ett tverrfaglig team
• Når produktet er vel oppe å kjøre – dog med begrenset funksjonalitet – gjelder det i tett kontakt med brukerne å levere verdifull funksjonalitet så hyppig som mulig.
• Utviklingen er kontinuerlig, uten fastlagt sluttermin – vi gjør løpende kost/nytte vurderinger og vurderer arbeidet opp mot andre ting i porteføljen.
• Om vi trenger å øke hastigheten på utviklingen kan vi øke teamstørrelsen (maks 9) eller sette på flere team.
• Vi regner ikke med at ting fungerer perfekt fra starten av (dette er urealistisk), men derimot at vi tar små skritt og forbedrer arbeidsprosessene gradvis mens vi jobber.

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.

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

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.

Kunsten å kjøpe det ukjente

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.

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.

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 dette 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.

Endre organisasjonen sa du? Lykke til!

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”.

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. Fokuset 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.

Smidig kontraktsstandard på 3 uker

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…

Innstilling og tankesett

Noen blir ivrige og sier ting som at “dette vil kreve mye endring, jeg kan ikke vente med å sette i gang!” Andre parkerer det jeg snakker om: “det der går ikke an hos oss fordi ___________” (fyll inn selv).

Jeg er egentlig ikke tilhenger av å generalisere og å putte folk inn i to ulike båser. (Det er to typer mennesker: De som kategoriserer folk i to typer og de som ikke gjør det. Hehe.) Men enkelte ganger kan jeg ikke hjelpe for det. Det synes å finnes to kategorier mennesker. Og team. Og organisasjoner. Det er de som blir ivrige og får en ekstra gnist i øynene når vi begynner å snakke konkret om endringer. Og det er de som jeg mister litt, de får et matt uttrykk i ansiktet og møter ikke blikket mitt.

Det er forresten uhyre sjelden folk protesterer på det jeg sier. Jeg opplever at de aller fleste a) vet at det er mye som ikke fungerer godt der de er i dag og b) ser at smidig tilnærming kan bøte på flere av problemene. Men det å intelektuellt sett akseptere at smidig antageligvis er bedre, er tydeligvis ikke nok. Det har forresten kun skjedd én gang at en kursdeltager har reist seg og sagt “jeg har bedre ting å bruke tiden min på enn å sitte og høre på dette her!”.

Selv om de aller fleste kjøper smidig og gjerne vil ha effektene av dette, viser all erfaring at endringen går utrolig sakte og veldig mange snubler stygt i sine bestrebelser på å innføre Smidig. Jeg har hatt ulike teorier om dette og blant annet skrevet om det her.

Nye tanker har i det siste fått næring blant annet av en veldig god, forskningsbasert bok av Dr. Carol S. Dweck kalt

Mindset, The new phsychology of Success. Dweck har gjennomført en lang rekke studier av hvordan mennesker, spesielt barn, oppfører seg i forhold til hva slags innstilling de har til det å prestere. Hun deler folk i to grupper; De med fixed mindset og de med growing mindset. De med fixed mindset mener/tror at folk har visse talenter og at dette er ganske fastsatt, mens de med growing mener at alle kan bli bedre i hva som helst, bare de gjør en innsats. Jeg må si en del brikker falt på plass hos meg når jeg leste hva Dweck skriver.

Ta denne studien her for eksempel: I USA er det i visse miljøer en ganske klar oppfatning om at jenter er dårligere i matte enn gutter. Hvor disse oppfatningene kommer fra kan man spekulere i selvsagt, for det har ikke rot i virkeligheten. Men det er ikke poenget her. To grupper jenter ble satt til å løse matteoppgaver. Begge gruppene fikk samme oppgave, den eneste forskjellen var at gruppe 1 måtte sette ett ekstra kryss for hvilket kjønn de hadde. De som fikk den ekstra avkrysningen presterte dårligere enn den andre gruppa. Hvorfor? Fordi de ble minnet på at de var jenter. Denne inngrodde tankegangen var nok!

“Hva er det som får deg til å føle deg smart? Er det at du leverer perfekt uten feil, eller er det at du har lært noe?” Fixed mindset folk vil gå for det perfekte, og vil nyte skryt av hvor flinke de har vært, men vil sky store utfordringer av frykt for å ikke få det til. Og motsatt, de kan lett bli deprimerte om de blir kastet ut i noe de ikke behersker og de leverer dårlig. Jeg er dårlig blir jo konsekvensen.

En med growing mindset som mislykkes vil slå seg til ro med at jeg prøvde ikke hardt nok – neste gang skal jeg få det til!

Om vi tar med oss denne tankegangen til organisasjoner blir det veldig spennende! De stedene jeg sliter med å få gehør for endring er jo typisk de “konservative” som sier “det er sånn vi gjør ting her hos oss”. Og ikke bare det, men de har målinger som premierer å lykkes, men ikke premierer læring. I offentlig sektor har de New Public Management som blant annet fører til at “alt” skal måles og premieres. I deler av privat sektor er det vanlig med Management by Objectives med tilhørende Key Performance Indicators. Vil noen disse regimene fokusere på læring? At man utvikler seg? At man våger å ta sjanser og feile, for å lære? Hvordan skal man måle slikt forresten? Nei, for meg virker det som om måleprogrammer i skolen, og i arbeidslivet (offentlig og privat sektor) har det til felles at det institusjonalisere et fixed mindset.

Vel. Måling eller ikke måling; Det rådende tankesettet i en organisasjon er jo det man kan kalle firmakultur, og det virker som denne kulturen også kan være fixed eller growing.

En av heltene mine i Agile-verdenen er 71 år gamle Linda Rising. Hun hadde nylig en Keynote på Agile2013-konferansen, der hun nettopp snakket om dette med Mindset. Hun refererer også til Carol Dweck, men hun tar seg den friheten å tweeke begrepene litt. I stedet for å kalle det growing mindset bruker hun Agile mindset. Dette er jo nettopp det vi legger i agile argumenterer hun. Nettopp!

Smidig forutsetter jo et growing mindset! Jeg hører stadig at organisasjoner “får beskjed” overifra om å bli mer innovative. I mitt hode betyr dette “våg å ta fler sjanser!”. “Verdsett læring over perfeksjon!” Men da må også styringssystemet være skrudd sammen for dette.

Bruk gjerne 1 time på presentasjonen til Linda Rising. Dette krever at du har en viss relasjon til Agile Alliance, trykk Subscribe/Confirm Subscription hvis du ikke er medlem. Dette er helt gratis og vil ikke drukne deg i spam.

• En Smidigblogg av

  Lean Venture

• Ressurser

  • Agile (is) Risk Management (video)
  • Debugging the organisation with Scrum (video)
  • Presentasjoner (slideshare)
  • Prosjektveiviseren med Scrum (video)
  • Raskere, billigere, tryggere,bedre (video)
  • The Power of Why (video)
  • Tidstyveri (video)

• Temaer

  Ansvarliggjøring Brukervennlighet Business Model Generation Coaching Customer Development DevOps DRM endringsledelse EVO eXtreme Programming fildeling forretningssiden forskning gruppedynamikk innovasjon ITIL Kanban kommunikasjon kompleksitet kontrakt kundeverdi kunnskapsdeling Kvalitet Lean Lean Startup ledelse ME målstyring opphavsrett organisasjon Prioritering produkteier prosessforbedring prosjektstyring saksbehandling Scrum ScrumBut sertifisering Skalering Smidig Styring systems thinking ulovlig fildeling

• Siste kommentarer

  • Heidi Ihle Edvardsen on Kurs
  • gamsjo on Ny versjon av Scrum Guiden – hva er nytt?
  • Ronny Justsen on Ny versjon av Scrum Guiden – hva er nytt?
  • gamsjo on Å planlegge for det ukjente
  • Jon Steinar Kjøllesdal on Å planlegge for det ukjente
  • Det smidige hjørne » Å planlegge for det ukjente on Det perfekte team
  • Det smidige hjørne » Å planlegge for det ukjente on Empirisk prosesskontroll

• Arkiv

  Arkiv Select Month August 2023  (1) August 2022  (1) July 2022  (1) August 2021  (1) May 2020  (1) August 2019  (1) December 2017  (1) April 2017  (1) February 2017  (1) December 2016  (1) November 2016  (1) September 2016  (1) July 2016  (1) June 2016  (1) May 2016  (1) March 2016  (1) February 2016  (2) December 2015  (1) November 2015  (1) October 2015  (2) September 2015  (2) August 2015  (2) February 2015  (2) January 2015  (1) November 2014  (4) October 2014  (2) August 2014  (2) July 2014  (2) June 2014  (1) April 2014  (1) March 2014  (2) February 2014  (1) January 2014  (3) November 2013  (2) September 2013  (1) August 2013  (1) July 2013  (1) June 2013  (1) May 2013  (1) April 2013  (1) March 2013  (3) February 2013  (1) January 2013  (1) November 2012  (1) October 2012  (1) September 2012  (2) August 2012  (1) July 2012  (2) June 2012  (1) May 2012  (1) April 2012  (3) March 2012  (1) February 2012  (1) January 2012  (2) October 2011  (1) August 2011  (1) July 2011  (1) June 2011  (1) April 2011  (1) February 2011  (1) December 2010  (1) November 2010  (1) August 2010  (2) July 2010  (1) May 2010  (1) March 2010  (1) February 2010  (2) December 2009  (1) November 2009  (3) October 2009  (2) September 2009  (1) August 2009  (3) July 2009  (1) May 2009  (1) April 2009  (5) March 2009  (5) February 2009  (6)