Jeg blir ofte spurt av mine klienter hvor fort kan man forvente synlige endringer når man jobber med organisasjonstransformasjon. La oss se på skissen under som jeg ofte tegner som svar på dette spørsmålet. Samme logikken gjelder når man har gått på kurs og lært noe nytt.

Vi starter med akser horisontalt har vi tid, og vertikalt kunnskaps adopsjonsnivå. Så ser vi på kurven fra venstre til høyre.
Læringskurve

Steg 1.

Man starter å lære noe nytt, går på kurs, leser en engasjerende bok,  starter med kulturendringer eller større transformasjonsprogram. Herfra går kurven oppover, mennesker liker å lære nye ting, liker mestringsfølelsen og liker å være blant likkesinnede.

Steg 2.

Her er vi ferdig med kurs eller opplæringsprogrammet, og har passert kick-off stadiet til kulturendringsprosjektet, osv. Vi er fulle av optimismen, tror at alle rundt oss deler samme følelse og at alle vil begynne å bruke den nye kunnskapen.

Steg 3.

Her møter vi sannheten. Vi oppdager at de fleste rundt oss gir blaffen i kulturendringsinitiativet, kurset du var på og kunnskappen du fikk. Folk bryr seg ikke, de har sine egne mål, kpi-er og er veldig lite opptatt av enda en bølge med endringer. Når du ser slike reaksjoner begynner din egen optimisme å senke og ofte når vi kommer til nullpunktet stopper det der. Lufta går ut av ballongen, initiativet dør og det skjer ingen endringer. Noen få som vet hvordan beholde momentum fortsetter forbi nullpunket og ender opp i minus.

Steg 4.

Det har blitt verre enn det var før vi startet med endringer! Ja, og verre blir det. Grunnen til det er at selv om du har skjønt alt riktig og begynner å implementere og ta i bruk din nye kunnskap, så må du ødelegge det gamle systemet først. Du kan ikke innføre nye regler, lage nye system, osv før du har blitt kvitt all det gamle. Gamle vaner må læres bort, status quo må utfordres, vi må dyppe våre tær i kaos.

Steg 5.

Nå er alt det gamle borte og tilstanden er en god del verre enn før vi har begynt med alle endringene. Om dere ikke hade kastet håndkle i nullpunktet mellom steg 3 og 4 er sansynligheten stor at dere gjør dette nå. Flere interne vil merke den dårlige tilstanden vi er i og legge skylda på den nye prosessen/ kunnskapen/ kulturen. De vil si at det er det nye som har brakt med seg alt det negative. Veldig få forstår at vi hadde dette hele tiden, og at den nye kunnskapen har kun brakt det til overflaten og gjort alt dette synlig. Her bruker man ofte “shoot the messenger” prinsippen og forlater initiativet (like før man skulle begynne å se resultater).

Steg 6.

Her begynner vi å bygge det nye fundamentet, bruke den nye kunnskapen aktivt og lykkes med det. Ja, det begynner å endelig gå oppover (men den generelle tilstanden er fortsatt dårligere enn det var før vi startet med endringene). Her er det viktig å bruke de gode eksempler som vi begynner å se og gjøre dem mere synlig i organisasjonen. Trekke de frem, promotere og vise til alle.

Steg 7.

Her begynner den nye kunnskapen å virkelig bære frukt. Organisasjonskulturen er endret og begynner å forsterkes fra dag til dag av flere interne følgere. Vi begynner å bruke det intuitivt, uten å tenke, og slik gjør folk flest i organisasjonen.

Hvorfor trenger vi deg?

Noen kunder spør om kurven blir annerledes når de engasjerer en organisasjons coach som meg. De sier at de er villige til å betale om de slipper å ta steg 4,5,6. Man ønsker ikke å dykke ned i det negative, man vil ikke at ting skal bli verre enn de hadde vært. Spesielt når vi kommer til en organisasjon i krise, bunnlinja har vært i rødt i fjor og i år må de vise forbedring. Om man starter med endringene og følger kurven, kan det godt hende at man kommer enda dypere ned i rødt på slutten av året. Da ønsker man gjerne å betale for en coach for å unngå den deleLæringskurve med organisasjons coachn av kurven.

Som dere kanskje mistenker kan ikke jeg gi disse kundene det de øsnker. Jeg kan ikke gi dem en annen kurve for slik er alle endringene. Man må først ødelegge dagens status quo for så å bygge nye rutiner, systemer, kultur, osv. Ved å engasjere en organisasjons coach vil man kanskje forkorte den tiden og man kommer kanskje til å dykke ikke så dypt ned som på egen hånd, men ned skal man uansett. Man får den grønne kurva istedenfor den sorte. og det kommer til å ta tid!

Hvor lenge?

Tiden er avhengig av en hel rekke spørsmål.

Hvor stor organisasjonen er, skal vi innføre endringer i et team eller i en stor organisasjon med flere tusen ansatte på flere kontinenter? Hvor mye bagasje har vi? Hvor store endringene blir det sammenlignet med dagens praksis? Forstår alle hvor viktig det er å få endringene gjennomført? Og mange fler.

Men jeg vet at dere øsnker et konkret svar. Hvor fort kan vi forvente synlige endringer når vi jobber med organisasjonstransformasjon? Jeg kan gi dere erfaringstall og gjerne som et spenn ikke som et absolutt tall.

Selv små endringer i et enkelt team pleier å ta minst 2-3 måneder. I en organisasjon med noen hundre ansatte en viktig kulturendring kan ta alt fra 6 måneder til 1 år. Og større organisasjoner ser på dette som en evig prosess, med synlige endringer etter 1 år og lengre.

Lykke til med deres endringer!

Ja, nå har jeg sagt det.

Jeg øsnker at de fleste IT-prosjekter dør. Mer enn det, jeg ønsker at de skulle aldri bli født. Jeg ønsker at selve begrepet prosjekt brukt i utvikling av programvare sammenheng dødde og ble borte akkurat som dinasaurer dødde for mange millioner år tilbake og at mine barnebarn smilte når de hørte ordene IT-prosjekt og lurte på om de var virkelig (prosjekter altså) eller kun i bestefars fantasi-historier.

Hvorfor er jeg så negativ mot prosjekter?

Definisjon av prosjektet ifølge PMBOK: Et prosjekt er en tidsavgrenset bestrebelse for å skape et unikt produkt eller en tjeneste.

Jeg har flere spørsmål i forbindelse med denne definisjon.

  • Hvorfor skal teamet være temporær?
  • Hvorfor skal vi bygge temporær organisasjon (prosjekt team), som skal bygge et produkt, slutte å eksistere og overlevere produktet til andre folk (linja) som ser dette produktet for første gang?

Om vi skal prøve å tenke logisk så virker det naturlig at de som hadde laget produktet burde også ta hånd av support. Det å overlevere produktet til noen andre “Her er det, vær så god, dere kan fikse det” virker ulogisk. Det er også ulogisk å bryte ned et effektivt team. Team medlemmer hadde brukt masse tid for å bli kjent med hverandre, etablere internkommunikasjonsprosesser, så kommer vi og ødelegger alt dette og flytter alle til nye (ikke effektive team, ikke enda) hvor alle må bruke like mye tid igjen for å kanskje bli til et bra team igjen.

Produktet som vi hadde lagd i prosjektet dør heller ikke når prosjektet er ferdig. Den var bygd for å leve, for å bli forbedret, feilene skal fikses og ny funksjonalitet må lages osv. Man finner neppe bedre kandidater for å gjøre all den jobben enn de som lagde produktet oprinnelig. Logikken tilsier det.

Tenk for et øyeblikk, blant alle prosjekter som er i gang i deres organisasjon, hvor mange av dem egentlig er produkter? Ut ifra min erfaring av alt vi gjør i IT-organisasjoner i dag er det altfor liten del som kan bli kalt prosjekt, stort sett så snakker vi om produkter. Og når du først har definert noe som produkt (i motsetning til prosjekt), så kan vi løse enda et hodebry til ledere, nemlig ressursallokering. For har du et produkt så kan du med hånda på hjertet dedikere et produkt team som skal jobbe med dette produktet over 2-3 år og føle eirskap og ansvar for sine valg.

Det ville vært flott å kunne unngå feil bruk av ordet prosjekt, men jeg er redd at dette toget allerede er gått. Samtidlig så betyr det mindre hvilke ord vi bruker, og det betyr mer hva vi gjør og basert på hvilket sett av verdier. Og de verdiene som prosjekter bringer med dem er ikke de verdiene som jeg ønsker å promotere og ønske velkommen i fremtiden, derfor ønsker jeg å understrekke denne overgang på en eller annen måte.

Hva synes dere om prosjekter? Skriv gjerne i kommentarer.

Møte

Dårlig møtekultur er noe av det første som krever rask behandling i mange organisasjoner hvor jeg jobber som coach. Bilde over demonstrerer godt hva jeg mener og i dag tenkte jeg å dele med dere hva er det vi trenger for at våre møter blir gjort om til effektive og produktive.

Her er et minimum sett som jeg lærte fra Anders Skoe for mange år siden:

  • Hensikt
  • Ønsket resultat
  • Agenda
  • Fasilitator
  • Handlingsplan

La oss dykke ned i detaljer.

Om du gir prosessen et navn styrer du denne. Hvis ikke styrer den deg.

Hensikt (Hvorfor skal vi ha møte?)

Ingen hensikt – ingen vits i å ha møte! Hensikten har gjerne noe med en mulighet og/eller en utilfredstillende situasjon å gjøre. Vi trenger hensikt for å forberede og motivere deltagerne. Dette punktet er ofte det eneste som man greier å få med når man kaller for møte i mange organisasjoner i dag, så stopper det.

Ønsket resultat

Her begynner vi å være konkrete. Forestill deg at møtet er ferdig. Hva har vi oppnådd? Hva kan vi ta med oss? Typisk snakker vi om 3-5 helt presise, konkrete og detaljerte punkter.

Her har vi dårlige eksempler:

  • Diskutere strategisk planlegging
  • Se på strategien for Q2
  • Informere salgsavdeling om månedsresultater
  • Skaffe forankring hos ledelse angående prosjekt X

Og her er de gode:

  • Løsning på problem  Y
  • En liste med alle mulige neste steg fra nåværende situasjon
  • En prioritert liste med top 5 handlinger for å nå våre mål
  • Signert avtale

Agenda

Vi trenger Agenda slik at tiden i møtet blir brukt fornuftig og at vi oppnår våre resultater på en effektiv måte. Agendaen viser hvordan tiden benyttes under møtet helst detaljert helt ned på minutter. Det er viktig å vite hvordan en sak skal behandles og hvor lang tid som er avsatt til den enkelte sak. Vi må kunne se hvordan vi kommer frem til Ønskede resultater ut fra Agenda.

Vi skriver dette i fire kolonner: Hva, Hvordan, Hvem, Når (fra-til).

Fasilitator

Dette er en person (helst med kunnskap og erfaring) som er hovedansvarlig for prosess. Fasilitator legger forholdene til rette slik at gruppen kan være effektiv. Det er viktig å skille prosess og innhold, fasilitatoren er kun ansvarlig for prosess (holder deltagerne til agenda og gjeldende spilleregler, aktiverer de som sitter stille, parkerer de som snakker mye, holder tid og avstemninger, osv). Uten å bidra med innhold kan fasilitator være nøytral mot alle deltagerne, noe som hjelper gruppen å forbli konstruktiv når temperaturen i møtet stiger.

Fasilitator kan også:

  • fokusere gruppens energi på oppgaven som skal løses
  • ser at alle deltar aktivt i diskusjoner
  • er en slags møte sjåfør
  • stiller masse spørsmål
  • minner deltagerne om ønsket resultat og prosessen mot denne
  • motiverer
  • bidrar ikke med egne meninger
  • hjelper referenten (den som noterer) å registrere alle uttallelser ordrett (kjempe viktig!)

Handlingsplan

Handlingsplan henges opp fra starten av og har ofte disse kolonner: Hva, Hvem, Når. Saker føres på (uten nødvendigvis å sette navn på personer og dato) i løpet av møtet. Ved møteslutt påføres det navn og dato helst når frivillige tar ansvar for hvert punkt.

Sikre minimum

Om du greier å sikre dette som et minimum for hvert møte som skal skje i din organisasjon allerede om 2 uker kan jeg garantere dere en helt annen stemning i møtene. Dette er selvfølgelig ikke alt, men du må starte med noe. Ønsker du å gå helt ned i dybden er du velkommen på mitt kurs om “Effektive møter” hvor vi lærer møte-kunsten og ikke minst praktiserer det i trygge omgivelser.

I dag ønsker jeg å se på et annet konsept som jeg bruker mye i mitt arbeid verden rundt nemlig kompleksistetsteori. Kompleksitetsteori er relativt ny vitenskap og brukes i filosofi, biologi, kybernetikk, ledelse, mm og vi skal spesifikt se på Cynefin rammeverk til Dave Snowden.

De som vil se oppfinneren selv snakke om sin ide kan sjekke den 8 minutters lang video:

Mens vi skal gå litt mer i dybden men før vi gjør det trenger vi et par definisjoner om hva er et system og hva er en agent:

Et system er et hvilket som helst nettverk hvor det finnes noe samordning. Systemet kan være ganske udefinert, den kan ha og ikke ha mål.
Agent er hva som helst som fungerer inne i et system. Dette kan være et menneske, gruppe mennesker, en ide, en regel, osv.

Verden vi lever i er altfor variert. Om vi skal se på alt vi gjør gjennom dagen kan vi fort oppdage 3 typer systemer rundt oss:

Cynefin

  • Ordnede systemer: i dette tilfellet begrenser systemet sine egne agenter, systemet er bygd på forenklinger og regler, den er deterministisk og uavhengig av observatør.
    Eksempel: tenk på produksjonsprosessen av spikre, et hær eller et fengsel.
  • Kaotiske systemer: systemet begrenser ikke sine agenter disse er uavhengige av hverandre.
    Eksaempel: tenk på et bygg som er nettopp blitt truffet av en bombe, hva som flyr hvor og hvor det kommer til å lande er umulig å forutsi.
  • Komplekse systemer: systemer som lett begrenser sine agenter, hvor agentene endres over tid og hvor de også påvirker og endrer selve systemet. Alt co-evolusjonerer og endringene er irreversible.
    Eksempel: tenk på et levende organisme, økosystem eller organisasjon.

Avhengig av hvilket system opererer vi i våre handlinger burde vært veldig forskjellig. La oss se på dette i mer detalj.

Cynefin rammeverkPå tegningen over ser vi 4 domener (vi har delt ordnede systemer inn i enkle og kompliserte). La oss snakke om forskjeller i disse domener samt hvilke praktiske konsekvenser dette har på vår atferd.

Enkle ordnede systemer (høyre nedre kvadrant)

Karakteriseres av sin enkelthet, alle vekselvirkninger er opplagte for ethvert menneske, det er lett å se årsak og virkning i disse sytemer selv for et barn.
Alle avhengigheter er åpenbare.
Om du skal operere i dette området bruker du følgende mønster: Føl – Kategoriser – Responder.

Har du kjøpt en ikea-stol legger du alle delene på gulvet og ser hva du har (føl), legger 4 ben, 4 skruer og en plate sammen (kategoriser) og setter det hele sammen i henhold til bruksanvisning (responder).

I disse systemer kan vi snakke om Best praksis, og det er mulig å finne en riktig løsning for å oppnå resultat. Det finnes en optimal prosess for å samle stolen og om du avviker fra denne taper du effektivitet.

Kompliserte ordnede systemer (høyre øvre kvadrant)

Systemet er fortsatt ordnet, det finnes årsak og virkning som er ikke så åpenbare lenger. I hvert fall ikke for alle mennesker. Dette er systemer hvor vi hører på ekspertene. Om man har nok kunnskap kan du fortsatt finne ut hvordan ting henger sammen.

Handlingsmønster i slike systemer er: Føl – Analyser – Responder.

Har du fått motorstopp på bilen din og ikke jobber som bilmekanikker er det ikke sikkert at du finner ut av det på egen hånd. En bilmekanikker vil sjekke visse ting (føl), prøve å tenke hva kan være årsaken basert på symptomene han ser (analyser) og begynne reparasjon (responder).

I dette området finnes fortsatt riktig svar, dog det kan være flere av dem. Spør to eksperter hvordan skal vi oppnå resultat så skal du kanskje få to helt forskjellige svar og hver av ekspertene vil prøve å overbevise at hans løsning er best. Det er fullt mulig at begge løsningene er like gode. I denne domene forsvinner best praksis og vi har Gode praksis.

Komplekse systemer (vensre høyre kvadrant)

Disse systemer kjennetegnes av veldig rotete og innviklede forbindelser mellom agentene, samt har så mange av disse agenter at det er umulig å finne frem i det.  Det er årsak og virkning, men det er ikke mulig å forstå seg på disse og se hva som kommer til å skje om man påvirker systemet (i hvert fall ikke på forhånd). To helt like påvirkninger kan gi to helt forskjellige resultat. Du har nok fakta i slike systemer for å bevise forskjellige og ofte motstridende teorier. Den minste påvirkning på systemet kan gi enorme konsekvenser (butterfly effect).

Handlingsmønster i slike systemer: Prøv – Føl – Responder

Med andre ord når vi opererer i slike systemer bygger vi masse hypoteser og så begynner å eksperimentere for å bekrefte eller avkrefte disse hypotesene. For hvert synspunkt eller teori lager vi et eller et sett av eksperimenter som ikke nødvendigvis skal ende opp med suksses men gir oss mer innsykt og forståelse av situasjonen. Vi kan starte flere eksperimenter i parallell (fordi det uansett ikke er mulig å finne ut hvilken av disse som har gitt effekt) og vi kan teste motsigende teorier.

I denne domene har vi ikke beste eller gode praksis. Det vi gjør vokser frem basert på våre eksperimenter og vi kaller disse Fremvoksende praksis.

Kaotiske systemer (venstre nedre kvadrant)

Kaos er ikke en permanent tilstand. Total kaos i naturen eksisterer kun brøkdeler av sekunder og kun som en overgansgs tilstand. I det øyeblikket bomben traff bygget var det total kaos, men 5 minutter etterpå har systemet blitt stabilt (ruiner, rester, osv alt har funnet sitt plass) .

I kaos finnes det ingen årsak-virkning sammenhenger. Ingenting er klart. Man kan ikke trekke noen konklusjoner.

Handlingsmønster for kaotiske systemer: Gjør – Føl – Responder

Det viktigste i kaos er å gjøre noe noe som vil føre til stabilitet i systemet. Så lenge vi vil være i kaos  blir det vanskelig å oppnå resultater. Kaos er ofte det stedet som fører til innovasjon. Kriser og innovasjon går ofte sammen. Det er flere måter å komme seg ut av kaos du kan inntrodusere rigide regler inn i systemet og omstille det til et enkelt ordnet system, du kan begynne å innføre lette begrensninger og begynne med eksperimenter som vil gradvis redusere turbulens og flytte systemet i det komplekse domene, osv.

Praksis i kaotiske systemer vil ofte være ny og oppfunnet der og da.

Nå kan du ta en ny titt på verden rundt deg gjennom den nye kunnskapen. Hva slags ting, prosjekter, aktiviteter rundt deg faller inn under hvilken domene? Hva slags systemer kan du se rundt? Ikke prøv å kategorisere alle prosesser inn i disse fire områder. Husk at under forskjellige omstendigheter og med forskjellig kontekst  en og samme prosess kan være i alle fire domener samtidlig. Og en og samme prosess kan gli fra en domene til en annen over tid. Dette er ikke en kategoriserings modell, men en modell som tillater oss å forstå seg på verden litt mer.

Litt om sølv-kuler

Baser på alt ovennevnte kan vi snakke litt om sølv kuler eksisterer. Og snakker vi om prosjekter (selv om prosjekter må dø, men dette blir et annet bloginnlegg om) så kan man bruke det vi nettopp har lært for å velge hvordan vi skal angripe det.

Nede til høyre i et enkelt og ordnet domene kan du trygt bruke fossefall. Fossefal her er faktisk det mest effektive verktøy. Du har hele prosessen din beskrevet og basert på best praksis. Om du bruker noe annet enn fossefall i lignende sistemer sløser du med ressurser og tid for å finne opp hjullet på nytt.

Oppe til høyre glir du inn i ekspertens verden. Her har vi prosjektledelse med PMI, Prince2 og lignende tilnærminger. Ønsker du å bygge en bro kan du fortsatt spørre ingeniører, bruke deres mangeårige erfaringer og få bra resultat.

Oppe til venstre er du bedre tjent med scrum som rammeverk. Den vil gi deg sjansen for å eksperimentere inne i sprinter, bekrefte og avkrefte deres hypoteser og endre retning fort basert på eksperimenter i forrige sprint.

Nede til venstre kan du bruke hva du vil. Du kan invitere en diktator som får din organisasjon til å følge en enkel og ordnet prosess. Du kan kalle inn dine beste eksperter og stole på det de bestemmer å gjøre, ellers så kan du begynne med små eksperimenter som kanskje etterhvert vil flytte systemet inn i det komplekse domene.

I forskjellige situasjoner trenger vi forskjellige instrumenter og det å bruke scrum overalt er like dumt som å gjøre alt med fossefall.

Jeg blir ofte spurt av mine kursdeltagere og ledere jeg jobber med hvor kunne de henvist sine kollegaer om de vil lese mer om ansvar på norsk. Dette tema er veldig aktuelt og vi går gjennom det i detalj på de fleste av mine kurs. Jeg snakker ofte på konferanser om dette men nå, men jeg er på vei fra en kunde i Hong Kong har jeg nåk tid for å belyse hvordan fungerer ansvarsprosessen i hodene våre.

For flere hundre år hadde vi mennesker lært om hvordan vi kan unngå ansvar. Denne prosessen er polert i oss av evolusjon. Det er akkuratt samme prosess for enhver av oss, den er helt automatisk, bygd inn i vår underbevissthet slik at mange merker ikke en gang når dette skjer. La oss studere nærmere hva som skjer i våre hoder i det øyeblikket noe galt skjer. Legg merke til at størrelsen på problemet betyr ingenting. Det kan være at du klarer ikke å finne bilnøklene på morgen aller at du hadde sløset vekk pensjonsfondet til hele nasjonen. Prosessen med ansvarsunngåelse vil være akuratt den samme.

Tenk hva som skjer i ditt eget hode når du har et problem, forstår at du kan være årsaken til det men vil ikke ta ansvar for det. Foreslår at du bruker 2 minutter på å reflektere litt over en slik situasjon. Hva blir du fortalt av din egen hjerne? Hvordan kan du unngå ansvar?

ansvarEn av de første reaksjonene som dukker opp er å ignorere problemet. Her er noen eksempler:

  • Du knuser et glass i kantina, ser deg rundt, forstår at ingen har sett deg gjøre det, og stikker av gårdet.
  • En politikker vil ofte si: “Vi har ikke dette problemet”
  • En programmerer kan si “dette er ikke en feil, funksjonen er beskrevet slik i spesifikasjonen”

Med andre ord om du kan snu ryggen til problemet og late som ingenting har skjedd og andre rundt deg kjøper dette så har du løst problemet og unngått ansvar.

En annen mulig reaksjon er å skylde på andre. Om vi ser på eksemplene over kan man si at glasset var knust av en katt som hoppet på bordet, politikkeren vil klage på opposisjonen, mens programmereren vil legge skylda på arkitekten eller business analytikeren. Legger du skylda på andre unngår du også ansvar.

Hjernen kan by på flere løsninger for å unngå ansvar. Man kan for eksempel finne en fin forklaring og rettferdiggjøre situasjonen. Glasset hadde allerede en sprekk, og bordet den stod på hadde dårlig ben. Jeg trenger ikke å gi dere eksempler når politikkerne rettferdiggjør problemene, det er nok å slå på tv og høre hvilken som helst tale rundt brennende tema. Programmeren sier at koden hvor feilen var funnet er stygg og var dårlig skrevet fra før av, derfor var det ikke mulig å forstå seg på den og dette førte til at man gjorde en feil.

Enda en måte å unngå ansvar på er å føle skam. Man kan si: “Beklager slik vil ikke gjenta seg” og alle rundt deg vil fort glemme det som har skjedd. Mer en det, slik ansvarsunngåelse er almenakseptert i samfunnet vårt. Se hva som skjer i et møterom i et stort selskap hvor alle ledere er samlet for å invistigere en vanskelig situasjon hvor selskapet tapte sin viktigste kunden. Alle sitter og ser ned i bordet, ingen løfter blikket. Den store sjefen ser seg rundt på alle deltagere. Det er så stille at man kan høre hvordan en flue flyr gjennom rommet. Plutselig så står Iversen opp og snakker: “Beklager, dette hadde vart en feil av min avdeling, jeg er veldig lei meg, dette vil ikke skje igjen”. Du kan se hvordan folk puster lettet ut, løfter hodene og skuldre. Sjefen er også blitt mildere og man kan høre fra kollegaer rundt bordet: “Ja-ja /klapp på skulder/, slik skjer alle”.  Tilgivelse ar gitt. Iversen hadde unngått ansvar. Hvorfor unngått? Jo, fordi problemet er fortsatt der. Det har skjedd ingen handling og møtedeltagerne hadde vært delaktige i det å unngå ansvar. Istedenfor skulle man sagt “Iversen du kan sitte ned, vi trenger ikke å finne en å skylde på, vi har et problem og må finne en løsning hva som skal gjøres med det”.

Hjernen din har enda et argument om det ikke er nok med de som er nevt over. Nemlig fortelle at dette var en plikt. Du vil høre fraser som “Jeg måtte gjøre det”, “Om du ville vært meg ville du gjort akuratt det samme”, “Jeg var malt inn i et hjørne”, “Dette var det eneste riktige i den situasjon”, “Jeg hadde ingen andre valg”. Dessverre så er dette ansvarsunngåelse dette også. Valg er et annet tema som jeg vil belyse i et annet bloginnlegg, for oss nå er det viktig å forstå at når en sier at man handlet fordi man må så unngår en ansvar.

Husk at dette er ikke en linjeær modell hvor du først nekter, så skylder på andre så beveger deg oppover. Nei, hjernen din vil analysere situasjonen raskt, velge det som passer best for å unngå ansvar og tilby deg dette som et svar. Kjøper du dette, unngår du ansvar. Sier du nei til forslaget fra ditt underbevissthet får du sjansen til å gjøre noe med problemet.

Du har nettopp lært om ansvarsprosessen selv og jeg oppfordrer deg til å dele denne kunskapen med andre. Du kan laste ned pdf med ansvarsprosessen, skrive det ut og henge opp på møterommene der du jobber og lære kollegaer hva det betyr. Du kan lese mer om temaet på blogen til Christopher Avery som jeg samarbeider med. Han hadde også skrevet en veldig bra bok Teamwork is an individual skill som handler om det å jobbe i team som jeg kan varmt anbefale.

I dag vil jeg dele med dere et konkret instrument som dere kan bruke for å begynne å diskutere tverrfaglighet i deres team, nemlig Stjernekartet.

Det er ganske lett å bygge opp et stjernekart. Det dere trenger er et par timer og et koselig sted hvor hele teamet deres kan gjemme seg med flippover og produkt backlog (alt dette, med unntak av tid, er ikke nødvendig, men ønskelig. Glem også ikke om hvordan man holder møter effektivt). Et bra sted for å lage stjernekartet kan også være rommet hvor dere holder sprint planlegging eller retrospektiv.

Begynn med å lage stjernekartet

Steg 1

StjernekartetGjør produktbacklogen synlig for alle (prosjektor, skjerm eller papir) og begynn brainstorming med et åpningsspørsmål: “Hvilke kompetanser, evner og ferdigheter er nødvendige for å selv kunne lage alle elementer av vår backlog uten involvering av tredjeparter?”

Hvis vi tar webutvikling som et eksempel, kan liste se ut som:

  • xhtml
  • css
  • js
  • php
  • mysql
  • analytikk
  • tester
  • kjennskap til domeneområdet

Steg 2

Tegn en tabell hvor hver rad skal inneholde navnene til alle teammedlemmer, og hver kolonne skal inneholde kjennskap, evner og ferdigheter som akkurat ble funnet. Deretter gi tusjpenner til alle teammedlemmer.

Steg 3

Be alle teammedlemmer om å vurdere sine kjennskap, evner og ferdigheter ifølge hvert punkt ved hjelp av to enkle tegn:

  • stjerne – jeg har utmerket kjennskap til dette området slik at jeg kan lære andre;
  • punktum – jeg har noe kjennskap til dette området, men jeg vil gjerne vite og lære mer om dette;

Da har dere fått et stjernekart!

Analyser stjernekartet

Nå vet vi om våre stjerner og kan begynne med å analysere kartet. Hva bør man legge merke til først, og hvilke spørsmål bør man diskutere?

  1. Vi leter etter kolonner med stjerner som står alene. Det er det vi kaller “bussfaktor” (trikkfaktor for de som bor i Oslo) – hvor mange personer i teamet deres kan bli påkjørt av en buss/ trikken for at prosjektet/selskapet deres stopper helt. En stjerne i en kolonne betyr at bussfaktor er lik en. Hvis jeg hadde visst dette og vært daglig leder i deres selskap så ville jeg sovet ganske dårlig.
  2. Vi leter etter kolonner hvor det bare står punktumer. Disse kolonnene er interessante på grunn av at det er ganske store sjanser å ikke lykkes og produsere et lavkvalitetsprodukt. Derfor, hvis vi bare har punktumer i kolonne “databaser”, så bør vi legge merke til dette og diskutere med teamet det dere kan gjøre for å hindre en uønskelig utvikling av situasjonen. For eksempel kan dere vurdere å innføre ekstern kontroll av koden av en spesialist.
  3. Vi leter etter tomme kolonner. Disse utmerker seg ved at vi mangler kjennskap til dette området helt. Og dette medfører at deres team er avhengig av tredjeparter. Jeg hører allerede at “Vi har nå gjort det vi måtte gjøre, vi venter bare på… (legg til noe som passer)”. Dette skjer i tilfellet teamet glemte om ansvar. Det er veldig leit å se et godt nok team som kom inn i en slik situasjon og kan ikke gå videre.
  4. I hver kollonne vil vi, ideelt sett, ha minst ett stjerne og ett punktum. Det betyr at vi har en person som vil lære seg, og en som kan lære. Perfekt! Disse er kandidatene for parprogrammering eller for det å jobbe litt sammen. En som har satt stjerne og en som har satt punktum i samme kolonne kan gjerne diskutere planer for videreutvikling og opplæring av ”punktum” i denne retningen. Samtaler som foregår rundt stjernekartet, kan også holdes sammen med deres HR avdeling.

I mange team jeg jobber med, eksisterer det et spilleregel om at stjernen ikke har lov til å jobbe selvstendig med oppgaver fra sitt stjerneområde. Det er punktum som skal gjøre hele jobben mens stjerne skal bli en coach. Slikt hever vi nivået på våre punktumer, og slikt viderefører vi kunnskap fra medarbeider til medarbeider inne i selskapet.

Spesielt gjelder denne regelen eksterne stjerner. Hvis vi har involvert en spesialist i databaser til å jobbe i vårt team gjennom et par iterasjoner, så har han ikke lov til å jobbe selvstendig med noen av oppgaver. Det må alltid være et punktum fra vårt team som skal jobbe sammen med stjernen, og det er punktum som skal gjøre hele jobben mens stjernen skal bli en coach. Jeg vet at noen kommer til å skrike: “På denne måten vil kunde betale for at vi lærer opp våre medarbeidere noe som blir urettferdig fordi et par som “punktum-stjerne” vil jobbe mer langsomt enn stjerne alene”. Skrik om dette i kommentarer så tar vi en diskusjon på det :). Dessverre så er det den eneste måten å utvikle deres medarbeidere på og videreføre kunnskap inne i selskapet. Hvis dere har andre forslag som faktisk fungerer, skriv dem gjerne i kommentarer.

Bruk av stjernekartet

Stjernekartet kan brukes:

  • under sprintplanlegging (hvor smart er det å ta mange historier som er kompliserte i databasen inn i sprinten, hvis det bare er punktumer i teamet på dette område?)
  • under utarbeidelse av utviklingsprogram til medarbeidere (enten av HR eller linjeledelse): aktuelle spørsmål kan være “Hvilke punktumer vil du videreutvikle i år?”, “Vil du kanskje ta et kurs i dette temaet?” osv.
  • daglig for å forstå hvem du skal jobbe i par med de neste 2-3 timene
  • regelmessig (en gang i halvt år) under retrospektiver for å forstå i hvilken retning kunnskapet til teamet utvikles
  • foreslå ditt eget alternativ i kommentarer 🙂

Et spørsmål for dere som hjemmeoppgave: “Når teamet estimerer, hvem sin vurdering skal vi velge som svar? Stjerne sin elle punktum sitt?”. Du kan gjerne svare i kommentarfeltet under.