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.

Læringsmulighet

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

 

Posted on February 20, 2015 at 4:54 pm by gamsjo · Permalink · 2 Comments
In: Forskning, kompleksitet, Scrum · Tagged with: , , , ,

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:

  1. Praktisk bistand
    • innkjøp av mat og annet én gang i uka
    • husvask annenhver uke
  2. 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

blind

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

eyes

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.

Posted on February 13, 2015 at 6:15 pm by gamsjo · Permalink · 4 Comments
In: ansvar, Lean

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å. CoachingProcess

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.

CoacingProcessDailyI 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).

CoachingProcessWIPPå 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.

 

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

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.

Posted on November 25, 2014 at 4:18 pm by gamsjo · Permalink · Leave a comment
In: prosjektledelse, Samfunn, Uncategorized · Tagged with: , , ,

Om risiko, innovasjon – og pudding

Hvilken strategi bør vi velge for å håndtere den uungåelige risikoen?

Det vil alltid være en sammenheng mellom vår vilje til å finne nye, fremtidsrettede, spennende løsninger og faren for å mislykkes. Dette vet alle som er opptatt av å lykkes bedre enn andre, enten de er idrettsutøvere eller aktører i et innovativt marked.

“Du kommer ikke først av å gå i andres fotspor”, “No pain – no gain”, “Den som intet våger, intet vinner”.

Alle forstår at man må tøye grensene og tråkke ut av komfort-sonen for å oppnå en utvikling litt utover det ordinære. Om målet ditt er “det ordinære” kan du slutte å lese her.

Tradisjonell prosjektstyring og tankegang er opptatt av å minimalisere risiko. Grundige analyser og detaljert planlegging skal gjøre prosjektet trygt. Fungerer dette egentlig? La oss se litt nærmere på årsakssammenhengene.

ForarbeidRisiko1

I figuren betyr ringen at det er en omvendt sammenheng, mao jo grundigere forarbeid, desto lavere risiko. Dette er en intuitiv og svært konvensjonell antagelse. Men hva om vi tenker oss at vi skal i gang med å utvikle et nytt IT-system. I våre tidlige analyser finner vi ut at brukerne ikke kan gi oss noe klart svar på hva de trenger. Videre ser vi at dette er et område vi ikke er helt trygge på, det er ganske nytt for oss. Dessuten vet vi at i dette markedet skjer det stadige endringer og skal vi være helt oppriktige er det sannsynlig at noe helt uventet vil komme til å skje det neste året. Hva om vi legger inn disse faktorene i årsakssammenhengen?

ForarbeidRisiko2

I fiiguren står C-ene for constraints (beskrankninger). Under slike rammebetingelser begynne vi å ane at det grundige, tidkrevende forarbeidet kanskje ikke vil redusere risikoen.

Usikre brukere: Man kan intervjue brukere, lage prototyper og be om brukernes tilbakemeldinger på om dette virker fornuftig. Om de liker det. Men det vil være grenser for hvor mye kunnskap vi kan få på denne måten. Historien er full av gode forsøk på brukerundersøkelser, der man setter sin lit til det brukerne uttrykker og baserer kravspesifikasjonene på dette. Men når systemet vel er ferdig, viste det seg at brukerne ikke likte det de fikk allikevel. Man kan si det er “overraskende vanskelig” å komme til bunns i brukernes behov og ønsker på et teoretisk plan. Det er først når de sitter med løsningen foran seg og får prøvd det ut at den endelige dommen vil falle. I en ren analysefase er det overveiende sannsynlig at vi vil måtte spikre noen antagelser for å få framdrift. All erfaring viser at dette er svært risikabelt!

Dynamikk: I vår tid er det i de fleste markeder en betydelig dynamikk. Behov endrer seg, ny teknologi dukker opp, alternative løsninger finnes – alt dette mens vi kjører prosjektet. Om vi oppdager dette må vi kjøre kostbar endringsbehandling. Om vi ikke oppdager det underveis, ender vi opp med et utdatert produkt. Hva om endringer skjer mens vi analyserer behovene og beskriver løsningene? Om vi tar oss god tid her, risikerer vi jo at spesifikasjoner og planer er utdaterte allerede før vi starter!

Stor nyhetsgrad: Om vi er innovative og det vi skal lage er helt nytt må vi selvsagt bruke en del tid for å finne mulige løsninger. Men det vil også være begrenset hva vi kan få ut av en slik analyse. Antallet ukjente faktorer vil være stort, og disse faktorene kan til alt overmål påvirke hverandre. Faren vil være stor for at vi her vil basere oss på antagelser som er vage, og kun egnet til å gi oss en falsk trygghetsfølelse.

ForarbeidRisko3

Så under slike rammebetingelser vil vi med andre ord få en sammenheng der grundigere forarbeid vil øke risikoen(!)

Oppsummert: Når vi har rammebetingelser som gir dynamikk og usikkerhet – som de fleste IT-prosjekter har – må vi være bevisste på å ikke bruke for mye tid og energi på forarbeide før vi setter i gang.

Alternativet til grundig analysearbeid

Alle tyr vel fra tid til annen til “prøve-og-feile-metoden”. Når vi er på utrygg grunn lønner det seg å gjøre noen tester før vi tar på oss for store forpliktelser.

Vi hadde en forholdsvis nyinnkjøpt hytte med furu vegger, tak og gulv. Etter noen år var vi enige om at det kanskje var litt for mye gulnet furu, så vi bestemte oss for å tilføre veggene og taket noe farge. Men vi ville fremdeles at treverket skulle være synlig, så vi trenge noe som var transparent. Vi (les: kona) gikk i gang og sjekket markedet og fant fort ut at det veldig mye å velge imellom av beis og oljebaserte produkter. Men det er jo vanskelig å få et godt inntrykk av farge og gjennomskinnelighet i brosjyrer og på nett, så vi skjønte fort at her måtte vi teste ut alternativer. Heldigvis har malingsbransjen forstått dette og gjort det mulig å kjøpe små kvanta for å gjøre tester. Så vi testet ulike farger og produkter på løse planker, og deretter på selve hytteveggen før vi var trygge nok til at vi kunne gå til innkjøp av store kvanta. Vi endte opp med et for oss helt nytt produkt basert på voks. Denne skulle i følge oppskriften på boksen påføres i ett strøk, og overskuddsfarge tørkes av etter ca 20 minutter. Når vi så var i gang med å påføre dette produktet, oppdaget vi raskt at resultatet på ingen måte var gitt ved å følge oppskriften på boksen til punkt og prikke. Vi trengte fremdeles å vinne erfaring med hvordan den skulle påføres og ikke minst hvor lenge vi skulle vente med å tørke av overskuddsfarge. Antageligvis er det stor forskjell på treverk og slike detaljer kan ikke spesifiseres på forhånd.

Her kommer  Lean-prinsippet “Last Responsible Moment” til sin rett. Vi venter med å binde oss til endelig løsning før vi har validert antagelsene våre gjennom å ha få ting i arbeid.

“The proof of the pudding is in the eating”

Det første nødvendige skrittet å ta er å innse at vi ikke har – eller kan få – full kontroll. Vi må leve med usikkerheten: Det er bare sluttresultatet som vil fortelle oss om vi lykkes eller ikke. Selv det å lage en perfekt pudding er overraskende vanskelig og usikkert – vi må faktisk smake på det ferdige produktet før vi kan evaluere resultatet og konkludere om vi har lykkes eller ikke.

I klartekst betyr dette at fram til det tidspunktet vi ferdistiller noe, vil alle påløpte kostnader måtte betraktes som økonomisk risiko. Vel, det kan hende at noe av arbeidet kan ha verdi, selv om sluttresultatet var ubrukelig, men det er slett ikke sikkert.

KostRisikoVannfallPudding

Historien er full av IT-prosjekter som etter alt for lang tid og akkumulerte kostnader finner ut at de har feilet. Kanskje de har løst feil problem. Kanskje de har løst problemet feil. Uansett – de har oppdaget dette alt for sent!

Smidig tankegang anerkjenner virkeligheten. Vi må forstå dynamikken og usikkerheten vi står overfor og vi må ta denne virkeligheten på alvor. I stedet for å bekjempe usikkerheten må vi forsøke å absorbere den! Dette gjør vi ved “prøving og feiling” eller kanskje et bedre uttrykk: Empirisk Prosesskontroll. Vi må skaffe oss empiri så raskt og billig som mulig slik at vi kan validere antagelsene vi har gjort. Og vi er ydmyke for at vi kan ha tatt feil.

KostRisikoSmidigPudding

I figuren ser vi hvordan man kan kjøre små tester eller eksperimenter med det for øye å vinne erfaring og få validert antagelser. De første inkrementene vi ferdigstiller lager vi bare for å få i gang en valideringsprosess i tett samarbeid med brukerne. Dette blir veldig tilsvarende den vitenskapelige metode. Her ser vi også at konsekvensen ved å feile blir liten. Vi kan med andre ord senke skuldrene og våge oss utpå litt dypere vann en tidligere. Om noen av inkrementene ikke er vellykkede blir ikke konsekvensen så stor. Dessuten gir også disse inkrementene vedifull læring!

Så dette slitter helt andre krav til organisasjonen enn tradisjonell prosjektstyring. Vi har et annet syn på virkeligheten og vi trenger helt andre sett av metoder og ferdigheter.

 

 

Smidig, Lean Startup og Customer development – som hånd i hanske?

Lean Startup har blitt svært populært etter Eric Ries kom ut med sin bok i 2011. Lean Startup har blant annet blitt omfavnet for sin fokus på validert læring og jeg er en stor tilhenger av rammeverket. Det er likevel mange misforståelser i sammenhengen mellom Lean Startup, smidig og customer development.

Jeg har sett flere eksempler på at Lean Startup settes opp mot smidig som om det skulle være motsetninger mellom de to. Det er vanskelig å forstå at det skal kunne være slik om man kjenner bakgrunnen.

Eric Ries skrev Lean Startup etter å ha vært med på å starte flere selskaper. Etter å ha feilet med there.com ble Eric Ries co-founder av IMWU sammen med Will Harvey. I sin jakt på kapital til selskapet kontaktet Will Harvey en investor og serie-entreprenør han kjente fra tidligere, Steve Blank. Som en motytelse mot å investere i IMWU ville Blank at Ries og Harvey skulle evaluere hans klasse innen Entreprenøskap ved University of California, Berkeley.

Gjennom sin erfaring med både ”spectacular failures” og sukesser i startup verden begynte Steve Blank å reflektere rundt om det var noen fellestrekk mellom de selskapene som lykkes bedre enn andre. Resultatet at disse refleksjonene er det som vi i dag kaller Customer Development. Blank observerte at vi hadde mange rammeverk og teorier for å håndtere produkutvikling- og teknisk risiko, men at det helt manglet noe for å håndtere kunderisikoen. Majoriteten av start-ups feiler fordi de lager noe som kundene deres ikke vil ha, eller ikke ser nytten av av. CB Insights undersøkte over 100 startups som feilet og over 85% av disse oppga somhovedårsak at de ikke løste et viktig nok problem for kunden (ref. Kapital).

Customer development prosessen er et rammeverk for å håndtere denne kunderisikoen. Rammeverk består av 4 steg; Customer discovery, Customer validation, Customer acquisition, Company building.

Custdev

 

Første steg er Customer discovery; det første vi gjør er å dokumentere hypotesene vi har om brukerne og hva som skaper verdi. Bruk gjerne Business model Canvas for å dokumentere, lag en stor versjon av canvaset – heng det på veggen og bruk post-its for å dokumentere hypotesene. Da får dere synliggjort antagelser og endringene som vil skje underveis. Et godt canvas kommuniserer veldig bra og det hjelper oss å organisere tankeprosessen vår.

Men, alt vi har nå er hypoteser, et fancy ord for gjetninger….. Så neste steg er å innse at det ikke eksisterer noen fakta inne i bygningen – GET OUT OF THE BUILDING er et av mantraene i Customer development – snakk med kunder, leverandører, partnere – de som du tror har et problem eller behov som du kan løse. Dette skal gjøres på en strukturert måte gjennom å designe eksperimenter, gjøre tester, samle data og på den måten få mer innsikt. Første målet er å få validert at vi løser et problem eller behov som det er verdt å løse, det vil si det skaper verdi for en spesifikk kundegruppe.

I Customer validation steget bruker vi resultatene fra Customer discovery og ser om vår foreslåtte løsning/funksjonalitet faktisk løser problemet eller fyller et behov for en kundegruppe. Igjen skal dette gjøres på en strukturert måte slik at man får testet problemet vs solution/funksjonalitet.

Customer development er en iterativ prosess og vi tror ikke vi klarer å få alt riktig første gangen – derfor har vi pivots…en pivot er ganske enkelt noe som skjer når du har fått validert at en av hovedhypotesene i business model canvas ikke holder og du må endre fokus. Pivots tar oss tilbake til Customer discovery fasen for å oppdatere business model canvas, designe nye eksprimenter og avdekke ny informasjon. Gjennom denne iterative prosessen er målet å komme frem til en repeterbar, skalerbar forretningsmodell.

Så hva har dette med smidig utvikling å gjøre?
Customer development har sitt fokus på kunden – men trenger og en ramme for produktutvikling som passer inn med det iterative måten å jobbe på. Her kommer smidig utvikling inn og passer som hånd i hanske med customer development prosessen.
Customer development og smidig utvikling er komplementære og begge styrker hverandre. Customer development støtter tidlig i prosessen med HVA som skal bygges og er dermed med å validere innholdet i produktkøen.

Da Eric Ries tok klassen til Steve Blank i 2008 ved University of California, Berkeley, var det flere brikker som falt på plass. Ries med sin utdannelse som programmerer som hadde brukt rammeverk som XP og Scrum i sine starts-ups (han var også Certified Scrum Master) med en viss suksess, men også i there.com som feilet – kombinerte smidig utvikling med Customer Development prosessen i IMWU. IMVU måtte gjennom en serie pivots før de endelig fant sin forretningsmodell.

Lean Startup kom ut i 2011 og er basert på erfaringene Eric Ries har som gründer. I Lean Startup kombineres smidig utvikling og Customer development.

leanstartup

Omtrent samtidig kom Alexander Osterwalder med sitt business model canvas. BMC hjalp på en utmerket måte å visualisere de hypoteser man må teste gjennom Customer development prosessen. Sammen er disse 3 rammeverkene en svært kraftfull pakke.

Business Model Canvas for å visualisere og strukturere alle hypotesene våre, Customer development prosessen for å redusere kunderisikoen og smidig utvikling for å kunne ha korte iterasjoner fra validert hypotese til oppdatert/klart produkt eller tjeneste.

Nylig utga Alexander Osterwalder boken Value Proposition Design som styrker Business Model Canvas ytterligere.

 

 

 

 

Smidig og forretningsutvikling i et livssyklusperspektiv

Vi som tilhører “smidigmiljøet” må nok innrømme at forretningsutvikling har blitt stemoderlig behandlet alt for lenge. Vi har riktignok hele tiden hatt fokus på kunden og brukerne, og at mye av poenget med smidig var å maksimalisere på kundeverdi. 

Mantra:

“Vi må bruke kreftene på det som betyr mest for brukerne – og det er feedbacken fra korte iterasjoner som gir oss kunnskap om dette”.

Dette er bra, men ikke nok. Vi hadde nok en naiv ide om at forretningsutvikling først og fremst skjedde i en tidlig fase i et produkts levetid – og at Produkteier sammen med “forretningssiden” tok seg av dette. Det var en stadig tilbakevendende frustrasjon om at vi ikke maktet å integrere forretning og utvikling på en god nok måte. Produkteiere i Scrum var ofte i villrede og maktet alt for sjelden å finne ut hva som faktisk betyr mest for brukerne.

LivssyklusEnkel

Vi manglet gode metoder for forretningsutvikling og det var derfor kjærkomment når Eric Ries publiserte boka Lean Startup i 2011. Boka fikk stor oppmerksomhet og jeg husker ennå “lyden av puslespillbrikken som falt på plass”. Dette var jo en svært iterativ prosess, laget for å identifisere kundebehov, beskrevet av en utvikler – som til og med var Certified Scrum Master! Mantraet i Scrum om å “feile så fort som mulig” stemmer veldig godt overens med iterasjonene til Eric Ries. Man hans perspektiv er selvsagt “tidlig fase” når man skal finne ut om selve produktideen (visjonen) er verd å investere penger i.

Fram til Lean Startup boka hadde jeg (og mange andre kursholdere) undervist i begrepet Minimal Marketable Feature (MMF) som en god tankegang for Scrum Product Owners: Lag det minst mulige produktinkrementet som brukerne kan tenkes å oppleve som verdifullt. Hvis de ikke liker det, kaster du inkrementet. Hvis de liker det, deploy og benytt anledningen til å finne ut hvilke utvidelser de trenger.

Eric Ries definerer Minimal Viable Product (MVP) i Lean Startup. Dette er omtrent det samme som en MMF, men Ries (som på Berkeley-Haas var elev av Steve Blank, mannen bak Customer Development) fokuserte begrepet mot initiell fase og mao til å omfatte helt uferdige prototyper og nærmest “skisser” som ofte kan være nok til å sette i gang en fruktbar samtale med brukerne. Dette er altså optimalisert på å finne ut mest mulig om kundebehov på en raskest og billigst mulig måte. Samtidig gjelder det å bruke all feedbacken man kan samle på denne måten til å overbevise investorer om at her bør vi legge inn penger og skalere opp en større satsning!

LivssyklusReell

Mange erfarer at man må utvikle en rekke MVPer før man (eventuelt) har en solid nok hypotese på hva man skal lage. Det kan med andre ord gå flere iterasjoner før man får finansiering til å sette i gang med utviklingsfasen. Men det er ingen grunn til å slutte med Lean Startup-tankegangen nå! Smidig (og Scrum) kan fremdeles profitere på denne tankegangen med MVPer. Det er fort gjort å glemme at vi fremdeles har kompleksitet og dynamikk og at både eksisterende og kommende kunder er uforutsigbare. Det er uansett lurt å betrakte produktinkrementer som en måte å validere (mer eller mindre sterke) hypoteser på. Og for ordens skyld; de små, blå MVP-ene i figuren kan godt gjøres av det samme teamet som bemanner utvikling og vedlikehold. Det er ikke noe problem å innlemme MVP-er i en vanlig Scrum Produktkø.

Når et produkt har vært i markedet en stund og vi er inne i “vedlikeholdsfasen”, vil vi ha mest fokus på å holde kundene fornøyde med minst mulig innsats – altså en slags “innhøstingsfase”. Men også her kan det fremdeles være fornuftig å teste ut hypoteser i form av MVPer – som potensielt kan føre til en ny vår for produktet i spesielle markeder.

Så vår konklusjon er at Lean Startup komplementerer smidig og Scrum på en etterlengtet måte. Men Lean Startup svarer heller ikke på alt. Hvordan jobber vi fram en god forretningsmodell?  Hvordan finner vi kundene? Hvordan sikrer vi at kundene ikke bare liker det vi lager, men også er villige til å betale en god pris? Det er faktisk mange eksempler på “vellykkede” produkter som mange kunder elsker, men som allikevel ikke skalerer godt nok og derfor aldri vil oppnå en positiv nåverdi.

Her kommer to andre konsepter inn i bildet. For det første kan vi bruke Alexander Osterwalders Business Model Canvas som på en utmerket måte støtter opp under diskusjonen om den best mulige forretningsmodellen. For det andre kan vi gå tilbake til Eric Ries sin læremester Steve Blank sin Customer Development modell. Felles for disse er at de er svært iterative og fokusert på rask læring. Og de kombinerer på en utmerket måte med smidig.

Benjamin Sommer forklarer hvordan Customer Development og Smidig sammen med Business Model Canvas utgjør en kraftig kombinasjon i en lyntale på Smidig2014.

 

Når smidig møter virkeligheten

Alle smidig-initiativer møter et mer tradisjonelt styringssystem. Hvor annerledes dette systemet er varierer selvsagt, og kommer først og fremst an på to faktorer: Størrelse og alder. I de gamle, store organisasjonene må smidig forholde seg til en virkelighet som på mange måter er i konflikt; Et helt annet paradigme som ikke samvirker særlig godt med smidig.

Hybridmodellen

Så, i de fleste forsøk på å innføre smidig vil man i en periode måtte leve med en blanding. La oss kalle dette Vann-Scrum-Fall. Jeg har nylig skrevet om dette her.

VannScrumFall

Vann-Scrum-Fall

Det er altså fremdeles spesielle roller som gjør forarbeidet, det vil være en kjede av overleveringer mellom brukerne og teamet. Når teamet er “ferdig” vil de ikke ha et “Shippable Product”, men en slags “halvfabrikata” som kan demonstreres, men som på ingen måte er leveringsklar. Det gjenstår flere overleveringsnivåer og det vil ta tid før noe som helst er helt ferdig (i drift).

I en slik setting kan man få visse positive effekter av smidig. Men det er også fare for at effekten blir negativ. Jeg har sett dette mange ganger og jeg har laget en “topp-15″ uprioritert liste over de viktigste problemene.

1. Syklusproblemet
Lange iterasjoner gjør det vanskelig å lære og å optimalisere
2. Deadlineproblemet
Fokus på tid og kost gjør at vi ofrer det gode håndtverket
3. Overleveringsproblemet
Lang avstand mellom brukerne og utviklerne fører til manglende forståelse
4. Risikoproblemet
Risiko får vokse seg stor og dyr før den avdekkes
5. Innovasjonsproblemet
Får ikke anledning til å være kreative underveis
6. Flytproblemet
Arbeidet stopper opp fordi vi stadig må vente på andre
7. Eierskapsproblemet
Autoriteter styrer så detaljert at eierskapet hos utviklerne svekkes
8. Retningsproblemet
Roller og individer har ulike agendaer og målsetninger
9. Budsjettproblemet
Rigorøse budsjettprosesser gjør at vi binder oss for tidlig på dårlig grunnlag
10. Kompletthetsproblemet
Alt er like viktig, ingen spissing av tidsbruken mot det som gir mest verdi
11. Sårbarhetsproblemet
Rollefokuset fører til spesialisering og stor personavhengighet
12. Ullenhetsproblemet
At svært mye arbeid samles opp før vi fullfører, ødelegger gjennomsiktigheten
13. Suboptimaliseringsproblemet
Funksjonelle avdelinger med egne målsetninger fortrenger helhetssynet
14. Prosjektproblemet
Stadig opp- og nedbemanning av prosjekter i paralell vanskliggjør teamarbeidet
15. Fokusproblemet
Arbeidsdagen er preget av multitasking og avbrytelser

Hva kan vi gjøre med dette?

Alle disse problemene skal på en eller annen måte komme til overflaten om Scrum-teamene virkelig ønsker å stadig forbedre seg. Forbedring i starten av et slik smidig-løp vil i en eller annen form bestå i å få raskere gjennomløpstid i verdistrømmen. Gode Scrum team vil detektere hindringer og gjøre noe med dem. Det er ScrumMaster sin viktigste jobb å forsøke å fjerne identifiserte hindringer. Dette berører veldig ofte andre deler av organisasjonen, og da gjelder det å våge å si ifra.

Man kan si at god Scrum vil føre til at små “bomber” detonerer rundt om i organisasjonen. I praksis vil det være at Scrum Master ber om en samtale med rette vedkommende og foreslår endringer i arbeidsprosessene. Og siden vi jobber i korte iterasjoner kan vi gjøre disse endringene gradvis. På denne måten blir Scrum en slags debugger på organisasjonsnivå.

 

DebuggingOrg

Scrum som organisasjonens debugger

Eksempler:

“Teamet støter stadig på løsingsbeskrivelser som bygger på antagelser som ikke lenger er gyldige. Kan vi gå igjennom dette og løse opp i det slik at teamet kan selv kan finne de beste løsningene?”

“Vi opplever stadig at vi i tett samarbeid med brukerne finner enklere løsninger enn det som er spesifisert. Kan vi gå igjennom Spec´en og gjøre den mindre forpliktende?”

“Vi blir alt for ofte belemret med gamle feil, som det er tungt å søke fram og rette. Kan vi begynne å levere hyppigere, slik at feilene kommer raskere tilbake til oss?”

“Vi får ikke integrert systemet godt nok underveis, og det fører til at vi alt for ofte får integrasjoneproblemer rett før leveranse”

Etter at Scrum Master og resten av Scrum teamet iherdig har jobbet med å fjerne hindringer på denne måten, verdistrømmen gradvis kunne bli kjappere med langt hyppigere leveranse og bedre samarbeid mellom Scrumteamet og brukerne.

Tada

Optimale forhold for tett kundesamarbeid

 

Stagnasjon

Det er dessverre alt for mange som blir hengende ved en hybridmodell, og derfor går glipp av de store gevinstene som ligger og venter. Hvorfor skjer dette? Vel, den enkle forklaringen ligger nok i at en overgang til smidig innebærer en betydelig organisasjonsendring. Alle ledere vet at dette er smertefullt og kommer til  skape frustrasjon og ustabilitet. Vi risikerer å miste gode folk. Derfor er det veldig lett å prøve seg med en mer overflatisk endring, der vi innfører nye begreper (som Scrum Master, Produkteier, Sprinter, Retrospectiver) uten å endre på noe grunnleggende.

Jeg er ikke noen stor fan av John Kotter, men på øverste nivå er hans 8-trinns modell fornuftig. Og den starter naturlig nok med “establish a sense of urgency“. Om man mangler dette vil resten falle sammen og føre til en skinn-endring som ikke vil gi den potensielle gevinsten. Det kan være mange grunner til at ledelsen velger denne enkle “løsningen”, men jeg tror vi ser to hovedmønstre:

Det første mønsteret er formålsløshet. Det tas en beslutning om å innføre Scrum – uten at man riktig vet hvilket problem man skal løse med dette verktøyet. I samtaler med ledergrupper spør jeg alltid om forretningsmessige problemer og ambisjoner de har. Ikke alle kan gi noe klart svar på det. Når ingen riktig vet hvorfor man skal gjøre en endring er den dømt til å bli overflatisk.

Det andre klare mønsteret er uforstand. Det tas en beslutning om å innføre Scrum – uten at man har satt seg skikkelig inn i hva Scrum og smidig er. Man sender utviklerne på kurs og tenker at det er der – nede på IT-avdelingen – at endringen skal foregå. Stor feil! Scrum og smidig berører hele organisasjonen og alle – særlig ledergruppene – må få en grad av opplæring. Når Scrumteamene kommer settende med identifiserte hindringer de ønsker å få løst opp i, er ikke linjeorganisasjonen forberedt og Scrum Masterne blir bare oppfattet som “negative urokåker”.

Om man ønsker å få kontroll på risiko, komme raskere til markedet, øke innovasjonsevnen eller effektivisere så kan Scrum eller andre smidige rammeverk være løsningen. Men det er ingen vei utenom en helhjertet endringsprosess. Det kommer til å bli krevende, det blir ustabilt og til tider smertefullt.

Posted on October 30, 2014 at 6:26 pm by gamsjo · Permalink · Leave a comment
In: Endringsledelse, ledelse, Scrum, systems thinking, Teamarbeid · Tagged with: , , , ,

Evolusjon

IT-bransjen er inne i en langvarig, dramatisk evolusjon, der stadig flere organisasjoner innfører ulike former for iterative prosessmodeller for sine IT-satsninger. På 90-tallet satset alle på sekvensielle faser og tradisjonell prosjektstyring. Jeg har selv vært med på å lage noen veldefinerte eksemplarer. Denne tankeganger er forlatt av store deler av bransjen, men ennå henger en del igjen. De aller fleste har innført eller har ambisjoner om å innføre mer smidige metoder. Verden går gradvis framover i retning av stadig kortere iterasjoner og hyppigere leveranser. Jeg har funnet at det grovt sett dreier seg om fire stadier:

  1. Vannfallsmodellen – Sekvensielle faser. Typisk årlige leveranser.

  2. Hybrid – Vannfall med Scrum i utviklingsfasen. Noe hyppigere leveranser.

  3. Scrum – Smidig, iterativ, evolusjonær. Leveranse typisk annenhver uke.

  4. DevOps – Kontinuerlige leveranser, mange ganger daglig.

Vannfallsmodellen

Trykk for å se større bilde

Praktiseres stadig av en del aktører som av ulike grunner ikke behøver å være særlig innovative. Ideen er å standardisere en fremgangsmåte gjennom detaljerte regler, sjekkpunkter, prosedyrer og rollebeskrivelser slik at man kan gjenta den samme fremgangsmåten prosjekt for prosjekt. Holdes i stor grad i live av prosjektstyringsaktørene som Project Management Institute (PMI) og Prince2 samt IT Service Management og ITIL. I offentlig sektor i Norge er det Difi og Prosjektveiviseren som holder denne ideen levende.

 

 

Hybrid

Svært mange (antageligvis de aller fleste) IT-organisasjonene i Norge er i dette stediet i evolusjonen. Noen er her helt bevisst og ser dette som en endestasjon, for andre er dette en mellomstasjon på vei mot “helt smidig” og Scrum. NB: en del svært synlige aktører vil helt feilaktig kalle dette for “smidig”. Dette er høyst tvilsomt, ettersom denne modellen har en lang rekke klare brudd med verdiene og prinsippene i Agile Manifesto – som definerer Smidig. Prosjektveiviseren til Difi har en viss støtte for iterasjoner og faller inn i denne kategorien. Det man forsøker på her er å blande to svært ulike tankesett der det ene fokuserer på grundig analyse og planlegging, mens den andre fokuserer på å feile billig og raskt og å lære mens man jobber. En del vil hevde at disse to er som olje og vann…

 

Scrum

Denne modellen bryter fullstendig med det meste innen tradisjonell prosjektstyring og ledelse. Dette er empirisk prosesskontroll, hvilket betyr at resultatet av en iterasjon danner basis for de neste iterasjonene. Forståelsen av Scrum forvaltes av Scrum Alliance og Scrum.org. Du finner en god definisjon her. Scrum er fullstendig i tråd med Agile (smidig) som sier at suksess ikke dreier seg om prosjektstyring, men i stedet om å ha flinke, dedikerte folk som jobber godt sammen tverrfaglig i korte iterasjoner – sammen med kunde/sluttbruker og forretning.

 

 

DevOps med kontinuerlig leveranse

DevOps

Ukentlige leveranser er alt for sjelden for mange, og de senere årene ser vi stadig fler som tar skrittet “forbi Scrum” og frigjør seg fra de tidsgitte iterasjonene. Her er det om å gjøre at utviklerne jobber så produksjonsnært som mulig og idriftsetter nye små oppdateringer mange ganger daglig. En kommentar til dette er det er fullt mulig å levere daglig innenfor Scrum-rammeverket også.

 

 

Posted on October 13, 2014 at 12:48 pm by gamsjo · Permalink · Leave a comment
In: Endringsledelse, inkrementell utvikling, Scrum · Tagged with: , , , , ,

Bokomtale: User Story Mapping

rc_cat_USMJeff Patton nærmer seg endelig ferdigstillelse av boka si om User Story Mapping. Denne er svært etterlengtet og denne ikke helt ferdige utgaven jeg har lest, lover veldig godt! De som overhodet ikke er kjent med User Story Mapping kan godt ta en sveip innom denne siden til Patton.

Boka beskriver selvsagt teknikken (eller metoden om du vil) User Story Mapping. Men dette er kanskje ikke det mest interessante. Teknikken er fin den og forholdsvis lett å praktisere. Men som med alle metoder og teknikker – det blir ikke skikkelig bra før vi forstår det grunnleggende tankesettet bak.

Så boka er mye mer enn en lærebok i USM – den handler også grunnleggende om innovasjon, læring, tverrfaglig teamarbeid, design, kommunikasjon, smidig systemutvikling og optimalisering.

 

Man kan si boka handler om den oppdagelsesreisen en IT-organisasjon gjør sammen med brukerne sine. Hvordan jobber vi for å finne ut hva vi skal lage? Noen gjør dette helt tilfeldig og følger prinsippet om “siste taler får fokus”. Noen baserer seg på rene gjetninger. Andre går etter den komplette spesifikasjonen og gjør tidkrevende analyse- og planarbeid før man setter i gang å lage funksjonalitet. Jeff Patton argumenterer svært overbevisende om at vi må være bevisste og strukturerte når vi forsøker å oppdage de viktigste behovene til brukerne. Og vi må jobbe inkrementelt og evolusjonært tett sammen med dem. Ett er sikkert – det holder ikke bare å spørre brukerne. Vi må være sikre på at vi forstår hva de trenger – ikke bare hva de sier de trenger.

USM

Et veldig spennende aspekt ved USM er at teknikken hjelper deg å identifisere hva du skal VENTE med å lage, og ikke minst hva du IKKE skal lage. Her ligger et enormt potensiale; IT-bransjen har lang historie i å utvikle, levere og vedlikeholde en helt unødvendig stor mengde funksjonalitet. Det blir veldig naturlig å kombinere USM med Lean Start-up. USM kombinerer veldig godt med Build-Measure-Learn syklusen og er uovertruffen for å identifisere Minimal Viable Product.

Jeg har i flere år benyttet USM i Scrum-kursene mine. Særlig i Certified Scrum Product Owner kurset vil en vesentlig del utnytte USM. Hver gang Product Owner vurderer å setter i gang med en større satsning (uavhengig om dette er innenfor et eksisterende område eller et nytt) anbefaler jeg å planlegge inn en USM-workshop. Ta med representanter for de potensielle brukerne, andre interessenter, Scrum Master og ikke minst hele utviklingsteamet.

” Story mapping is a technique that provides the big picture that a pile of stores so often misses”

Martin Fowler i forordet til boka

Hvem er du som trenger denne boka? Vel, alle som er interessert i smidig systemutvikling! Litt mer spesifikt det er i hvert fall

“But when the two strains of practice—design and development— collaborate, the work becomes electric and has the potential to create a living, breathing product. Teamwork breathes life into the monster and makes people love it.”

Alan Cooper i forordet til boka.

Posted on August 29, 2014 at 3:20 pm by gamsjo · Permalink · Leave a comment
In: forretningssiden, Planlegging, produkteier, Teamarbeid, Uncategorized · Tagged with: , , ,