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.

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?

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.

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.

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.

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.

 

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.

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.

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!

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.

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

 

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.

 

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.

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

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

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

 

 

Bokomtale: User Story Mapping

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

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

• du som trenger å få bedre oversikt over produktkøen,

• du som sliter med kompleksitet og trenger hjelp til å finne de enklest mulig løsningene,

• du som er innovativ og trenger hjelp til å validere ideen din på en billigst mulig måte,

• du som behøver å forstå brukerne dine bedre,

• du som vi hjelpe brukerne dine til forstå sine egne behov bedre,
• du som ser behov for at alle involverte på tvers av mange ulike roller skal få en felles forståelse.

Selvorganisering – hva og hvorfor

De fleste organisasjoner styres etter en ovenifra-og-ned modell, der medarbeidernes autoritet avgjøres av hvor høyt oppe i hierarkiet de befinner seg. Jo større beslutning, desto høyere opp skal den tas. I slike organisasjoner kommer også mål, planer og budsjetter ovenifra. Man antar at vi på forhånd vet hvilke strukturer (prosesser, roller, avdelinger, partnere, outsourcing etc..) organisasjonen behøver for å drives effektivt. Eventuelle endringer i strukturene har stor betydning, er krevende og fordrer derfor grundige analyser og planer. Og vil derfor nødvendigvis ta lang tid.

Alternativet er en nedenifra-og-opp modell der beslutninger tas med minst mulig avstand til virkeligheten (og brukeren). Her er tankegangen at den personen (eller den gruppen) som er midt oppe i situasjonen også er den (eller de) som er best egnet til å beslutte. I en slik situasjon vil tidsforbruket nødvendigvis kunne kortes kraftig ned, og vil kan raskt få erfare hvor god beslutningen var.

Dette innebærer implisitt at makt forskyver seg nedover i systemet og at arbeidet kan gjøres i ganske autonome, selvstyrte team. Lederrollen går dermed fra å sende styringssignaler nedover i systemer til å bli en tilrettelegger for de som gjør jobben. Fokus dreier på denne måten vekk fra organisasjonen selv og over på brukerne/kundene. Man kan si at pyramiden blir flatere og snus opp ned.

Ovenifra-og-ned står for fall

Tradisjonelle styringssystemer bygger på Taylorisme eller “vitenskapelig ledelse” beskrevet av Fredrick Taylor på begynnelsen av forrige århundre. Dette regimet ble ikke laget for omgivelser med stor dynamikk og kompleksitet – som vi har i dag – så det er et opplagt behov for å tenke nytt her. Mange gjør nettopp det og det er slående at svært mange eksperter på ledelse er samstemte her:

Peter Drucker uttaler (allerede) i 2001 i Management Challenges for the 21st Century “Knowledge workers have to manage themselves. They have to have autonomy”

Gary Hamel, en annen inflytelsesrik ledelsesguru, tar sterkt til orde for langt mer selvorganisering og flate organisasjonsstrukturer i boka What matters Now, How to Win in a World of Relentless Change, Ferocious Competition, and Unstoppable Innovation

Hamel stor også bak Management innovation eXchange (The MiX) et svært aktivt nettverk der blant annet Statoils Bjarte Bogsnes er en vesentlig bidragsyter om Beyond Budgeting og Smidig virksomhetsstyring.

John P. Kotter gjør på mange måter det samme som Drucker og Kotter og etterlyser lederskap i HBR-artikkelen Management is (still) not leadership: “Leadership is about vision, about people buying in, about empowerment and, most of all, about producing useful change.”

Det smidige manifestet (fra 2001) sier Individuals and interactions over processes and tools og The best architectures, requirements, and designs emerge from self-organizing teams. I ettertid har opphavsmennene (og andre) brukt mye energi på å poengtere at dette mener de faktisk! Det er altså dedikerte, flinke, autonome mennesker som samhandler godt som er mest avgjørende for suksess.

Autoriteter innen kompleksitetsteori er også klare på dette punktet. Dagens utfordringer er på mange måter mer sammensatte, dynamiske og komplekse enn vi hadde for en del tiår siden. Når vi gir oss i kast med komplekse problemer duger ikke lenger de detaljerte planene og de lange beslutningsveiene. På samme måte er det med styringssystemer; de detaljerte stillingsinstruksene, prosedyrene og måleregimene (Management By Objectives) vil være i veien for innovasjon og tilpasningsevne. Disse beskrivelsene og målingene vil på mange måter sementere Status Quo i stedet for å stimulere til den nødvendige nytenkning. De som vil kan lese mer om dette her.

 

Hva innebærer egentlig selvorganisering?

Når jeg snakker om dette opplever jeg stadig at ledere finner dette “interessant” og “spennende”, men samtidig veldig fremmed og nærmest eksotisk. Noe som sikkert kan passe for andre…

Vi finner selvorganisering overalt i naturen. Når flokker av gjess flyr sydover om høsten har de funnet ut at det kan være lurt å legge seg i en V-formasjon for å spare krefter. De bytter på å “dra”. De tar litt ulik rute hver gang, selv om de skal til samme bestemmelsessted som i fjor. På den måten tilpasser de seg vær og vind og mellomlander der de finner en fredelig liten slette som passer de behovene de har. Det har ingen kunnskap om aerodynamikk, ingen plan, ikke kart – bare retningssans og en fantastisk, dynamisk tilpasningsevne.

 Fiskestimer, maurtuer og bisvermer er andre eksempler på selvorganisering i naturen. Hvorfor skulle ikke vi mennesker kunne operere på denne måten? Vel vi gjør jo det allerede.

I små oppstartsbedrifter vil måten de jobber på og hvem som gjør hva avhenge av ting som tilgjengelighet, erfaring og lyst – ikke stillingsbeskrivelsen. Du hører aldri “nei, det der er ikke min jobb” i en liten gruppe gründere som brenner etter å lykkes. Samhandlingen vil være spontan og tilpasset situasjonen. Det er forresten dette som er modellen for et Scrum team som skal være av passe størrelse (4-9 personer på heltid) der rollene har mindre betydning enn teamet som helhet.

Byutvikling er et annet eksempel. Vel, det vil alltid være byplanleggere som forsøker å anslå behov for butikker, bank, skoler osv og lager en initiell plan. Men over tid vil vi se stor dynamikk – styrt av loven om tilbud og etterspørsel – der butikker og andre bedrifter kommer og går.

Til slutt vil jeg trekke fram rundkjøringen der myndighetene har valgt å la hver og en av oss avgjøre om vi skal kjøre, sakke farten eller stoppe helt opp. Motpolen – som baserer seg på Taylorisme – er jo lyskrysset der myndighetene har tatt kommandoen og bestemmer for deg om du skal stoppe eller ikke. Vi vet ut fra utallige målinger at rundkjøringen er fullstendig overlegen både hva gjelder flyt (gjennomløpskapasitet, throughput) og ulykker. Les mer om dette her.

 Vi behersker med andre ord selvorganisering ganske godt, bare vi slipper den til.

Gruppedynamikk

Dette temaet er det skrevet, forsket og sagt mye om. Selvsagt! Gruppedynamikk er et stort fagfelt som vi kan bruke for å forstå samhandling innen lagspill, i familier, i stammer / klaner, i ledergrupper og ikke minst i tverrfaglige team.

Bruce Tuckmann definerte i 1965 gruppedannelse som en firetrinns utvikling: Forming – Storming – Norming – Performing. Målet er (selvsagt) å nå Performing, der gruppa fungerer godt sammen. En enkel erkjennelse vi finner når vi anvender denne modellen er at det tar tid å bli et godt team. Og så er det viktig her å minne om at Performing ikke er en stabil tilstand. Alle team vil når de blir utfordret på nye områder – eller når teammedlemmer blir byttet ut – finne seg i å starte på Forming igjen.

En annen mye referert ekspert på teamarbeid er J. Richard Hackman som er veldig klar på hva som er ekte team (og ikke bare en gruppe mennesker som samarbeider litt): Research confirms that the presence of the five conditions–real team, compelling direction, enabling structure, supportive context, and competent coaching–enhances team performance effectiveness.

MIT har forholdsvis nylig gjennomført en stor studie der de målte samvirkningen mellom teammedlemmer med måleintrumenter og komme fram til det klare resultatet at de beste teamene er “balanserte”. Dette betyr at alle teammedlemmene interagerer med alle de andre – med omtrent samme intensitet. Av dette kan man slutte at team med en utpekt, styrende og kontrollerende teamleder har vanskelig for å fungere like optimalt som et selvorganiserende team der alle i utgangspunktet er likeverdige.

Det er en helt klar konsesnus om at et godt team har større kapasitet enn summen av individenes kapasitet. Samarbeidet er i seg selv verdiskapende og fører til bedre, mer robuste løsninger.

 

Kjennetegn ved gode team

Klare mål og verdier – alle i teamet har samme oppfatningen av retningen, det er ikke konflikt mellom egne mål og teamets mål. Og de har i stor grad de samme verdiene.

Medlemmene forstår sin egen rolle i teamet – I alle team er det visse strukturer – ofte et slags hierarki – der folk spiller ulike roller. I de gode teamene er alle inneforstått med sin egen rolle – som vil være relativ til de andre i teamet.

Tillit – Folk i teamet er trygge nok på hverandre til å være åpne og ærlige, også når ting går galt.

Åpen, effektiv kommunikasjon – I de gode teamene kan vi observere at de snakker med hverandre i “halve setninger” og stikkord. Allikevel blir det ikke misforståelser.

Energi og engasjement – Man kan tydelig se at folk i teamet bryr seg – det kan observeres ved tidvis høylytte diskusjoner.

Full deltagelse i beslutningsprosesser – Alle i teamet deltar når viktige beslutninger skal tas. Ikke dermed sagt at alle har like stor vekt.

Ledere med ubetinget støtte – Omgivelsene rundt gode team viser tydelig at de har tillit til teamet ved å la være å blande seg. Om teamet hele tiden produserer resultater er det nok å observere det de produserer og effekten av dette. Lederne er alltid parat til å finansiere forbedringer.

Konstruktiv konflikthåndtering – Det etablerer seg en form for energiske diskusjoner der man kommer styrket ut av konflikten.

Ulikheter – I de gode teamene er ikke medlemmene alt for like. De har ulike personlighetstrekk, ulike styrker og svakheter.

Intakte over lang tid – Gode team består av individer som er bortimot full tid i teamet og dessuten er  teamet er intakt over lang tid. Det tar tid å bli et godt team!

Blir coachet– team må stadig fornye seg når de får nye utfordringer, men behovet for fornying og forbedring er vanskelig å detektere innenifra. Derfor er det av stor verdi å ha en alliert som er tett på – men på utsiden – som kan observere og utfordre Status Quo når det er nødvendig.

Innovasjon og grader av selvorganisering

I arbeidslivet ser vi grader av selvorganisering, og slik vil det nok alltid være. Dette har med størrelse å gjøre, med firmakultur og ikke minst med typen arbeid som skal utføres. Om man er i et domene med forholdsvis lite dynamikk og kompleksitet vil Taylorisme kunne fungere godt. Har vil effektivitet og lave kostnader være styrende suksessfaktorer. Om man derimot befinner seg i et domene der suksess baserer seg på tilpasningsdyktighet og innovasjon, vil man måtte bevege seg i retning av selvorganisering.

Hackman differensierer mellom fire grader av selvstendighet eller autonomitet:

Manager-led teams Teamet utfører det de får beskjed om. De har ikke autoritet til annet enn å utføre oppgaver. Ledelsen definerer teamet, retningen og prioriterer oppgaver. Ledelse følger opp framdrift. Teamet kan ha noen grad av myndighet til å bestemme hvordan en oppgave skal løses.

Self-managing teams Teamet er ansvarlig for detaljplanlegging og oppfølging av progresjon.

Self-designing teams Teamene har myndighet til å endre på team-sammensetningen og til å utfordre omgivelsene for å oppnå innovasjon og forbedring.

Self-governing teams Helt autonome team som sette seg mål, former seg selv og ellers tar alt ansvar.

Dette er i realiteten en ganske flytende skala. Man innfører ikke selvorganisering over natta. Særlig ikke om man befinner seg i startgropa; der utgangspunktet er svært tradisjonelt styresett med høyt hierarki og streng avgrensning mellom ledelse og arbeid. Vi må her huske at dette skiftet innebærer både omfattende struktur-, prosess- og ikke minst kultur-endringer. Dette vil være en reise over mange år.

(Norsk arbeidsliv nok heldigere stilt enn det vi finner i helt andre kulturer. I Norge har vi tradisjonelt hatt en pragmatisk lederstil og arbeiderne “på gølvet” har gjennomgående en ganske stor grad av myndighet.)

Det er spennende å studere suksessfulle firmaer som Morning Star (som står bak self management institute) Gore og Semco (les boka Maverick!) som alle langt på vei er basert på Self-governing prinsippet. Disse selskapene er ekstremt opptatt av innovasjon og deler synet på at innovasjon kommer nedenifra der de som gjør jobben møter kundene. Når en medarbeider får en god ide, skal det være raskt og enkelt å finne finansiering og støtte til å sette ideen ut i live. Men disse selskapene er svært modne og representerer foreløpig et ganske uoppnåelig regime for mange mellomstore og store bedrifter.

Spotify er et spennende eksempel på et svært innovativt selskap som vokser hurtig for tiden.  Hvordan de klarer å beholde selvorganisering som prinsipp på tross av at de begynner å bli et ganske stort selskap kan man se mer om her. Bruker vi Hackmans terminologi her vil de nok havne på Self-designing teams.

Maktforskyvning

Når vi innfører økende grad av selvorganisering fører dette til at noen personer mister makt og posisjon, samtidig som andre tilføres det samme. Jeg har selv observert organisasjoner som har beveget seg i denne retningen og som ender opp med langt færre mellomledere. De fleste er med på at dette kan være et gode for bedriften; Sjefer tilfører ikke direkte verdi – de bare styrer og koordinerer. En grundig verdistrømanalyse i et Lean-program vil typisk peke på mellomledere som “waste”. Dette er en brutal, men ikke desto mindre reell erkjennelse.

Så, selv om mange (alle?) kan være med på at lavere hierarkier, færre ledere og mer fokus på de som faktisk skaper verdi kan være av det gode, vil det nødvendigvis føre til motstand. Få vil aktivt jobbe for å overflødiggjøre seg selv! Så for å lykkes med å øke graden av selvorganisering må toppledelsen være villige til å sette mye på spill og de vil miste gode medarbeidere. Create a Sense of urgency (Kotter) er fremdeles punkt nummer én over faktorer som må til for å skape endring; Det skal mot og utholdenhet til for å oppnå varig endring!

Cynefin for beslutningsstøtte og ledelse

Etter at Dave Snowden i 2007 publiserte A Leader’s Framework for Decision Making i Harvard Business Review har han vært en ettertraktet fordragsholder og Cynefin-modellen blitt stadig mer referert. Særlig i forbindelse med ulike former for Lean- og Agile-relaterte konferanser og blogger. Han er for eksempel Keynote-speaker på årets Scrum Gathering i Berlin. Cynefin blir også trukket fram blant annet av Gartner som i denne rapporten predikterer at 10% av IT-selkapene vil benytte Cynefin til å fatte belutninger.

Hva er Cynefin?

Cynefin er et rammeverk som gir oss svært nyttige holdepunkter når vi skal fatte beslutninger og løse problemer. Modellen beskriver ulike nivåer av kompleksitet og sier at hvilken problemløsningsmetode vi bør velge, avhenger av problemets kompleksitet. De opplagte problemene løser vi på en måte, de kompliserte litt annerledes, for de komplekse må vi tenke helt ulikt og de kaotiske problemene får vi en fjerde tilnærming.

Orden eller uorden?

Først kan vi lage et grovt skille mellom det vi kan kalle ordnet og uordnet. I det ordnede området har problemet klare begrensninger og vi har stabilitet. Disse problemene kan vi løse slik vi alltid har gjort: Vi analyserer og vurderer de ulike opsjonene vi har, veier dem opp mot hverandre og gjør et valg. Vi regner da med at vi har funnet en løsning som er god nok. Her kan vi med andre ord forstå relasjonen mellom årsak og virkning (kausalitet). I det uordnede området har vi grader av ustabilitet og vi vil ikke klare å finne løsningen kun ved analyse. Her er det rett og slett for mange ulike faktorer som spiller inn. Mange av faktorene påvirker dessuten hverandre, og noen ganger har vi så mye dynamikk at analysen lett blir utdatert før vi får satt løsningen ut i live. Vi har ikke lenger en brukbar kausalitet hvilket innebærer at vi må forsøke det beste vi kan – og så kan vi finne ut i ettertid om løsningen var brukbar eller ikke.

 

Snowden har funnet at det ordnede området egentlig består av to ulike domener: Det Opplagte og det Kompliserte. Begge er såpass enkle at vi kan finne de vesentligste årsak-virkning sammenhengene, men de er også ulike av natur. De opplagte problemene er deterministiske, repeterbare og har løsninger som er allment kjente. Løsningene er ikke engang avhengige av konteksten – “det bare er sånn”. Én og bare én løsning. Her gir uttrykket “beste praksis” mening. De Kompliserte problemene finner vi en løsning på ved å tilkalle eksperter på området og be de analysere. Det vil her finnes flere mulige løsninger, så vi må vurdere alternativer opp mot hverandre og fatte beslutning. Her finnes altså en klar relasjon mellom årsak og virkning, men de kan være separert av tid. Hvilken løsning som er best vil avhenge av konteksten. Her finnes ingen beste praksis, siden vi har en sterk kontekstavhengighet. Men vi kan operere med “god praksis”.

 

Det uordede området deles også i to ulike domener. Det Komplekse domenet kjennetegnes ved at vi kan finne relasjonen mellom årsak og virkning, men kun i ettertid. Her har vi en grad av stabilitet, men den vil være flyktig. Uansett hvor grundig og dypt vi analyserer blir vi aldri sikre på at vi finner en god løsning.

Vi må allikevel operere i dette domenet, hvilket betyr at vi må bruke vårt beste faglige skjønn og utføre eksperimenter som vi evaluerer i etterkant. Har vi styrket, eller svekket antagelsene våre? Dette kan vi resonnere rundt, umiddelbart etter at resultatet foreligger. Vi må her gi slipp på den sterke kontrollen. Vi kan her se etter mønstre og vokse frem en bedre og bedre praksis, dvs vi beveger oss over i det Kompliserte domenet.

I det Kaotiske området råder fullstendig ustabilitet. Ingen ting synes å være forutsigbart. Allikevel må vi handle – og vi har alltid svært dårlig tid. Intuisjon, skjønn, magefølelse vil være styrende for hva vi foretar oss. Resonnementer rundt årsak og virkning er meningsløse. Hver situasjon er per definisjon ny, og vi må finne ny praksis hver gang. Bemerk at dette er en transisjonstilstand; Det er svært vanskelig å forbli i kaos over lang tid.

Snowden har i tillegg definert et femte domene – Disorder – som han gjerne plasserer midt i mordellen. Vi kan kalle dette Forvirret på norsk. Dette er domenet du havner i om du ikke klarer å bestemme i hvilket domene du egentlig er. Og ikke minst, om du innbiller deg at du er i feil domene. I følge Snowden er dette den mest vanlige tilstanden…

Problemløsning i de ulike domenene

Det er først og fremst kausaliteten som skiller de 4 domenene fra hverandre. Dette gir at vi trenger 4 ulike fremgangsmåter for å fatte beslutninger:

• Opplagte problemer: Forstå, deretter kategorisere problemet, så respondere i henhold til kategorien
• Kompliserte problemer: Forstå, deretter analysere og velge løsning, så respondere
• Komplekse problemer: Utføre et eksperiment, analysere og forstå resultatet, så respondere (forkaste eller beholde)
• Katotiske problemer: Gå til umiddelbar aksjon, forsøk å forstå om det hjelper, responder ved å justere handlingene.

Implikasjoner på styring og ledelse

Hvordan innvirker dette på ledelse og lederrollen? Igjen får vi 4 ulike løsninger:

• Opplagte problemer: Utarbeide klare prosedyrer og rollebeskrivelser. Sørge for at vi finner og benytter beste praksis. Kommunisere klart og tydelig til medarbeiderne. Motivere med belønning for vel utført arbeid. Automatiser!
• Kompliserte problemer: Sørge for tilgjengelighet av ekspertise. Lytte til ekspertene. Fatte beslutninger basert på analyser. Styre basert på rapportering.
• Komplekse problemer: Fokusere på verdier og visjoner. Kommunisere retning, uten å bli for detaljert. Innføre feiltrygghet, slik at vi kan feile uten for store konsekvenser. Gi stor grad av myndighet til de som gjør jobben. Optimaliser på mellommenneskelig, tverfaglig kommunikasjon. Sørg for å ha slakk. Sørg for rask, ekte feedback ved å monitorere endringene. Oppfordre til konflikt.
• Katotiske problemer: Gi klare tydelige ordre. Deleger myndighet til de som er midt oppe i situasjonen. Fatt raske, tydelige beslutninger.

Det er selvsagt på dette området Cynefin virkelig vil være verdifull. Det er jo fremdeles slik at faget ledelse defineres og læres bort uten å ta hensyn til disse domenene. I stedet predikes “one-size-fits-all” der man oppfordres til å finne den ultimate organisasjonen og styringssystemet. Vi ser det overalt, i privat som i offentlig sektor – det er reglene, prosedyrene, stillingsintruksene og målingene som regjerer – som om vi alltid hadde orden. Vi gjør grundige analyser, legger store, detaljerte planer og oppfører oss som om vi hadde orden og kontroll. Vi må snart innse at vi ikke alltid har orden, og at dette på mange måter er et tilbakelagt stadium.

Dette er jo dårlige nyheter for de som har bygget hele sin karriære på å best mulig håndtere Orden.

Et synlig bevis på at kompleksitet ikke er særlig godt forstått for tiden kan vi se på utbredelsen av PRINCE2. PRINCE er et akronym for “PRojects IN Controlled Environments”. Dette er med andre ord laget for det Ordnede (kontrollerte) domenet. Allikevel benyttes dette for styring av programvareprosjekter som i stor grad befinner seg i det Komplekse området. IT-bransjen sender horder av medarbeidere på slike kurs for tiden.

Dynamikken i systemer

Dette er et “sense-making framework”, men brukes for ofte (til Snowdens store fortvilelse) som en ren 2×2 kategoriserings-matrise. Nei her er det dynamikk og vi vil typisk vandre rundt i modellen, avhengig av hvordan vi innretter oss. Snowden gjør et poeng av at vi i vår tidsalder bør instille oss på å være i det komplekse hjørnet en hel del. Vi vil måtte regne med flyktige dykk ned i Kaos, og det er helt OK så lenge vi er klar over det. Og i dagens  kunnskapsorganisasjoner vil vi ofte osillere mellom Komplekst og Komplisert. Vi trenger å ha en grad av uorden for å finne de virkelig gode løsningene på dagens svært komplekse virkelighet. Samtidig er vi tjent med å jobbe med en grad av orden når vi vet hva vi skal gjøre og hvordan.

Det Opplagte hjørnet er for arbeid som skal dø. Det er dette som skal automatiseres eller outsources. Det er ikke her vi skal være gode i Norge!

Det er intessant å merke seg at Snowden mener at Scrum utført riktig vil fremme denne stadige runddansen mellom Komplekst og Komplisert.

 

Oppsummert modell

Referanser:

A Leaders Framework for Decision Making av David Snowden og Mary J. Boone

Cynefin 101 – an introduction av  Greg Brougham

Diverse blogposter på Congitive Edge taget Cynefin

 

 

 

Fortsatt god sommer!

Fellesferien slutter i disse dager og de fleste er gradvis på vei tilbake på jobb. Men det betyr ikke at det er full rulle ennå. Alle er delvis i feriemodus og hverken sjefen eller kundene har begynt å mase. Nå gjelder det å utnytte det litt bedagelige tempoet i kontorlandskapet til litt faglig påfyll. Ikke vær redd for å bruke arbeidstiden på å lese bøker, blogger og presentasjoner. Selv liker jeg å se videoer.

Ett tema som har opptatt meg (og mange med meg) den siste tiden er hvordan smidig fungerer i store organisasjoner. Er det mulig å skalere opp en smidig arbeidsform, en smidig kultur? Er det ønskelig? Dette temaet er jo relevant både for privat og offentlig sektor. Her kommer et lite knippe med presentasjoner som addresserer dette temaet – på ulike måter. Til sammen 3,5 time – det har du sikkert tid til 🙂

Først ut er Dan North, en jeg forsøker å følge ganske tett. Dan representerer på mange måter “advanced agile” og han er mannen bak Behaviour Driven Development (BDD) Se presentasjonen

Why Agile Doesn´t Scale (and what you can do about it) – 56 minutter

Og så må vi innom Spotify. De er et virkelig fasinerende selskap – de vokser hurtig, tar Lean og Agile på alvor og de publiserer bra saker på løpende bånd. Se for eksempel presentasjonen

How Agile Coaches Help Us Win—the Agile Coach Role at Spotify av Brendan Marsh and Kristian Lindwall. 40 minutter

Og om du ikke har gjort det ennå, se den herlige animasjonen

Spotify Engineering Culture (part 1) laget av Henrik Kniberg. 13 minutter

Det lages gode presentasjoner her på berget også. Hvorfor ikke se  Jon Kåre Stene sin Keynote på Smidig 2012, som på ingen måte er utdatert.

End of Big – Hva nå? – 50 minutter

Og så har vi en annen Norsk favoritt, nemlig Bjarte Bogsnes fra Statoil som 3 juni i år snakket om

Smidig virksomhetsstyring – 50 minutter

Alle som er oppatt av storskala IKT-utvikling og innovasjon i offentlig sektor bør unne seg noen minutter med Mette Gjertsen og Statens Pensjonskasse hentet fra det samme seminaret den 3 juni:

Verdi synliggjort i produktkø – 20 minutter

NB:Alle foredragene fra seminaret 3 juni, samt paneldebatten finner du i Vimeo under Smidig digitalisering av offentlig sektor.

 

 

Smidig digitalisering av offentlig forvaltning – video og slides.

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

 

• En Smidigblogg av

  Lean Venture

• Ressurser

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

• Temaer

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

• Siste kommentarer

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

• Arkiv

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