Tid er penger
Vi har opparbeidet en aksept for de tre T-er: “Ting Tar Tid”. Men må det være sånn? Er det smart å akseptere at saker må legges i køer og dermed ta lang tid å behandle? Kan vi ikke i det minste få løst det mest prekære problemet kjapt, i stedet for å legge det i kø? Betimelige spørsmål som vi burde stille oss oftere.
Ventekostnader – Cost of Delay
I bygg- og anleggsbransjen er det opplagt at en leverandør vil ha krav på å få kompensert kostnader om de må vente med oppstart. De har tross alt reservert dyrt materiell og arbeidskraft for et gitt oppstartstidspunkt, så en forsinkelse blir da ren kostnad.
I IT-bransjen er det helt uvanlig å operere med ventekostnader, kanskje fordi disse kostnadene ikke er like oppe i dagen som i andre bransjer. Materiell har vi ikke på samme måten og arbeidskraften kan ofte brukes på andre oppgaver i påvente av oppstart. Men hva med brukerne som har sett fram tid en sårt tiltrengt forbedring? Hva med gevinstene som blir utsatt? Bør vi ikke kalkulere med disse?
I følge Don Reinertsen forfatter av The Principles of Product Development FLOW er de fleste i IT-bransjen blinde for denne effekten. Og dette til tross for at den økonomiske effekten er betydelig. Dessuten kan COD-kalkyler utgjøre et veldig nyttig instrument i produktplanleggingen.
If you only quantify one thing, quantify the Cost of Delay. Don Reinertsen
Boka fokuserer på de økonomiske effektene av produktutvikling og introduserer en stor mengde prinsipper for planlegging og styring. Ideen er å øke flyten på de delene av produktet som gir antatt størst gevinst og som det dermed blir mest kostbart å utsette. En svært smidig tankegang med andre ord.
Figuren er hentet fra en god beskrivelse av Cost of Delay fra Black Swan Farming. Som vi ser er COD rett og slett den akkumulerte gevinsten vi går glipp av ved å vente med implementasjonen. Vi forstår at vi ideelt sett bør sette i gang så fort vi har identifisert en gevinst som er mulig å realisere. Og så vet vi at det vil være en rekke potensielle gevinster som står i kø for å realiseres, men vi har en begrenset kapasitet. Så vi må prioritere – hva skal vi gjøre først? Hvorfor ikke da prioritere å gjøre det som har den høyeste COD dividert på kostnad? Her er en mer inngående beskrivelse av denne prioriteringsmekanismen.
Tradisjonell prosjektledelse har veldig svake konsepter for prioritering. I stedet blir det ofte slik at “alt skal med”. Vi planlegger for kompletthet. Vi forplikter oss til å levere et stort omfang, som vi jobber med i paralell. Konsekvensen blir da at gevinstene forsinkes voldsomt i forhold til potensialet. Hva koster dette?
Det er fristende å ta med COD i analysen av de store IT-skandalene vi har sett i offentlig sektor i den senere tid. Hvis vi ser på de planlagte gevinstene i Moderniseringsprosjektet til NAV – som ble stoppet – dreier dette seg ikke akkurat om småbeløp. Prosjektet har pågått i mange år – ble i realiteten startet rundt 2008 – og det er siden dette ikke gjort mye annet enn å analysere og planlegge. Ingen vesentlige gevinster realisert ennå. Totalgevinsten antydes til rundt 4 Mrd kroner “netto nåverdi mot nullalternativet” i KS1-rapporten. Det skal spares ca 2000 årsverk. Når da dette prosjektet i fjor ble stoppet, betyr det at det fremdeles “løper” en anselig COD!
Alle synes nå omsider å være med på at vi må dele opp disse mammutprosjektene i mindre biter. Det er på høy tid. Men da trenger vi helt andre metoder og ikke minst annen kompetanse i startfasen. COD bør innarbeides som en naturlig del av den samfunnsøkonomiske analysen. Som Arild Haraldsen er inne på i denne artikkelen er disse analysene en svært krevende øvelse med stor usikkerhet og mange fallgruber. Men det er ingen løsning å gjøre analysene “grundigere”. Øket tidsbruk vil jo bare øke COD. Igjen, det gjelder å balansere tidspress mot grundighet hvilket må innebære oppsplitting og at de opplagte, største gevinstene realiseres først. En aktiv bruk av COD vil automatisk kanalisere innsatsen mot de områdene med størst gevinstpotensiale. Da vil vi se at de sære unntakstilfellene godt kan vente. Vi behøver ikke alltid lage løsninger som skal treffe “alle”, ofte ligger 80-95% av verdien i å automatisere operasjoner for det typiske tilfellet. Særtilfellene kan vi vente med, eller eventuelt leve med manuelle operasjoner, siden volumet er lite.
Flytoptimalisering fremfor ressursoptimalisering
Boka Dette er Lean er nå Sveriges mest leste bok om ledelse. I denne boka tar Niklas Modig et kraftig oppgjør med den tradisjonelle ressursoptimaliseringen – en filosofi som passer svært dårlig til kunnskapsbasert arbeid i vår tid. Han skriver her om løsningen på effektivitetsparadokset. Problemet er enkelt sagt at vi legger sakene i kø fremfor å bare løse saken med en gang. Disse køene er et valg – en konsekvens av tankegangen og organiseringen der vi jobber med mange saker på en gang og der vi dyrker spesialiserte roller som arbeider hver for seg i stedet for tett teamarbeid. Et sterkt tverrfaglig team med myndighet vil kunne ta unna innkommende arbeid “én sak av gangen”.
Nå en sak ligger i kø skapes det sekundærbehov. Disse behovene vil også belaste systemet, og ofte være til stor ulempe for brukerne. Søknad om foreldrepenger har i mange år vært en ganske uforståelig vanskelig prosess – noe som fører til at en gjennomsnittelig søker må ringe inn flere ganger og få hjelp for å gjennomføre en i utgangspunktet enkel oppgave. NAV har i denne perioden sysselsatt et helt “scannekontor” som jobber med å scanne inn søknader som tidligere er printet ut. Når brukere venter på den endelige løsningen vil de naturlig nok lage seg sine små hacks – midlertidige løsninger. Det er klart disse helt unødvendige ulempene vil koste tid og penger – og må tas med i regnestykket når vi prioriterer.
Denne bevisstheten om å optimalisere flyten, sammen med aktiv bruk av Cost of Delay og smidige metoder vil på sikt kunne gi en langt mer effektiv og økonomisk sunn offentlig sektor.
In: Lean, Planlegging, prosjektledelse, Samfunn, Uncategorized, Ventekostnader · Tagged with: forretningssiden, ledelse, organisasjon, prosjektstyring, Styring
IT-fadeser: Om læring og mentale modeller
Vi blir stadig påminnet om hvor vanskelig det er å lykkes med IT-prosjekter. Og det virker som problemet er økende. Vi leser om hundrevis av millioner som sløses bort, uten at særlig verdi er skapt.I kjølevannet av dette blir selvsagt bransjen svar skyldig. Hva kan vi gjøre for å bøte på dette? Hva kan vi lære av det? Per-Morten Hoff i IKT-Norge vil ha mer styring og havarikommisjon, Cathrine Klouman i DnD vil at vi skal våge å feile – i forprosjekter før det ordentlige prosjektet starter, Difi ved seksjonssjef Ellen Strålberg vil ha enda mer kvalitetssikring før oppstart (obligatorisk KS1 og KS2) samt obligatorisk bruk av prosjektveiviseren. Professor Magne Jørgensen på Simula analyserer også prosjektsuksess, og kommer til at det synes som det kan lønne seg å kjøre “smidige prosjekter” som jobber iterativt og at det er vanskelig å estimere.
Alle disse analysene baserer seg på én felles mental modell av IT-utvikling, nemlig at dette skal skje gjennom å starte et prosjekt. Et prosjekt er som alle vet en fokusert innsats mot et konkret mål gjennom å etablere en midlertidig organisasjon. Vi tenker noe ekstraordinært som ikke kan kjøres “i linja”. Og når vi hører ordet prosjekt vil de fleste av oss også umiddelbart tenke faser. Vi får en analysefase, en planleggingsfase, en oppstartsfase, en gjennomføringsfase, en leveransefase, en avslutningsfase og til slutt en lang driftsfase der en annen organisasjon drifter og vedlikeholder prosjektresultatet. Vi tenker “plan the work – work the plan”.
En typisk fasebasert modell for prosjektplanlegging og -styring (hentet fra prosjektveiviseren.no).
Så med denne klare, intuitive modellen godt forankret i underbevisstheten skal vi altså forsøke å lære av erfaring. Helt naturlig da å tenke siden dette er så vanskelig og risikabelt, må vi gjøre grundig forarbeide og forsøke å “tenke på alt” før vi bestemmer oss for å sette i gang. Og like naturlig å tenke at vi må ha enda bedre styring og kontroll underveis.
Mentale modeller er kraftige saker og de vil påvirke oss sterkt i hvordan vi forstår verden rundt oss og hvordan vi analyserer årsakssammenhenger. I den etter hvert legendariske boka The Fifth Dicipline – The Art & Practice of The Learning Organisation viser Peter Senge hvor avgjørende våre rotfestede mentale modeller vil være og at vi aldri må ta disse for gitt. Vi må alltid ta de med i betraktining i våre analyser. Mentale modeller er en av de 5 disiplinene lærende organisasjoner må beherske. De andre er Personal mastery, Building a shared vision, Team Learning og til slutt den femte og mest avgjørende Systems Thinking.
La oss forsøke å bytte ut den intuitive mentale modellen vi får fra prosjektbegrepet. La oss et øyeblikk tenke at vi kanskje ikke hadde behøvd å behandle IT-utvikling som noe ekstraordinært og stort som krever en egen organisasjon. La oss tenke at vi delte opp problemet i mindre biter, prioriterte disse og leverte resultater i små deler. Og at IT-utvikling er noe som pågår ganske kontinuerlig og som faktisk kan kjøres “i linja” i permanente team. Da får vi et helt annet bilde av IT-utvikling.
En alternativ, prosjektløs modell for IT-utvikling
Så med denne mentale modellen på netthinnen, hvilke tiltak ville vi nå anbefale for å lykkes med IT-utvikling? Det må jo da bli slikt som “vår evne til å levere små inkrementer av resultatet og å lære av disse”. Eller “vår evne til å løpende planlegge neste iterasjon uten å miste hovedmålet av syne”, “Vår evne til å fange opp brukernes basale behov underveis”. Kanskje “vår evne til å stoppe opp når kostnadene overstiger verdien”. Slike ting. Altså helt andre ting.
Ville det ikke vært verd et forsøk Difi, DnD, IKT-Norge, Simula og ellers alle som er opptatt av pengebruken i offentlige IT-satsninger?
In: Planlegging, prosjektledelse, Risko, Samfunn · Tagged with: endringsledelse, ledelse, organisasjon, prosjektstyring, systems thinking
Risiko og innovasjon
“No pain – no gain”. “Den som intet våger intet vinner”. Alle forstår at om vi vil oppnå noe bra så innebærer det ofte også en viss risiko. Slik er det selvsagt også med IT-prosjekter. Men hvordan forholder vi oss til risiko i IT-prosjekter? Hva slags strategi skal vi ha for å håndtere denne?
Mye tyder på at vi er i ferd med å bli alt for risiko-averse i dette landet. Særlig i offentlig sektor, hvor vi virkelig trenger innovasjon!
Tankegangen innen innkjøp, styring og ledelse er at vi må forsøke å eliminere risikoen ved å gjøre grundige foranalyser, gjerne forprosjekter, før vi tar på oss økonomiske forpliktelser. Dette er intuitivt og fornuftig i mange sammenhenger. Grundig analyse og planlegging gjør at selve gjennomføringen går på skinner. Dette er sant, gitt noen rammebetingelser nemlig at vi
a) er i stand til å overskue og forstå problemet gjennom analyser og
b) har en grad av stabilitet underveis slik at forutsetningene vi må legge i starten ikke endrer seg
Men hvor godt fungerer denne tankegangen for IT-prosjekter? Har vi disse rammebetingelsene? Klarer analyser å gi oss den nødvendige forståelsen og har vi denne stabiliteten?
I offentlig sektor skal IT-prosjekter gjennom kvalitetssikringsmilepælene KS1 og KS2. Dette representerer to nivåer av beslutningsgrunnlag – for å sikre at vi bruker penger på prosjekter som gir større nytteverdi enn de koster. Dette er svært rigorøse og omfattende prosesser. I moderniseringsprosjektet til NAV kan vi lese et 177-siders dokument som er kvalitetssikringen av KS1 – konseptvalg (Takk til Tom Gilb som viste meg dette). Det er lett å se at dette skal bli et gigantprosjekt! Nesten et år senere (april 2012) kommer KS2-av prosjekt 1 et dokument på ca 100 sider. Deretter skal prosjektet utlyses på anbud, løsningsbeskrivelser og kravspesifikasjoner skrives osv.. Vi snakker 3-4 år før noen begynner å lage en kodelinje. Nå vet vi jo også fasiten – prosjektet ble stoppet og 3-4 år av moderniseringen gikk tapt. Pluss noen hundre millioner kroner. NAV-direktør Joachim Lystad uttaler i 2015:
Hovedårsaken til det var at det i 2010 ble planlagt å kombinere ny saksbehandlingsløsning for Nav med en løsning for uførereformen. Det viste seg å være feil.
En antagelse tatt for mange år siden fikk med andre ord leve lenge i prosjektet før man fant ut at den var feil…
Systemet legger opp til følgende håndtering av risiko: Jo større prosjekter, desto grundigere analyser og forarbeide. Samtidig vet vi at de som gjør dette forarbeidet er spesialister på nettopp dette – så de vil sette sin ære i å gjøre dette grundig og komplett. Vi vet jo også at de konsulentselskapene som leverer analysene vil ha noe å tjene på at omfanget blir stort. Derfor ser vi gang på gang at noe som i utgangspunktet er stort, lett blir enda større i analysefasen! Det er mange krefter som spiller inn her, blant annet a alle interessentene vet at det blir lenge til neste prosjekt, så de vil presse på for å komme med i prosjektet – og det blir enda større! Vi må også være klar over at verden rundt oss er omskiftelig og dynamisk, slik at sannsynligheten for at antagelser rekker å bli utdaterte allerede mens vi analyserer og planlegger er stor…
Uheldige virkninger av grundig, tidkrevende forarbeid
Og så kommer MilliardKronerSpørsmålet: “Hvor gode betingelser har et slikt prosjekt for å lykkes?” Ikke så veldig gode. Det finnes mange studier som analyserer IT-prosjekter. Disse er ikke alltid samstemte, bortsett fra en ting: Samtlige advarer mot å kjøre store prosjekter!
Vi som har vært ute en vinterdag eller to ser dette lett. IT-prosjekter er komplekse og for mange overraskende vanskelig å spesifisere korrekt på forhånd. Til det er behovene for ulne og abstrakte, og antall krav får fort en uhåndterlig størrelse. Dessuten blir selve prosjektet selv et svært komplekst, dynamisk sosialt system. Og til alt overmål har vi dynamikken, de uventede hendelsene (som vi vet kommer) og ønsket om innovasjon.
Store prosjekter kommer fort inn i en ond sirkel med økende kompleksitet og liten tid til innovasjon
Innovasjon betyr blant annet å ta vare på de gode ideene og mulighetene som oppstår underveis.
Alle disse sammenhengene skulle borge for å forsøke å unngå store prosjekter. Men disse sammenhengene er på en måte ikke det mest skremmende! Det mest skremmende er at i store prosjekter med få leveranser, vil feilaktige antagelser få lov til å leve alt for lenge. Dette er et system uten feedback, uten læring slik at den akkumulerte økonomiske risikoen blir skyhøy! Vi vet per definisjon ikke om det har vært vellykket før leveransen er idriftsatt og vi kan analysere hvordan den faktisk fungerte i praksis.
“The proof of the pudding is in the eating”
Britene vet at det er overraskende vanskelig å lage en perfekt pudding. Vi vet ikke om resultatet ble vellykket før puddingen er ferdig. Akkurat på samme måten er det med IT-prosjekter.
Dette innebærer at jo lengre vi venter med å fullføre noe, desto større akkumulert økonomisk risiko tar vi. Dette er jo innkjøpere og prosjekteiere klar over, men resepten med å analysere enda grundigere for å minske risikoen duger altså ikke. I stedet kan vi ta virkeligheten på alvor og akseptere usikkerhet og risiko.
Vi kan lære oss å surfe på bølgen som kommer i stedet for å forsøke å stoppe den – det er en bedre strategi å forsøke å forstå og beherske naturen enn å prøve å motvirke den.
Om vi deler opp problemet i små biter og legger opp til mange små leveranser kan vi oppnå flere ting. Vi vil da kunne “smake på puddingen” og validere resultatet om igjen og om igjen og på den måten absorbere risikoen.
Løpende validering av antagelser for å unngå å akkumulere opp risiko
Figuren viser hvordan vi ved å levere resultatet i små inkrementer vil kunne “spise opp risikoen” underveis. (Enkelte ganger -hvis nyhetsgraden er stor – vil det første trinnet måtte ta noe lengre tid enn de andre. Dette trinnet kan også romme forretningsutvikling). Dessuten vil vi i dette regimet ha mye bedre betingelser for innovasjon. Her er det unødvendig å ha et ferdig omfang på forhånd, siden vi hele tiden får feedback og kan la detaljene bli til underveis. Vi kommer ikke på etterskudd for det er ikke inngått forpliktende, langsiktige løfter. Nå ser vi at det er rekkefølgen vi løser problemet i som blir avgjørende. Vi spør oss hele tiden “hva er det neste vi skal lage som vil gi oss maksimal validering av antagelser?“. Dette regimet er altså basert på en løpende finansiering. Vi validerer resultatet og gjør kost/nytte vurderinger hele tiden. Gevinstrealiseringen er innbakt i prosessen. Vi manøvrerer her i usikkert farvann i stedet for å låse oss til en fast kurs – og håpe det beste.
På denne måten ser vi at vi fint kan “slippe unna” med langt mindre forarbeide, siden vi insisterer på å ikke ta på oss store økonomiske forpliktelser. Om sponsorer og eiere gjennom feedbacken finner ut at det er riktig å avbryte (enten fullstendig eller for å justere kursen), så må de ha mulighet til det. Kunsten å stoppe i tide er avgjørende!
In: inkrementell utvikling, kompleksitet, ledelse, Planlegging, Samfunn · Tagged with: innovasjon, ledelse, prosjektstyring, Smidig, Styring
Er Scrum kompleks?
Når jeg holder kurs åpner jeg ofte med å si at Scrum er et enkelt rammeverk som tilbyr “minst mulig struktur” for å organisere kunnskapsarbeid på en effektiv måte. Det er noen få regler, 5 verdier, 5 møter, 3 roller og 3 artefakter. Det baserer seg på agilemanifesto.org, støtter seg på Lean-tankegangen og baserer seg på empirisk prosesskontroll i iterasjoner på 1-4 uker.
Jeg sier også at det lønner seg å “ta hele kuren” og implementere Scrum etter boka og vinne erfaring, deretter å eksperimentere med egen prosess slik at arbeidsformen gradvis blir mer og mer optimal. Om man klarer å gjennomføre Sprint planlegging på 30 minutter så er det selvsagt greit (selv om angitt timeboks er 2 timer). Om man klarer seg med en halv time i uka til Produktkøraffinering er det også i orden. Scrum pålegger deg selvsagt ikke “overhead”, for i bunn og grunn er dette en prosessforbedringsprosess. Hvis noe ikke gir verdi er det “waste” og skal bekjempes. Jeg støtter meg her på Core Scrum fra Scrumalliance, men Scrumguiden fra Scrum.org forteller det samme.
(For ordens skyld: Det er ikke noe i veien for å levere mange ganger i løpet av en iterasjon, eller å kombinere Scrum med Lean Startup sin “Build-Measure-Learn” eller DevOps)
Men alt er selvsagt relativt, og vi som steller med Scrum er vant til at de som sverger til Kanban forteller at Scrum er rigorøs og kompleks og medfører overhead. I BEKK sin ferske “teknologiradar” kan vi for eksempel se at de anbefaler å avstå fra Scrum, men heller vurdere gammeldags prosjektstyring..
Jeg har hørt Kanban-faderen selv, David J Anderson, presentere Kanban ved flere anledninger, og det slår meg at han ikke evner å forklare Kanban uten å sammenligne det med Scrum (der alt ved Scrum får negativt fortegn). Kanban er opplagt enklere og mindre rigorøst enn Scrum, siden det ikke definerer hverken roller eller aktiviteter. Samtidig er Scrum langt enklere enn Rational Unified Process og f.eks ITIL. Eller Prince2 for den saks skyld. Figuren under (laget av Henrik Kniberg) forteller en del.
Personlig synes jeg Kanban er genialt enkel og når jeg gir råd til organisasjoner sier jeg alltid at det viktigste er at de forstår sin egen kontekst, sine egne forretningsmålsetninger og setter seg godt inn i konseptet Agile (hvis dette passer med målene da – hvilket det gjør for de fleste moderne selskaper). Deretter kan de velge rammeverk. Jeg anbefaler å starte med Scrum for det gir konkret støtte til snuoperasjonen. Det tydeliggjør en nødvendig endring, og gir “umodne” organisasjoner en trygghet. For eldre vannfallsorganisasjoner gir Scrum et visuelt bilde og på samme måte et tydelig målbilde. Så kan man etter hvert vurdere å bevege seg i retning av Kanban. Men om de foretrekker å gå rett på Kanban er det også greit. Da starter vi alltid med en verdistrømsanalyse, finner flaskehalser og køer, forenkler og så visualiserer vi ende-til-ende prosessen i et Kanban board.
Spotify er som mange lesere vil vite en svært smidig organisasjon som styres etter noen enkle prinsipper og verdier. De har 80-90 team som lager dette produktet, og alle teamene har frihet til å velge prosessmodell. Interessant nok har dette ført til at de har en salig blanding av Scrum, Kanban og “hjemmebrygg”. Noen team foretrekker de ganske stramme rammene og iterasjonene som Scrum gir, andre vil ha mer frihet og flyten til Kanban. Det samme ser vi i de fleste rutinerte, “modne” smidigselskapene.
BEKK forteller i radaren sin at Scrum er for kompleks for de uerfarne og at “det blir mye nytt å lære seg på en gang”. Seriøst? Jeg har jobbet på heltid med Scrum i over 10 år og sett utallige organisasjoner fomle og feile med Scrum i starten –men det har aldri vært på grunn av at rammeverket er vanskelig å forstå. Selv i norske, uerfarne småfirmaer finner vi faktisk veldig smarte folk. Det de fleste sliter med er heller knyttet til endring av tankesett (mindset), firmakultur og at kunden eller ledelsen fremdeles henger igjen i gamle rutiner. Og Agile er langt vanskeligere å forstå godt nok enn det Scrum er.
Jeg møter fra tid til annen svært erfarne, dyktige software-utviklere som fnyser av Scrum. De nyter stor respekt i egen organisasjon og har klart seg utmerket i tiår uten disse seremoniene og strenge iterasjonene. De ser ikke verdien av tett, tverrfaglig teamarbeid og føler ubehag av å stå og snakke i detalj om hva de skal gjøre og hva de har av problemer hver dag. Jeg kan skjønne dette. Jeg kan skjønne at disse foretrekker Kanban, som (i hvert fall tilsynelatende) gir rom for å fortsette som før.
Argumentet om at Scrum medfører overhead er underlig. Det er alltid rom for eksperimentering, optimalisering og å utfordre Status Quo så lenge man gjør dette som team og i lys av en strukturert prosessforbedringsprosess (Scrum retrospective). “Medfører” egentlig et rammeverk noe som helst? Må man ikke uansett selv ta ansvaret for egen prosess?
In: Scrum · Tagged with: prosessforbedring, Scrum
Motiverte medarbeidere – 7 tips
Dette er en oppfølging av forrige post kalt Den indre motivasjonen.
Mary Poppendieck fortalte en gang en historie som jeg ofte bruker når jeg holder kurs. Den går omtrent slik:
En filosof gikk og vandret i fjellene nord i Italia og kom over tre menn som stod og hugget sten. Han gikk bort til den ene og sa “hei hva holder du på med?” Svaret kom kort og litt bryskt “er du blind, ser du ikke at jeg hugger stein?” OK, filosofen skynder seg bort til neste mann og stiller det samme spørsmålet “hva holder du på med?” Svaret denne gangen var noe helt annet; Han sa “jeg har en familie nede i dalen som trenger mat, så jeg står her og tjener til livets opphold”. Interessant, tenkte filosofen – et helt annet perspektiv på akkurat samme jobben! Så går han til siste mann og spør igjen “hva holder du på med?” Svaret denne gangen var episk: “jeg bygger en katedral” sa mannen.
Hvem av disse tre tror dere vil lete etter de beste stenene? Hvem vil legge sjela si i at arbeidet blir utført så godt som mulig? Svaret er innlysende – katedralbyggeren tenker hele tiden på sluttresultatet og har et betydelig eierskap til dette. Han vil gjerne yte det lille ekstra for å ende opp med en finest mulig katedral!
Alle jeg snakker med om systemutvikling er opptatt av kvalitet, særlig ledere. Men hvordan kan vi øke sannsynligheten for at kvaliteten blir ivaretatt tvers igjennom? Jo selvsagt, vi trenger katedralbyggere! Men hvordan får vi tak i disse? Kan vi gjøre steinhuggere om til katedralbyggere?
Innen kunnskapsarbeid – som for eksempel systemutvikling – er det spesielt viktig med katedralbyggere. Årsaken til dette ligger i kompleksiteten til arbeidet, ønsket om innovasjon og ikke minst at kvaliteten (på programkoden) er svært vanskelig å måle. Så, når vi klarer ikke å “spesifisere” høy kvalitet, blir vi avhengige av at de som gjør jobbe vil levere høy kvalitet.
Høy kvalitet og god håndtverksmessig standard er altså helt avgjørende for sluttresultatet, særlig på lang sikt. Katedralbyggeren vil insistere på å ta tiden som trengs for å bygge inn kontinuerlig integrasjon, automatiserte enhetstester og regresjon. Han vil gjøre kodereview eller jobbe i par. Og han vil re-faktorisere designet slik at koden til enhver tid er godt strukturert og lett for andre å sette seg inn i. Katedralbyggeren vil jobbe tett sammen med de ulike brukerne av systemet og forvisse seg om at vi har forstått deres egentlige behov. Katedralbyggeren vil ha en klar visjon og det nødvendige overblikket som skal til for å ta gode avgjørelser underveis.
Man kan si at katedralbyggeren er opptatt av å tilfredsstille brukerens behov, mens steinhuggeren er opptatt av å tilfredsstille kravstillerens krav (med så liten innsats som mulig).
Vi har altså slått fast at det er den indre motivasjonen som er verdifull, og at forsøk på stimuli i form av insentiver (ytre motivasjon) kan virke mot sin hensikt. Og vi har slått fast at motivasjon er knyttet til autonomitet, mestring og hensikt. Her kommer noen tips til hva vi kan gjøre.
7 råd for å skape katedralbyggere
Råd 1: De som skal gjøre jobben er med på å utforme visjonen. En god visjon er formulert på en lettfattelig, kortfattet måte og inneholder den viktigste informasjonen teamet trenger for å ta de nødvendige beslutningene underveis. Utviklingsteamet må med andre ord på plass veldig tidlig i et utviklingsløp.
Råd 2: Tett, løpende samarbeide med brukerne. Identifiser ekte brukere som er representative og som har et brennende ønske om å få løst noen problemer, så godt og raskt som mulig. Definer noen møteplasser der brukerne og de som lager løsningen kan være kreative sammen. Dette fører til et uvurdelig eierskap.
Råd 3: Husk bekreftelse! Vi trenger jevnlig å få bekreftet om vi er på rett vei – eller ikke. Det er veldig motiverende å få se smilet i ansiktet til en fornøyd sluttbruker! Samtidig må vi også få høre den brutale sannheten når vi har bommet. Kan vi få rask og målbar feedback på jobben vi har gjort, vil alle involverte få et dypt eierskap.
Råd 4: Legg til rette for øving! For å bli virkelig gode i noe trenger vi å repetere – noen ganger til det kjedsommelige. Om vi klarer å splitte opp arbeidet på en slik måte at vi stadig får analyserbare delresultater, kan vi gradvis perfeksjonere arbeidsprosessene, metodene og verktøyene vi bruker. Dette at hele teamet ser en kontinuerlig forbedring gir en uvurdelig mestingsfølelse – og motivasjon.
Råd 5: Tverrfaglighet. Kunnskapsarbeid er teamarbeid, og disse teamene vil alltid bestå av folk med ulik faglig spesialisering. For å oppnå sterkt eierskap hos flest mulig må vi dyrke det tverrfaglige teamarbeidet, fremfor å fokusere så mye på roller. Hvis vi lar de faglige siloene få leve vil vi ikke oppnå det kollektive eierskapet. Konsekvensen av dette er at de som bemanner teamene oftere må ut av både sitt faglige spesialfelt og sin komfortsone! Mye av den spennende innovasjonen skjer i skjæringspunktet mellom fagfelt.
Råd 6: Selvorganisering. La teamene få størst mulig autonomitet. Gi dem tillit og herredømme over deres egne arbeidsprosesser, metoder og verktøy! Behandle folk som voksne, positive, ansvarlige mennesker – og du vil få – voksne, positive, ansvarlige mennesker…
Råd 7: Slakk. Det ultimate beviset på tillit man kan gi et selvorganisert team er å unngå å presse på for å få framdrift. Når teamet opplever i praksis at de har tid til å ta vare på de gode ideene og til å perfeksjonere arbeidsprosessene sine kan vi være temmelig sikre på at den indre motivasjonen blir rotfestet.
Folk er forskjellige og det finnes sikkert mennesker som er “naturlige katedralbyggere” og det finnes nok også “notoriske steinhuggere”. Kunnskapsorganisasjoner trenger en god andel katedralbyggere, men kan også leve med at enkelte på et team er steinhuggere.
Tiltak
Det peker seg ut en del helt konkrete tiltak en ledelse kan begyne å jobbe med for å skape en høymotivert organisasjon. Dette må gjøres gradvis (kjør en “pilot” på et spesielt område) og vil nødvendigvis ta tid. Her kommer noen forslag til konkrete ting å starte med:
Unngå overleveringer – bygg ned siloene og “prosessorienteringen”. Lag i stedet en struktur der nederste nivået er robuste, permanente tverrfaglige team.
Unngå for mye spesialisering – dyrk teamarbeidet og utvikle medarbeidere som er teamorienterte og både spesialister og generalister.
Unngå detaljstyring – skrot de detaljerte prosedyrene, stillingsinstruksene og KPIene. Gi i stedet teamene den støtten de trenger for å komme i gang med selvorganisering.
Unngå insentiver – gi i stedet medarbeiderne ansvar og stimuler til eierskap. Sørg for at alle har en god lønn, slik at dette temaet får minst mulig oppmerksomhet.
In: ansvar, Endringsledelse, Lean, ledelse · Tagged with: Ansvarliggjøring, endringsledelse, ledelse, organisasjon, Smidig
Den indre motivasjonen
Vi som jobber med smidig systemutvikling og prosessforbedring tar ofte til orde for at folks indre motivasjon er uhyre verdifull. Både fordi det gir bedre arbeidsplasser (selvfølgelig), men også fordi sluttresultatet antageligvis kan bli vesentlig bedre på den måten.Når Dan Pink i 2011 publiserte Drive – The Surprising Truth About What Motivates Us falt brikkene på plass for meg. Jeg har vært der selv og jeg har sett det med egne øyne – folk som virkelig bryr seg leverer vesentlig bedre arbeid enn de som er mest opptatt av å heve lønn. Og hva er det som får folk til å virkelig bry seg? Autonomy, Mastery and Purpose er Dan Pinks kortversjon – og som det er lett å slutte seg til. Folk som får involvere seg i sluttresultatet og får herredømme over sine egne arbeidsprosesser vil få et eierskap og utløse den verdifulle, indre motivasjonen.
Her hjemme har jeg lenge fulgt BI-professor Bård Kuvaas som lenge har forsket på motivasjon og belønning. Han bekrefter på mange måter alt det Dan Pink sier – incentiver (ytre motivasjon) kan fortrenge den indre motivasjonen og virker således imot sin hensikt(!) Dette er særlig fremtredende ved kunnskapsintensivt arbeid – som jo systemutvikling i høyeste grad representerer. Jeg anbefaler alle å bruke en time på dette utmerkede foredraget Kuvaas nylig holdt om temaet:
Her blir disse fenomenene ytterligere styrket gjennom forskning og en nylig publisert metastudie med totalt over 200.000 bidragsytere.
Jeg mener systemet vi jobber i vil kunne stimulere til – eller komme i veien for – den indre motivasjonen. Ikke overraskende ligger de smidige metodene veldig godt an her. Dette gir jo nettopp en situasjon der de som gjør jobben opplever autonomitet, med eierskap til visjonen, selvstyrt teamarbeid og tett, direkte kontakt med kunden. På samme måten ser vi at tradisjonelle systemer (som for eksempel prosjektstyring) fører til fremmedgjøring, lang avstand til beslutningene, liten grad av tillit og ansvarsfølelse.
Så hva gjør ledere i privat og offentlig sektor med denne svært overbevisende forskningen? Alle ledere i kunnskapsorganisasjoner bør spørre seg: Hvordan utløser vi denne verdifulle, indre motivasjonen?
In: ansvar, Forskning, ledelse, Samfunn, selvorganisering · Tagged with: Ansvarliggjøring, forskning, ledelse, organisasjon
Om forskning på IT-prosjekter
Dette handler om kunsten å lære av erfaring og er en kommentar til Magne Jørgensens foredrag på Software 2015 kalt “Hva skal til for å lykkes i IT-prosjekter? Hvor mye og hvordan kan man lære av andres suksesser og fiaskoer?”Akkurat disse spørsmålene har opptatt meg nærmest på heltid siden tidlig 90-tall når jeg jobbet i Siemens Telecom på Linderud i Oslo. Jeg var da så heldig å få være med på ulike forskningsprosjekter, alle med variasjoner over disse spørsmålene som hovedtema. Jeg kan nevne SISU, SPIQ, SPIKE, PROFIT og Evisoft som ble kjørt på rekke og rad i en 20-års periode fra tidlig 90-tall, med finansiering av Norsk Forskningsråd og med forskere fra Sintef, NTNU, UiO og etter hvert Simula. Magne var selv med i noen av disse, husker jeg. Vi (i Siemens) var også med i PERFECT-prosjektet, et EU-finansiert ESPRIT-prosjekt over 3 år, der vi som industripartner hadde støtte fra konsulenter (Q-Labs i Sverige) og forskere fra Sintef, NTNU, Fraunhofer, Universitetet i Kaiserslautern og Universitetet i Grenoble. Våre utviktingsprosesser og vår evne til å lære av erfaring fikk da virkelig kjørt seg. Resultatet fra prosjektet ble kalt PERFECT Improvement Approach (PIA) og var basert på Quality Improvement Paradigm (QIP) og Goal Question Metrics (GQM). Alt lå til rette for at dette skulle bli virkelig bra. God finansiering, flere industripartnere og ikke minst anerkjente forskere som professor Dieter Rombach fra Fraunhofer på laget. Vi støtte oss også tungt på Professor Vic Basili ved Universitetet i Maryland som utviklet GQM og QIP. Og forskning gjort ved NASA av Frank MacGarry. Til tross for alt dette ble resultatet en stor flopp! Hvorfor virker ikke denne solide, vitenskapelig baserte prosessforbedringsmodellen? Hvorfor klarer vi ikke å lære av erfaring på denne måten? Jeg stilte meg dette spørsmålet om og om igjen på slutten av 90-tallet og utover i dette årtusenet og kunne bare konkludere med en ting: Prosjektene var for langvarige og store! Jeg tror det er tre helt fundamentale problemer med dette:
1. Det blir kjørt få prosjekter innenfor en kontekst, så vi får svært få datapunkter å sammenligne.
2. Store prosjekter er svært krevende å analysere, siden det fort vil være alt for mange variable faktorer – som ikke er uavhengige
3. Store prosjekter vil bruke mye kalendertid hvilket lett fører til at det neste prosjektet må forholde seg til en annerledes virkelighet og ha andre rammebetingelser – prosjektene blir ikke sammenlignbare.
Om 3: en metode som fungerte godt i ett prosjekt vil ikke nødvendigvis fungere godt i det neste for her vil sannsynligvis en rekke faktorer (som for eksempel personell) være forskjellige. Jeg husker godt dette fenomenet ble belyst i den smått kjetterske artikkelen The Importance of NOT Learning from Experience som Magne skrev sammen med Dag Sjøberg i år 2000. Bare overskriften fikk brikker til å falle på plass hos meg (jeg kan legge til at jeg ikke er enig i alt som står i artikkelen, men det spiller ingen rolle her). Jeg husker fra PERFECT-prosjektet at vi i Siemens ble trukket fram som et empirisk eksempel på at PIA fungerte. Vi kjørte da tre ganske like prosjekter rett etter hverandre. Alle tre var ganske korte med varighet på 6-7 måneder og prosjekt nummer 3 var særdeles vellykket. Vi som jobbet med prosessforbedring innkasserte gjerne denne seieren da, men med en litt flau smak i munnen. Realitetene var jo at disse tre prosjektene hadde vært nesten like! Og de hadde omtrent samme bemanning. Vi hadde systematisk samlet data og forbedret prosessene våre, men vi må ikke glemme at den erfaringen som satt i hodene på de som hadde vært med på alle tre prosjektene kanskje talte like mye. Eller kanskje mer? Etter dette forandret Siemens strategi (nye tider, ny teknologi osv) og vi oppdaget da at all erfaringslæring, innsamlede data og definerte prosessmodeller var fullstendig ubrukelige. Det ville rett og slett vært skadelig å benytte seg av dette i de neste prosjektene…
I foredraget problematiserer Magne Jørgensen rundt vår evne til å analysere og trekke slutninger. Hvor stor kausalitet har egentlig problemet vi analyserer? Hvor uhildet er våre konklusjoner? Er vi i stand til å være objektive, eller vil vi søke etter å få det svaret vi trodde på forhånd – eller det vi ønsker oss? Kan vi forvente å lære noe særlig når det opprettes “havarikommisjon” i forb med et stort, feilslått prosjekt? Dette er fornøyelig lesning og det er alltid godt å få bekreftet det vi allerede vet av en professor og av forskning. Men dette foredraget rommer egentlig ikke noe nytt. Dessverre.
Løsningen på læringsproblemet
Magne Jørgensen presenterer HVA KAN VI GJØRE FOR Å BLI BEDRE TIL Å LÆRE AV ERFARING? og kommer med en del gode, men ganske selvfølgelige tips. Men han nevner ikke noe om muligheten til å stykke opp problemet i små, sammenlignbare enheter som i for eksempel Scrum. Jeg “arvet” Masterkurset “Produkt- og Prosessforbedring” på IFI av Magne Jørgensen på tidlig 2000-tall, og jeg hadde kurset i 5 år. Jeg bakte tidlig inn det å kjøre mange små, fremfor få store prosjekter i kurset, men rundt år 2004 fikk jeg en slags oppvåkning da jeg forstod rekkevidden av Scrum og andre smidige metoder. Scrum er jo en prosessforbedringsprosess! Scrum er skreddersydd for å lære av erfaring! Men for at det skal fungere godt, må noen brikker være på plass: Teamet må ha på plass kontinuerlig integrasjon, og faktisk fullføre et produktinkrement i hver iterasjon. Og teamet må ansvarliggjøres slik at de selv kan iverksette tiltak når de lærer av erfaring. Erfaringer kan kun trekkes på bakgrunn av sluttresultatet.
Jeg blir altså stadig forundret over at forskere og konsulenter overser denne fantastiske muligheten til å optimalisere læringen. I figuren kan vi tenke oss at det samme 2-års prosjektet med de samme målsetningene kjøres på tre ulike måter. Først et “big-bang-prosjekt” som altså får én læringsmulighet, der vi kjører en prosjektevaluering (som alle gode prosjektledere gjør). Deretter det samme prosjektet med 3 delleveranser og 3 evalueringer. Her vil vi høyst sannsynlig ha ganske like rammebetingelser og kanskje vi er så heldige å ha de samme menneskene i prosjektet (mye tyder på at menneskeaspektet er det aller mest avgjørende). Det er lett å se at vi her får langt bedre betingelser for å forbedre oss underveis og å kunne trekke noen konklusjoner. I smidig vil betingelsene for læring være dramatisk forbedret. Her ser vi at hver iterasjon (I) (tar typisk 2-3 uker) resulterer i et produktinkrement som analyseres og vi får en direkte læringseffekt. Ett aspekt her er at de involverte får rask feedback gjør at læringen kan bli langt mer effektiv. Vi har det vi gjorde friskt i minne og kommer lett i en svært effektiv læringsmodus. Inkrementene er også svært like hverandre, hvilket gjør at vi nå kan eksperimentere med metoder og verktøy. Og vi får øvd oss. Skal vi virkelig bli gode i noe, må vi øve! En viktig betingelse for at smidig skal fungere godt er også at teamet som gjør jobben ikke arbeider mot en stor avslutningsmilepæl. I slike tilfeller vil investeringer i bedre metoder og verktøy kunne virke litt fånyttes, siden prosjektet blir oppløst ved avslutningen. En bedre løsning er å satse på mer permanente team som jobber mot klare målsetninger, men som da får lov til å forbli intakte og kan selv høste fruktene av egen prosessforbedring.
Scrum er laget for å øke kausaliteten dramatisk. Gjennom å dele opp arbeidet i inkrementer, tiden i løpende tids-bokser (iterasjoner) og organisasjonen i små, tverrfaglige team får vi en helt annen gjennomsiktighet. Årsak-virkning-sammenhengene kommer til syne på en helt annen måte.
Jeg trodde det var opplest og vedtatt at store prosjekter er for komplekse til å kunne trekke bastante konklusjoner om hva som gikk galt. Til det er det alt for mange avhengige faktorer som spiller inn; Verden er ikke lineær, den er tvert om dynamisk og kompleks. Jeg støtter meg til Cynefin-modellen til Dave Snowden når jeg diskuterer kausalitet i lys av kompleksitet. Jeg har skrevet en liten innføring her. Han deler inn problemer i 4 domener: Opplagte, Kompliserte, Komplekse og Kaotiske. Det Snowden interessant nok sier om Scrum er at inne i terasjonen er vi sannsynligvis i det kompliserte domenet, hvilket innebærer at vi kan finne årsak-virkning-sammenhenger. I et mer langsiktig perspektiv er vi i det Komplekse området, hvor vi kun i ettertid kan analysere resultatet og finne ut om vi er på rett vei.
Det var mange foredrag direkte og indirekte om smidig på Software2015. Synes nå det er på høy tid at også forskerne ser med større interesse på dette fenomenet, særlig når det er snakk om å lære av erfaring. Det er mulig jeg er for utålmodig, men forskerkverna kverner svært langsomt…
PS: Som deltager på Software2015 fikk jeg en dropbox-link til alle foredragene. Jeg er usikker på om jeg uten videre kan dele foredraget til Magne Jørgensen på denne bloggen.
Du kan se presentasjonen til Magne Jørgensen her
In: Forskning, kompleksitet, Scrum · Tagged with: forskning, ledelse, Scrum, Smidig, systems thinking
Blinde og seende systemer
Kanskje litt off-topic, men den våkne leser vil se at det er spor av både Lean og Smidig her. Dette er fra virkeligheten.
Vi får en stadig økende andel eldre i Norge, og samfunnet har forpliktet seg til å ta seg av disse når de av ulike årsaker ikke klarer seg helt på egen hånd. Det er kommuner og bydeler som har dette ansvaret, og det er en trend at man ønsker at de eldre bor lengst mulig hjemme, framfor å tilby dem plass på eldre- eller sykehjem.
—
Elsa er 83 år og nylig blitt enke. Hun har diverse plager og begynner å bli dement, men klarer seg brukbart i hverdagen så lenge hun slipper å bevege seg ut av leiligheten som hun trives godt i.
Bydelen setter i verk følgende tiltak:
- Praktisk bistand
- innkjøp av mat og annet én gang i uka
- husvask annenhver uke
- Hjemmesykepleie med besøk tre ganger daglig for å sørge for medisinering og matinntak.
Etter noen uker merker pårørende som kommer på besøk (ca én gang per uke) at ikke alt er som det skal. Det er spesielt én essensiell ting som mangler, nemlig kaffe. Hun drikker mange kopper per dag. Dessuten oppdager pårørende at det begynner å lukte vondt i kjøleskapet, og ganske riktig der finner de mat som er i ferd med å råtne og mugne. I det hele tatt er kjøleskapet veldig fullt, urent og uappetittelig.
Hva er det egentlig som skjer her?
Et blindt system
For det første må vi tenke over at dette gamle mennesket er dement og er dessuten kresen i matveien og har dårlig matlyst. Alt dette er vanlig. En annen ting å være klar over er at mange eldre mennesker helst ikke vil “være til bry”. Så på direkte spørsmål om hva hun mangler av matvarer vil ofte svaret være “jeg tror ikke jeg trenger noe, jeg”.
Så hva gjør hjemmehjelperen da? Improviserer, selvsagt. Kjøper inn noe enkel middagsmat og pålegg i håp om at det treffer noenlunde godt. Dette kan fungert fint over tid hvis en viktig faktor er til stede: nemlig at den samme hjemmehjelperen kommer tilbake neste uke. Hun ville da med egne øyne kunne se hva som var spist og hva som ikke ble spist. Hun ville gradvis i løpet av noen uker funnet et mønster i forbruket og kunne tilpasset innkjøpene deretter. Hun ville også sett at kaffeforbruket var stort og forstått at her må det storinnkjøp til.
Men denne forutsetningen er ikke til stede. Hjemmehjelperne rullerer – de befinner seg i en ressurspool og vil kunne få ulike ruter og sett med brukere fra uke til uke. Så det kan gå mange uker til den samme personen kommer tilbake. Hun vil da ikke få noen informasjon om forbruket ved å se inn i kjøleskapet, og vil da sannsynligvis fortsette å kjøpe inn matvarer som bare ble liggende til det blir kastet.
Hva så med hjemmesykepleierne som skal sørge for at hun får i seg næring? De har ingen enkel jobb her. De er jo prisgitt det de finner i kjøleskapet. De vil stadig oppleve at Elsa ikke har lyst på den maten de finner tilgjengelig. Og de finner bedervet mat i kjøleskapet som bare må kastes. Men heller ikke hjemmesykepleierne finner noe klart mønster her, for de rullerer også. Det kan gå mange dager mellom hver gang en pleier besøker henne.
Elsa stakkar blir tynnere og tynnere, selv om hun bruker mye penger på mat. Og hun blir dehydrert.
Det er tydelig at pleierne og hjelperne i dette systemet ikke er i stand til å finne mønstre (ingen kritikk av pleierne og hjelperne). De ser ikke konsekvensen av sine egne handlinger og besutninger. De opererer uten feedback og læring. De famler rett og slett blinde.
Å lære seg å se
Blinde systemer kan gjøres seende. Det er faktisk ganske enkelt å foreslå tiltak for å bøte på problemet.
Mulig tiltak 1:
Det mest åpenbare er å pålegge hjemmesykepleien og hjemmehjelperne å snakke sammen. Da vil jo de som sørger for at hun spiser lett kunne bygge opp en standard handleliste og de kunne be om påfyll av varer ved behov. Men dette er vanskelig i praksis siden hjemmesykepleien og hjemmehjelperne tilhører forskjellige enheter. Og det vil uansett ikke gå av seg selv, siden det det er så mange forskjellige personer involvert hele tiden. Så her måtte det bygges opp et system som ville hatt en kostnad. Slike kostnader må tas fra samme hovedbudsjett og således gått utover tilbudet.
Mulig tiltak 2:
Omorganisere, slik at det er fast personell som kommer og yter tjenester til sine faste brukere. Da får disse en kontinuitet og vil selv kunne erfare hvilke særegne behov hver av sine brukere har.
Sykepleierne ville lære seg brukerne mye bedre og kjenne og ville lettere kunne følge med på vektutvikling og andre helseparametere og ville lettere kunne satt inn tiltak om det var fare for underernæring.
Hjemmehjelperne ville fra uke til uke bygd opp erfaring for hva slags varer som ble brukt opp og hva som ikke ble konsumert.
Vi har her et “seende system” som vil kunne bli langt mer treffsikkert i forhold til brukernes behov. Uten ekstra kostnad.
Mulig tiltak 3:
Det mest radikale og mest treffsikre tiltaket er (selvsagt) at de som sørger for mat også handler. De har jo første hånds kunnskap om behovet både på kort og lang sikt. Om vi et øyeblikk legger bort tanker om profesjon og rolle, forstår vi lett at dette er den mest treffsikre løsningen; Et tverrfaglig system.
En bieffekt av dette vil være at handlingen vil kunne ta mindre tid. Husk at de som har handling som eneste jobb, først må besøke Elsa og finne ut hva de skal handle og få med seg kontanter fra Elsas pung (det er slik det fungerer). Deretter reise ut for å handle. Om de som har første hånds kunnskap om behovet også handlet, ville de lett kunne svippe innom butikken på veien til henne og dermed slå to fluer i ett smekk! På denne måten kunne handlingen vært mer behovsstyrt både ut fra brukerens behov og hjelperens kapasitet. Dette er flyteffektivt og ikke optimalisert for ressurseffektivisering.
Hvordan få teamet til å ha stand-up møter?
Når jeg holder kurs og ellers når jeg snakker med folk som strever med å innføre smidig, får jeg ofte dette spørsmålet:
“Noen av teammedlemmene synes det er noe pes med disse møtene, og de vil gjerne slippe. Hvis de møter opp, kommer de for sent. Hvordan kan jeg få dem til å møte opp på de daglige møtene?”
Det som slår meg er at dette spørsmålet er veldig tilsvarende et annet typisk spørsmål:
“Hvordan får jeg teamet til å redusere WIP-grensene sine?”
Selv om dette er to ganske ulike saker, har de noe til felles. De representerer noe som utviklere synes kommer i veien for det daglige arbeidet. Daglige møter fører til irriterende avbrytelser i utviklingsarbeidet og lave Work-In-Progress (WIP)-grenser fører til at flyten av arbeidet i det daglige stopper opp.
Hva man skal gjøre i disse tilfellene er ikke opplagt. Vi har lært oss at det er viktig med daglige møter og vi har lært oss at WIP bør være så lav som mulig for å øke gjennomstrømningen av arbeid.
La oss først problematisere litt rundt spørsmålet – hva er det som får noen til å gjennomføre disse (uønskede) tingene? For det er jo utvilsomt mange som faktisk gjør dette. Jeg tror du finner dem i tre kategorier:
1. De som gjør det fordi det er bestemt.
2. De som gjør det fordi de har en vag idé om at det sikkert er lurt
3. De som gjør det fordi de ser at det hjelper
Kategori 1 favner jo de organisasjonene som er prosedyredrevne og som har en sterk “complience-kultur”. Vi finner dette mange steder, og enkelte bransjer synes å peke seg ut her. Det kan også være at personlighet spiller inn. Det finnes opplagt folk som “bare følger etter” uten å tenke så mye over hvorfor – og det finnes rebeller som helt naturlig vil forsøke å unngå begrendense regler. Kategori 2 omfatter de som har en klar bevissthet på at det vi har gjort til nå suger – ergo må dette være bedre. De gjør det ganske helhjertet og vil stadig være på utkikk etter positive effekter. Kategori 3 er de som virkelig har satt seg inn i hvorfor. De ser det store bildet – og de ser aktivt etter effekten av det de gjør. Dette er katedralbyggerne (jeg har skrevet litt om dette begrepet på LinkedIn Pulse) som hele tiden er opptatt av sluttresultatet og “det store bildet”. Så i dette perspektivet kan vi drøfte hvordan vi skal løse disse problemene. For det er selvsagt problematisk at et team tydeligvis ikke er enige om hvordan de skal jobbe.
Jeg kommer nå rett fra 4 dager med fordypning i ulike aspekter av smidig. Først Agile Coach Camp Norway, deretter Agile Culture Hacking med Olaf Lewitz. Her har det vært rikelig anledning til refleksjon og fordypning i slike spørsmål. Hovedsaken alle disse dagene var finne ut mer om hvordan vi som er entusiastiske “smidige endringsagenter” kan gi verden et lite dytt i riktig retning.
Om kulturen tillater det kan vi “pålegge” folk å stille på daglige møter med fast agenda samme tid, samme sted hver dag. Men dette gir selvsagt ikke den effekten vi er ute etter. Det vi får er en syltynn, overflatisk implementasjon uten noe engasjement. Dette er compliance, ikke en bevisst handling. Dette er “command and control” og ikke Agile. Dette er akkurat det vi må komme oss unna. Skal vi får en implementasjon av smidige prinsipper som virkelig gir effekt, må vi innse at det ikke finnes noe kjapp, enkel løsning. De kjappe løsningene fordrer lydighet og ikke refleksjon. Hva er det vi ønsker i kunnskapsbedrifer egentlig? Lydige tinnsoldater, eller reflekterte katedralbyggere?
For å få til varing endring og forbedring må vi tåle å bruke tid på det. Vi må innse at folk må få være med selv og sette mål, utforske alternativer og gjøre valg. Vi som er endringsagenter må støtte i dette arbeidet. Vi kan opplyse, veilede, fasilitere og coache, men ikke insistere, pålegge eller presse på. 
Så, om vi ser at teamet vi jobber med har problemer, så vet vi altså at den kjappe løsningen der vi forsøker å overtale folk til å følge regler ikke vil fungere godt. I stedet må vi bruke tid på å gi dem den nødvendige innsikten i det problemet vi står overfor (Increase awareness). Deretter må vi snakke om målsetninger (Identify goals). Hva er det egentlig som er viktig å oppnå? Så må vi se på hvilke alternativer som ser best ut i forhold til målet (Explore options). Deretter må teamet selv få velge (Invite to choose). Og bare så det er sagt – de må bli enige om en måte – hvis de skal jobbe som team. Visse rammer må være felles for at et team skal fungere. Og så må vi ikke glemme å evaluere (Reflect on outcome). Fungerer det etter hensikten? Uansett kan vi ta en ny runde og sette nye mål og utforske flere mulige alternativer og forsøke noe annet.
I dette eksempelet ser vi hva vi i praksis kan gjør om teamet ikke får utbytte av daglige Scrum-møter, eller om de ikke møter opp. Først må vi altså sørge for at de forstår hva man kan oppnå med Scrum som rammeverk og hvilken rolle disse møtene spiller i dette rammeverket. Når alle da har dette felles fundamentet på plass kan vi fasilitere en samtale rundt samarbeid, koordinering og å finne hindringer. Slike ting som de daglige møtene er ment å hjelpe til med. Deretter kan vi få en reell diskusjon rundt hvilke alternativer som finnes. Kanskje de har ideer til bedre måter enn standard Scrum 15 minutters stående møte? I så fall er det jo bare å prøve i en sprint eller to. En coach eller Scrum Master må da være våken og notere seg hvordan dette forløper underveis i sprinten slik at man kan gjøre en ny vurdering senere ( i retrospective).
På samme måten kan vi gjøre med WIP-grensene. Vi kommer aldri til å få noe posistivt engasjement rundt WIP-begrensninger om ikke teamet forstår hvorfor, får være med å å styre grensene eller ser med egne øyne hvordan de blir brukt til å øke gjennomflyten og gjøre systemet med effektivt.
Jeg kommer stadig tilbake til dette:
Om du behandler folk som voksne, positive mennesker vil du få – voksne, positive medarbeidere. Voksne mennesker trenger å gjøres myndige og selv eie valgene som gjøres.
In: ansvar, Coaching, Endringsledelse, ledelse, Scrum, selvorganisering, Uncategorized · Tagged with: Ansvarliggjøring, Coaching, endringsledelse, ledelse
Prosjektets tre problemområder
Prosjektet er en godt egnet arbeidsform når vi trenger å løse et konkret problem som krever målrettet innsats og fokus. Det er en helt opplagt organiseringsform når noen skal levere et konkret produkt, som for eksempel en bygning, eller en veistrekning. Det gjelder da å stable på beina en midlertidig organisasjon som er kompetent til å levere resultatet innen en bestemt kostnadsramme og tidsfrist. Når da resultatet til slutt foreligger, får prosjektet et oppgjør, vi oppløser prosjektorganisasjonen og resultatet går over i en vedlikeholdsfase.
Prosjektet hviler på et helt spesielt tankesett som innebærer at bare vi bruker gode nok metoder og nok tid i planleggingsfasen, vil gjennomføringen gå greit (selv om vi vet at det vil komme endringer underveis som vi må håndtere). Innovasjonen foregår på forhånd, i oppstartsfasen. Prosjektet innebærer at vi forplikter oss til å levere hele produktet. Det er med andre ord mye penger på spill, så det er viktig å ikke feile!
Prosjektet og vedlikehold
Jeg forstår godt at prosjektledere og -eiere også benytter seg av denne arbeidsformen innenfor IKT-relatert arbeid, selv om programvareprodukter er ganske forskjellig fra en bygning. Hvorfor skulle det ikke fungere fint også for programvareutvikling? Vel, det kunne kanskje vært en ide å spørre de som egentlig kan faget: utviklerne…
OK, det er altså tre problemer med prosjekt som arbeidsform…
Problem nummer 1: Oppstart
Tankesettet her er at nå må vi forstå hele problemet godt nok til at vi kan definere sluttleveransen. Vi bruker god tid på å spesifisere, analysere og planlegge slik at vi ikke får overraskelser underveis. Så er det å legge det hele ut på anbud og finne den beste (gjerne billigste) leverandøren. Denne forplikter seg så til å levere iht en plan og til en avtalt pris. Denne leverandøren får da en ny oppstartsfase før de kommer igang med selve utviklingen.
Hva er så problemet med dette?
Siden vi forplikter en komplett leveranse, innebærer et prosjekt alltid en stor økonomist risiko. Derfor må vi logisk nok gjøre grundig forarbeid. Dette må nødvendigvis ta mye tid – ofte så mye tid at verden rundt oss rekker å forandre seg mens vi jobber! Dessuten vet vi jo nå av erfaring at det på tross av denne grundigheten klarer vi ikke å unngå stor risiko. Uventede ting skjer garantert! For å få framdrift i denne fasen får vi et stort behov for å forenkle og “spikre ting”. Dette gjør at vi låser oss til en mengde antagelser som blir en del av spesifikasjonen.
Resultat: En sanseløs bruk av tid, som gir svært begrenset verdi. Vi bygger antagelser inn i spesifikasjoner, baserer oss på svært usikre estimater (som alle er multiplisert med en faktor) og har skaffet oss en ganske ustyrlig kompleksitet.
Problem nummer 2: Gjennomføring
Når man lager fysiske ting kan man enkelt og intuitivt følge framdriften med egne øyne. Det er også fullt mulig å gjøre kvalitetssjekker av konkrete delleveranser underveis og dette gjøres (selvsagt) i stor grad. Når produktet er programvare er dette helt annerledes, siden det eneste synlige ligger i det tynne skallet på toppen som vi kaller “brukergrensesnittet”.
Hva er så problemet med dette?
Hele prosjektet jobber mot en komplett leveranse, så det er slett ikke gitt at det foreligger delleveranser. Derfor er man prisgitt en svært teoretisk framdriftsmåling og kvalitetsvurdering. Prosjektstyringsmiljøet har funnet på ulike regimer som er ment å gi styring og innsikt i framdriften. Earned Value er et slikt eksempel. Men gir dette navnet mening? Har det noe med opptjent verdi å gjøre? Nei, dette sier egentlig bare noe om forbruk av penger! Ikke noe feil med å følge med på pengeforbruk selvsagt, men dette kan lett gi en falsk trygghet. Og så kan vi følge opp framdrift mot en milepælsplan med tilknyttede estimater. Dette er også en svært teoretisk form for styring, selvsagt. Hvor gode er estimatene egentlig? Og hvordan vet vi egentlig om en milepæl er helt oppnådd? Problemet nå er selvsagt at vi ikke fullfører noe synlig funksjonalitet underveis. Det er tross alt synlige, konkrete resultater som vil kunne gi oss verdifull informasjon om framdriften. Og ikke minst om kvaliteten!
Og så er det alle endringene. Leverandøren vil være interessert i mange endringer både fordi de er godt betalt, men også fordi det vil være en betimelig unnskyldning om framdriften skulle være for dårlig. Sett fra kunden er endringer kilde til galopperende kostnader og utsettelser. Dessuten er formell endringehåndtering kostbart.
Resultat: Et kostbart styringsregime som er teoretisk og ikke er egnet til å vise den egentlige statusen til prosjektet, samtidig som kostnadene uansett galopperer avgåde på grunn av alle endringene.
Problem 3: Avslutningen
Slutterminen er sannhetens øyeblikk for et prosjekt. Alle krefter settes inn på å få leveransen akseptert, slik at prosjektet kan få betalt. Alle prosjekter er nå i en slags unntakstilstand. Uventede ting har ganske riktig forekommet i rikt monn. Estimater var optimistiske. Så nå gjelder det å finlese kontrakten og jobbe hardt mot ett formål: At akseptansetest og sluttkontroll skal gå igjennom. I de siste ukene er det om å gjøre å “pynte brura” og bare bruke kreftene på det som er helt nødvendig.
Når prosjektet da til slutt har lappet sammen en leveranse, vil denne ofte være beheftet med dårlig kvalitet. Mye av kvaliteten ligger som kjent gjemt langt under overflaten i programvareprodukter, så det er håpløst for kunden å vurdere om dette produktet er vedlikeholdsvennlig. Vedlikeholdsvennligheten er den viktigste faktoren til et produkts livsløpskostnad.
Dessuten er det først nå vi får testet antagelsene som ligger innebygd i spesifikasjonen. Har vi løst riktig problem? Får vi de gevinstene vi kalkulerte med? Er ytelse og brukervennlighet bra nok?
Resultat: Prosjektet blir godkjent og får betalt, produktet overleveres til drift- og vedlikehold slik at alle manglene kan rettes opp. Denne “vedlikeholdsfasen” blir svært kostbar og tung, siden prosjektet har etterlatt seg kode som ikke følger de beste håndtverksmessige standarder. Hvorfor skulle de det, egentlig? Denne midlertidige organisasjonen blir målt på leveransetidspunktet, ikke på det langsiktige livsløpet.
For ordens skyld: Det er ikke nødvendig å utvikle IKT-systemer med prosjekt. Bare nevner det.
In: prosjektledelse, Samfunn, Uncategorized · Tagged with: Kvalitet, ledelse, prosjektstyring, Styring