Jeg tror nøkkelen ligger i motivasjon. Man vil aldri få til dette med IT-verktøy eller incentivordninger – om ikke de ansatte er interessert i å dele. Så, hvorfor skulle noen ikke være interessert i å raust dele av sin kunnskap?

Motivert av belønninger

Det finnes et utall studier som viser at belønningssystemer virker mot sin hensikt – om oppgavene er komplekse. I IT-bransjen – og annen kunnskapsbasert virksomhet skulle jeg tro – er de fleste oppgavene komplekse. NHH-artikkelen Venter på belønning – holder tett viser nettopp dette – at om de ansatte er drevet av individuelle belønninger vi de ikke så lett dele kunnskap. Dan Piinks herlige animasjon The Surprising Truth About What Motivates Us.. sier i essensen det samme.

Passer på sin posisjon

Noen nyter stor respekt i organisasjonen fordi de har masse kunnskap. De har ikke nødvendigvis noen formell posisjon, men de blir alltid tatt med på råd og behandlet som en “guru”. Disse ser ikke nødvendigvis noen egen nytte av å være rause med kunnskapen sin. De er fornøyde med å “svare på henvendelser”.

Jobbsikring

Denne er åpenbar i de organisasjonene som har vært utsatt for flere runder med nedbemanninger. Her gjelder det å sitte på (holde på) kompetanse som ikke mange andre har. Man kan på den måten bli uunnværlig – helt til denne spesielle kunnskapen er utdatert.

Mangel på helhetssyn

Mange oragniserer seg slik at en kompleks oppgave skal løses i en lang kjede av spesieliserte oppgaver. Omtrent som i et samlebånd. Folk spesialiseres og blir veldig gode til å gjøre én delprosess. Disse vil ha lang avstand til sluttproduktet (og kunden) og det vil være vanskelig å se hvilket bidrag din jobb gir til helheten. Det er  ikke her åpenbart at kunnskapsdeling vil gi noen personlige fordeler.

Jeg er overbevist om at de som har et eierskap til helheten også vil være mest interressert i å jobbe smartere. Ikke fordi det gir dem noen ekstern belønning, men fordi de motiveres av sluttresultatet av den jobben de gjør. Eller av de menneskene som skal motta resutatet av den jobben de gjør. Det er jo nettopp dette Dan Pink viser i videoen sin. Folk som har eierskap og stolthet knyttet til sluttproduktet kan finne på å legge sjela si i å jobbe smartere. Og alle forstår at for å jobbe smartere må vi jobbe i team med gode, motiverte fagpersoner. Deling av kunnskap blir en selvsfølgelighet.

For øvrig – akkurat som foreskrevet i Scrum

Benytter her anledningen til å peke på Kunnskapstinget 2010 28 september

Wikipedia: “Wishful thinking is the formation of beliefs and making decisions according to what might be pleasing to imagine instead of by appealing to evidence, rationality or reality.”

Wikipedia: “Wishful thinking is the formation of beliefs and making decisions according to what might be pleasing to imagine instead of by appealing to evidence, rationality or reality.”

Vi danner oss meninger og vi tar viktige beslutninger basert på hva vi skulle ønske var sant i stedet for å bruke kunnskap og fornuft. Ofte er dette basert på at vi hører at noe har fungert i ett eneste tilfelle – og så tror vi at dette er en allmengyldig sannhet. Det virker som dette ofte inntreffer når denne løsningen synes å være ekstremt enkel eller fantastisk fordelaktig.

Se for eksempel på aksjemarkedet. De fleste tunge aktørene innen aksje- og valutahandel er høyt utdannede mennesker. De har alle lært at konjungturene svinger. “Inget tre vokser inn i himmelen”. “Når toppen er nådd går det stupbratt nedover”. Allikevel har vi sett gang på gang at tusenvis av disse presumtivt smarte menneskene kollektivt går i fella og lånefinansierer kjøp som bare kan gi (formidabel) gevinst om markedet fortsetter å vokse. Denne blinde troen på “evig vekst” er altså ulogisk, men gis næring av en blanding av griskhet og hang til ønsketenkning.

De virkelige ekspertene innen dette feltet er selvsagt reklamebransjen. De fleste i den vestlige verden har kunnskap om sammenhengen mellom kosthold/mosjon og vekt. Er man overvektig så må man legge om livsstilen – trene mer, spise mindre – for å få en varig endring.  Allikevel velger millioner å se bort fra denne kunnskapen og heller kjøper et preparat som reklamen lover skal gi rask vektreduksjon. Om man vil kan man finne veldig solid dokumentasjon på at raske slankekurer alltid vil feile. Men hvem ønsker egentlig å endre livsstil? Vi fornemmer at dette innebærer å gi avkall på goder samtidig som vi skal begynne å bruke tid og krefter på ting vi ikke ønsker å gjøre (som f. eks. å trene). Dessuten blir livet mer komplisert ved å skulle begynne å tenke på hva vi putter i munnen – og hvordan vi skal få satt av tid til å mosjonere? Klart folk ønsker seg enklere løsninger! Reklamebransjen vet at det er mulig å få folk til å betale godt for helt verdiløse produkter som lover raske løsninger. Bare folk i målgruppen ønsker det sterkt nok!

Et annet område som nok er svært utsatt for fenomenet ønsketenkning er religion. Har ingen planer om å utdype dette i særlig grad, men det er jo besnærende med et liv etter døden…

Hva har så dette med ledelse å gjøre? Jo, jeg tror at fenomenet også er svært utbredt hos beslutningstakere i bedriftene. Hva gjør en leder når han observerer et problem i egen organisasjon? Et litt diffust og komplekst problem der det er vanskelig å peke på noe klar årsak. I løpet av de lange diskusjonene i ledergruppa, er det en som påpeker hvor tungvindt og gammeldags datasystemet som er involvert egentlig er. Ja, det er nok sant det mumler de andre. Kanskje vi må oppgradere?  Dette er jo en løsning som fortoner seg konkret og  forholdsvis enkel. Lederne viser handlekraft og sette i gang et prosjekt for å utvikle/installere nye IT-løsninger. Men hva om det egentlig problemet ligger på et annet plan? Er det prosessene våre, eller organisasjonen vår som er feil? Er det strategigen kanskje? Dårlig arbeidsmoral? Motivasjon? Slike ting er ikke lett å jobbe med – nei da kaller vi det heller et IT-problem. (Jeg har skrevet mer om dette i lys av problemene i NAV her http://scrummaster.no/?p=369)

Ackoff: When a panacea appears to work in one or two prominent business situations, it can quickly become a fad.

Jeg tror dette kan gi oss store problemer i arbeidslivet. Vi har vondt for å forholde oss til kompleksitet. Når en organisasjon vokser merker ledelsen gradvis at man mister oversikten. Vi innser at vi ikke egentlig forstår hvordan helheten fungerer. Derfor nøyer vi oss med å forstå elementer av organisasjonen. Eller deler av totalprosessen. Vi splitter opp i mindre biter og følger opp enkeltelementene hver for seg – og så føler at vi har håndtert kompleksitet. Eller rettere sagt vi ønsker at verden er skrudd sammen på denne måten. Men dette er helt feil! Det er helheten som er viktig, ikke elementene eller delprosessene. Uansett hvor sterkt vi måtte ønske det så er det ingen vei utenom å forstå helheten! Alle organisasjoner har en egen hensikt og har egne brukere/kunder denne hensikten er myntet på. Delene av organisasjonen er bare mekanismer uten egen hensikt (sett fra brukerne).

Jeg husker fra lederutviklingskursene jeg har vært innom at det er viktig å sette seg målbare mål. Denne lærdommen – at vi kan sette oss kvantifiserte, lokale mål for å spare penger – er også et resultat av ønsketenkning – det er som kjent lettere å måle kostnader enn å måle verdiskapning. Det ville vært flott om verden fungerte på den måten, men det gjør den dessverre ikke. Det vi får er sub-optimalisering. En lokal forbedring som gir en negativ effekt på totalen. Totalen er som vi vet stor og kompleks, så det er ikke helt lett å se sammenhengen her. Årsak-virkning blir utydelig. Resepten er i stedet det Vanguard (med John Seddon i spissen) sier, nemlig at vi må over på “utenifra-og-inn tankegang”. Vi må evne å se vår egen organisasjon med kundebrillene på. Hva er det vi gjør som skaper verdi for kunden? Hva ønsker egentlig kunden forresten? Hva var det kunden ville ønsket av vi målte på? Seddon har utallige eksempler på slike tiltak som har virket mot sin hensikt. (Se bl.a. http://vimeo.com/4670102) Årsaken er at vi forsøker å forenkle ved å måle kostnader i stedet for verdiskapning og å sette lokale mål i stedet for totale mål. I arbeidslivet er det altså ingen vei utenom å forsøke å forstå kunden så godt som mulig. Og så må vi gjøre den smått ubehagelige øvelsen det er å se kritisk på egen organisasjon – med kundebrillene på. Hva er det vi gjør egentlig her som ikke skaper kundeverdi? Dette kan være ganske tungt og ubehagelig arbeid som lett vil utfordre mange eksisterende posisjoner og prosesser. Skal vi da la være å gjøre det? Bare fordi vi ønsker at verden er skrudd sammen på en enklere måte?

—

Om vi tar den desidert største gruppen først så sier tallene at det per første halvår 2010 er ca 90.000 Certified Scrum Masters. Vi ser av grafen at økningen har vært ganske jevn.

*) 2010 tallet er kun for første halvår.

At dette er mest populært i Nordamerika er neppe noen bombe. Europa er en klar nummer to her. Og når vi sier Europa mener vi egentlig nord-vest Europa. UK og Skandinavia er et klart tyngdepunkt. Tyskland kommer, det samme gjør Holland, men de Skandinaviske landene holder stand som de med høyest tetthet av CSM’er (se innlegget “vi er verdens smidigste nasjon” http://scrummaster.no/?p=240.)

Scrumalliance jobber stadig med sertifiseringsregimet. Nytt av året er at Certified Scrum Professional kommer inn i stedet for Sertified Scrum Practitioner. (Forkortelsen er fremdeles CSP:))

Les med om sertifiseringen her: http://scrumalliance.org/scrum_certification

Uansett så har jeg mer eller mindre systematisk begynt å merke meg hva som skiller de som lykkes fra de andre.  Hva er det som kjennetegner disse? Og like interessant – hva er det som kjennetegner de som mislykkes? Hva er avgjørende – er det hvordan de angriper problemet, eller er det Scrum i seg selv som ikke egner seg for alle?

Jeg har kommet fram til 5 avgjørende faktorer:
1. Ser de på Scrum som en endringsprosess?
2. Bruker de Scrum til å forbedre håndtverket?
3. Bruker de Scrum til å oppnå strategiske mål?
4. Ambisjoner og videre læring – fordyper de seg i Smidig systemutvikling?
5. Benytter de Lean tankegang?

1. Endringsprosess?

Erkjenner organisasjonen at Scrum innebærer en endringsprosess? Eller ser de på Scrum som en metodikk for gjelder for utviklingsavdelingen?
Alt for mange “driver med Scrum på IT-siden”, mens ledelsen og forretningssiden tenker tradisjonelt. Hvordan skal man da klare å dra maksimalt nytte av smidig systemutvikling? Om forretningssiden måles på antall nye features de klarer å produsere – vil de garantert mislykkes i å maksimalisere verdiskapningen for brukerne. Om ledelsen ikke er villige til å legge til rette for hyppige releaser, hvordan skal vi da klare å lage topp kvalitet? Mange av organisasjonene jeg møter mangler overordnede langsiktige målsetninger og vilje til å endre på annet enn “IT-siden”. Jeg snakket nylig med noen som hadde kjørt 35 Sprinter, men releaset kun årlig – og det forelå ingen konkrete planer om å øke release-takten…

2. Forbedre håndtverket?

Utnytter de iterasjonene til å stadig forbedre håndtverket? Utvikler de kunnskap systematisk?
Mange nøyer seg med Scrum “prosessen”. Med det mener jeg at de følger alle anbefalingene om 15 minutters morgenmøte, passe store team, faste sprintlengder, har Sprint review og retrospective osv.. Uten at de legger sjela si i retrospectivene! Er det mulig å bli skikkelig god i Scrum uten å ha en solid Definition of Done som stadig blir forbedret? Det er helt tydelig at de som blir gode er også raske til å prøve ut og adoptere ulike XP-teknikker som Parprogrammering, TDD, DDD; BDD, User Stories osv. På forretningssiden vokser det fram andre gode teknikker som Story Mapping, Pragmatic Personas etc.

3. Strategiske mål?

Har ledelsen et helhetlig syn på dette og setter seg mål for Scrum koblet til forretningsstrategien?
FINN.no har kommet virkelig langt – og jeg husker godt hvordan Scrum-innføring bare var et tiltak i et større program for å øke innovasjonsevnen. Schibsted presset på og var villige til å bruke mye krefter på dette. Når ledergruppe forstod at Scrum og Lean tankegang var skreddersydde verktøy for å oppnå de forretningsmessige målene ble det virkelig sving på sakene. Det er alt for få som har et godt svar når jeg spør ledelsen “Hvorfor Scrum?”

4. Ambisjoner om videre læring?

Ser vi en vilje/evne til å fordype seg i “Agile”?
Agile-begrepet er i stadig utvikling og det publiseres en mengde erfaringsbaserte nyvinninger i økende tempo. En ganske god indikator på evnen til å lykkes med Scrum er “læringsambisjonene”. Hvor mange leser bøker, går på konferanser og kurs, leser blogger og andre publikasjoner, deltar på diskusjonsfora eller deltar i lokale nettverk? I Osloområdet har vi er imponerende aktivt “smidig-miljø” som bidrar med små fokuserte kveldssmøter (lean meetup, XP meetup) og større konferanser. (se www.cantara.no og http://smidig2010.no/)
Begynn for eksempelt med Johannes Brodwalls utmerkede blogg:

http://johannesbrodwall.com/2010/05/02/six-ideas-that-improve-your-software-design/

5. Lean tankegang?

Benytter de Lean tankegang og prinsipper?
Dette har blitt en slags kjepphest for meg. Lean og Scrum går “hånd i hånd”. Mens Scrum er en maksimalt enkelt rammeverk, gir Lean en ledelsesfilosofi og en masse nyttige teknikker og tankemodeller som kan gi Scrum-implementasjonen en skikkelig “boost”. I hvor stor grad tenker forretningssiden “Pull” og tar brukernes behov på alvor? Jobber de for å eliminere “waste”? Ser de aktivt og systematisk etter forbedringsområder – IKKE begrenset til retrospectiv-møtene? Osv osv.. Her synes jeg å se en markant forskjell mellom de som tenker Lean og de som ikke gjør det.

Bruk disse 5 faktorene som en sjekkliste i egen organisasjon. Hvordan står det til?

Jeg får fra tid til annen spørsmål og hvordan Scrum og ITIL passer sammen – og jeg skjønner nå at jeg har tatt litt for lett på dette spørsmålet. I mitt enkle verdensbilde har ITIL representert 1. linje support – de som avgjør om Scrum teamet skal få saken eller om det kan løses av andre. Alle gode prosesser med fokus på kvalitet (som jo Scrum er) foreskriver at de som forårssaket feilen skal få den rett tilbake så fort som overhodet mulig. Kjører man korte iterasjoner (14 dager eller mindre) og leverer små inkrementer fortløpende vil dette kunne bli helt optimalt.

Jeg leste med interesse innstikket om ITIL i Computerworld for et par uker siden. En lang sammenhengende hyllest til dette rammeverket, med ett lite unntak, nemlig “universalskeptiker” Helge Skrivervik som sier Itil er gammeldags. (Han blir her kraftig marginalisert ved at journalisten gjentar “universalskeptiker” flere ganger i artikkelen.) Uansett, det Skrivervik sa var nok til å pirre nysgjerrigheten min, så jeg satt i gang med å orientere meg litt i ITIL-jungelen. Og det er en jungel med ekstremt mange aktører på kurs og tjenester. Men det var ikke så vanskelig å finne beskrivelser som gjor at en novise som meg kunne orientere meg i dette uten å måtte gå i detalj.

Den gjeldende versjonen er ITIL V3. Dette rammeverket er et gigantisk, altomfattende rammeverk for drift, vedlikehold, release, og nyutvikling. Hvor omfattende dette er kan man få et inntrykk av her og her.  Jeg har sett og brukt utallige prosessmodeller opp igjennom tidene. Vi brukte Cleanroom Software Engineering på tidlig 90-tall i Siemens Forsvarssystemer. Jeg har brukt hjemmesnekrede, detaljerte vannfallsorienterte modeller og jeg har brukt RUP. All denne erfaringen har lært meg en ting: Standardisering av arbeidsflyt er fornuftig – så lenge man ikke detaljspesifiserer og så lenge man holder seg til minimumsløsninger. Rigorøse prosesser fører enten til at man sementerer prosessen og dermed umuliggjør systematisk forbedringsarbeid eller det fører til “ulydighet” ved at man omgår prosessen for å klare å jobbe effektivt. Alle prosedyreverk bør starte med et absolutt minimum og så kan vi legge til detaljerte prosedyrer på områder som er spesielt kritisk for oss. Det er mye vanskeligere å begynne med noe stort, komplett og detaljert og så fjerne det vi ikke trenger. Jeg kaller dette på spøk Geirs første og eneste lov: “Det er 10 ganger lettere å legge til enn å trekke fra”. Helge Skrivervik har tydeligvis samme syn.

Helge Skrivervik: FFF: Forandring uten Forenkling er Forkastelig!

ITIL-prosessene er noen store mammuter, eller dinosaurer er kanskje et bedre ord. Jeg finner et 40-talls roller, en mengde store prosesskart som typisk nok blir helt uleselige når de forminskes for å passe inn i et normalt dokument eller en web-side. Jeg ga fort opp å forstå de hierarkisk oppbygde flytdiagrammene. Kan dette være nødvendig da? Det som er helt sikkert er at dette er anti Agile, anti Lean og det sikk motsatte av Systems Thinking. ITIL systematiserer jo alt de John Seddon advarer så sterkt mot.

Ikke nok med det – ITIL er først og fremst laget for å optimalisere feilhåndtering. Hvorfor skal vi det? Dette er jo i utgangspunktet Waste, eller slikt John Seddon definerer som Failure Demand.

John Seddon: Failure Demand is demand on the resources of an organization caused by its own failures.

Mary Poppendieck: Your objective is not to handle failure demand more efficiently; it is to eliminate failure.

Det slår meg at dette rimer veldig godt med god gammeldags vannfallstankegang eller “Command and Control”; Vi håndterer kompleksitet og avhengigheter ved å modellere virkeligheten. Gantt-diagrammer er et godt eksempel på dette. Tenker man Lean vil man i stedet for å modellere eller håndtere avhengigheter redusere avhengigheter. Moderne, effektive organisasjoner verdsetter innovasjon, kvalitet og fleksibilitet, nærhet til kunden og jobber med enkle, fleksible rammeverk som Scrum og Kanban.

Problem Management: Skremmende ineffektiv “handover” prosess – lang avstand til brukeren:

Hva med å kjøre en “Eliminate Waste” på denne ved å bruke Total Value Stram Maps? Ikke helt få køer og prosesstrinn der det ikke foregår mye verdiskapning – om en har på kundebrillene.

Hva lover Scrum da?

Jeg har her funnet fram en del utsagn som på en kortfattet måte beskriver lovnadene.

Tobias Mayer:
“Scrum makes one promise only: it will help you fail in thirty days or less. That’s it.  And it will begin to surface organizational dysfunction in the process.”

Hmmm. Er vi helt sikre på at det er dette vi vil..?

Ken Schwaber:
“imagine that your mother-in-law believed her daughter could do better… and then imagine that she moved in with you… that’s what Scrum is like”

Hjelp! Er Scrum virkelig så ubarmhjertig!!!??

The Scrum Guide:
“Scrum, which is grounded in empirical process control theory, employs an iterative, incremental approach to optimize predictability and control risk.”

OK, det var bedre. Forutsigbarhet og kontroll over risiko er jo bra!

Henrik Kniberg:
“Scrum in a nutshell:
* Split your organization into small, cross-functional, self-organizing teams.
* Split your work into a list of small, concrete deliverables. Assign someone to be responsible for that list and to sort the list by priority. The implementation team estimates the relative size of each item.
* Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration.
* Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
* Optimize the process by having a retrospective after each iteration.”

Greit! Så dette er et knep for å forenkle ved å dele opp organisasjonen, arbeid og tid samt å få i gang en optimaliseringssløyfe. Dette trenger vi!

Selv bruker jeg å selge Scrum ved å si at jeg har jobbet med organisasjoner som beretter om forbedringer på mange områder på en gang:
* Bedre kundetilfredshet
* Bedre trivsel
* Mer innovasjon og effektivitet i utviklingsavdelingen
* Langt bedre oversikt internt
* Bedre samhandling mellom IT og forretningssiden
Men dette er ikke lovnader om noe man kan innkassere bare man følger “oppskriften”. Alle vil selvsagt ikke kunne høste alle disse fruktene med en gang, dette kommer jo an på hvor “dårlige” man er i utgangspunktet.

Det jeg kan love er at du her får all den hjelpen du vil ha til å optimalisere prosessene dine. Men dette er hardt arbeid – som du må gjøre selv!

Management 3.0 is a silly name. We already have Web 2.0, Government 2.0, Project Management 2.0, Enterprise 2.0, and RSS 2.0. And interestingly enough, Gary Hamel’s Management 2.0 was one of the last to jump on the “2.0″ bandwagon.

Jeg leser Gary Hamel’s Management 2.0 med stor fornøyelse og spesielt artikkelen The Facebook Generation vs. the Fortune 500  gjorde meg sikker på at verden – til tross for en del motstand – er i ferd med å bli smidig. Smidig som i Agile. Og i Scrum. Så vi klarer oss helt sikkert godt uten Management 3.0 i lang tid framover. Men dette nettverket er spennende da! Og Jurgen appellerer tydeligvis til mange for i medlemslista i nettverket finner vi navn som Mike Cohn, Esther Derby og Phillippe Krutchen. Så hvorfor ikke. Jurgen holder på med boka Management 3.0: The Era of Complexity og ideen er selvsagt å få kompetente, engasjerte folk til å bidra til å gjøre boka god. Han bruker sin egen medisin her for ideen hans er at vi må begynne å se på organisasjoner som komplekse sosiale nettverk der innovasjonen får blomstre i stadig raskere tempo ved å la folk selvorganisere og å la energien og kunnskapen selv finne veien dit den skaper mest verdi.

Her er profilen min

Engasjer eder!

Noen tror dette er et problem som kan løses med IT-systemer. Men utallige erfaringer viser at IT ikke er løsningen på problemet. Ofte er selve saksgangen og organiseringen så kompleks at det nærmest er umulig å støtte alt. Her en bare en av mange artikler som forteller at IT i helsevesenet ikke løser problemet. Jeg er kanskje illojal overfor en bransje jeg selv er en del av, men i disse tilfellene står det klart for meg at IT-løsninger kan virke stikk imot sin hensikt. Ved å dreie fokus mot IT-løsninger vil man selvsagt “slippe unna” viktige diskusjoner rundt organisering for styringsfilosofi. Dessuten er det dyrt og krevende for organisasjonen å måtte forholde seg til avanserte IT-systemer i stadig utvikling.

Slik NAV er organisert i dag tror jeg man kan kaste så mye penger man bare vil inn i det systemet uten å verken få mer fornøyde brukere eller ansatte. Problemet virker systematisk og må håndteres som systemfeil. Dette er ansvarsfraskrivelse satt i system. Man må langt opp i hirarkiet for å finne ansvaret, og dermed blir avstanden alt for stor til at dette ansvaret kan utøves særlig operativt. Dette kan føre til helt håpløse tilstander der prinsipper og begrensninger fullstendig overtar for løsningsorientering. Leste akkurat på Paul Chaffeys blogg at man fremdeles sender disketter med pasientdata til fastlegene!

Heldigvis finnes det alternative modeller som fungerer – og som helt sikkert kan brukes i NAV. Felles for de aktuelle modellene er at de tar til orde for:

• Der etterspørselen ikke er konstant over tid eller geografi er det ufornuftig å standardisere saksbehandlingen
• Kompetanse må plasseres så nær kunden/brukeren som mulig
• Ansvar og myndighet må plasseres så nær kunden/brukeren som mulig
• Resultatmål som ikke er direkte koblet til brukerne gir sub-optimalisering og uønsket adferd
• Kvalitet må hele tiden være den mest styrende parameteren
• Gjennomløpstiden for saker må være kort – løs en sak om gangen i stedet for å starte mange på en gang; Jobb i tverrfaglige team.

Dette innebærer jo at hver lokale enhet må få frihet til å organisere seg slik at de treffer sine brukere best mulig. Det skal ikke mye fantasi til å forstå et brukerne på Holmlia skiller seg gaske kraftig fra de på Snarøya. Eller de i Stokmarknes. Om de ulike enhetene får dette ansvaret vil de selv finne sine egne kompetansehuller og begynne å fylle disse. Når etterspørselen av ulike grunner endrer seg vil de raskt kunne gjøre den nødvendige tilpasningene. Langt flere av de ansatte vil på denne måten få en tett kontakt med brukerne. De vil løse saker raskere og oftere oppleve den gode følelsen av å ha utrettet noe positivt for en person. En slik enhet vil virkelig interessere seg for å gjøre en god jobb for brukerne. De vil ikke behøve direktiver – de vil optimalisere sine egne prosesser av egen fri vilje. Saksbehandlerne og fagpersonene må på denne måten jobbe tettere sammen noe som vil føre til kompetanseflyt og ikke minst gi et bedre overblikk over saksgangen. Et slikt system er i mindre grad avhengig av store, komplekse IT-systemer. De helt essensielle funksjonene – som en koplett journal per person – må man nok fremdeles ha, men vi behøver ikke saksbehandlingssystemer som støtter kompleks saksgang.

Dette er (desverre) ikke noe jeg har funnet på selv. Tankegodset kommer fra W. Edwards Deming som spesielt Toyota hørte på på 1950-tallet og som mange gir mye av æren for at Japanerne så fort kom seg på beina som industrinasjon etter krigen. Etter hvert har “The Toyota Way” blitt definert som Lean - som er en ledelsesfilosofi som kan tilpasses veldig mange ulike organisasjoner. Innenfor tjenestesektoren og saksbehandlingssystemer er det nå spesielt Systems Thinking som er mest toneangivende. Spander 1 time på denne videoen der Vanguards John Seddon forklarer hvordan dette konseptet kan revolusjonere saksbehandlingssystemer.

Cultural change is free from Mindfields College on Vimeo.

Er det mulig? For godt til å være sant! Hvorfor gjør vi ikke dette? Jeg tror grunnen først og fremst er fordi disse tankene strider imot en del tillærte “sannheter”. Mange skal avlæres, myter skal overvinnes og kjepphester kastes.

De viktigste mytene som virker mot dette tror jeg er slikt som:

• Sentralisering gir vesentlige stordriftsfordeler
• Sentralisering gjør at vi lettere kan utnytte spisskompetanse
• Man må ha lederstilling for å ta beslutninger
• Medarbeidere og enheter må styres gjennom å sette lokale mål
• Et rettferdig system må være regelstyrt og er avhengig av standardisering

Kan det være likhetstanken som har vært mest styrende her? Ender vi opp med systemer der alle blir behandlet like dårlig – i stedet for å tillate forskjeller med det resultatet at alle blir bedre? Det er jo klart at i et desentralisert system er det lett å frykte at to ganske like saker får noe forskjellig utfall. Men det opplever vi allerede i dag! Se for eksempel innlegget NAV som overdommer på den utmerkede bloggen Marias Metode. Les gjerne de 182 kommentarene også… Reglene er – og vil alltid være – utilstrekkelige. Det MÅ utvises skjønn. Hvorfor ikke da la skjønnet være en naturlig del av prosessen? Hvorfor ikke sikre at skjønnet utøves av kompetente team i tett kontakt med brukeren?

SISTE: Aftenposten: Intern NAV-kritikk ties ihjel: Bekrefter systemfeil – som må rettes om det skal bli bedring. De måles på tid - ikke kvalitet, det er ingen forkus på forbedring, det er ikke lov å si i fra, det brukes masse energi på fortvilelse og “snakk i gangene”. Hele sentraliseringstankegangen må endres om det skal bli bedring!

Jeg kommer rett fra lørdagens faste spinning-time. Hadde tenkt å legge inn en ganske hard, men ikke for lang treningsøkt. Jeg har lært at det er viktig og ikke presse seg for hardt i treningsperiodene. De virkelig harde intervalløktene skal spares til formtoppingen. Mine mål for 2010 dreier seg om slå egne tider på Birken på ski, sykkel og på beina. Som i år.

Man kan få masse kunnskap om trening blant annet på olympiatoppen.no og på et utall nettsteder med diskusjonsforum. Når det gjelder utholdenhetstrening synes alle å være enige om at mange mosjonister trener for hardt og for lite variert. Dette går utover overskuddet og gir dårlig framgang. Men hvordan kan du vite om du trener for hardt? Første bud er å skaffe seg en pulsklokke. Jeg gravde dypt ned i lommeboka og kjøpte meg en Polar RS800 som kan gi en masse data om hver treningsøkt, basert på pulslogging. Under ser vi loggen fra dagens spinning-time. Jeg har her utfordret melkesyreterskelen min ganske kraftig.

Jeg har faktisk vært i sone 5 i 39 % av tiden – hvilket kanskje er litt for mye. Men, jeg har heller ikke tenkt å trene på et par dager, så jeg får sjansen til å opparbeide meg overskudd igjen før neste økt. I min lille 2-minutters retrospective konkluderer jeg med at jeg er fornøyd med denne økta. Må bare huske å ta det roligere neste økt. Pulsklokka gir meg også direkte feedback underveis i treninga, så jeg kan justere intensiteten etter hvor jeg ønsker å ligge. Veldig motiverende å følge med på dette!

Idrettsfolk er ekstremt avhengig av feedback for å øke prestasjonene. Man har en teori i bunnen om hva som er riktig trening i de ulike fasene. Og så bruker man alle tilgjengelige verktøy for å samle data og måle progresjonen mot målet. Men siden vi her snakker om mennesker så er det til syvende og sist den enkelte utøver som vil gjøre vurderinger løpende underveis. Det er ekstremt vanskelig å jogge rolig om været er godt, musikken på øret er suggererende og kroppen fungerer glimrende. Kommer man i flytsonen er det bare å la det stå til, så får man ta smellen etterpå. All loggingen og feedbacken kan ikke bli mer enn veiledende.  Dataene motiverer og må brukes med måte til å øke kunnskapen om egen kropp, ikke til blind styring.

På samme måten er det med smidig systemutvikling. Vi ønsker data som kan gi oss kunnskap om to ting: 1) hvordan vi ligger an i forhold til det vi har forpliktet oss til og 2) data som kan gi oss kunnskap om hvordan det lønner seg å jobbe/samhandle.  Scrum – som er det desidert mest brukte rammeverket – legger opp til å klare seg med så lite verktøy som mulig. Vi jobber i små team nettopp for at vi på en pragmatisk og uformell måte kan beholde oversikten. Vi har daglige møter for å koordinere.  Vi må ha skikkelig kontroll på alle oppgavene i Sprinten og hva som gjenstår for å bli ferdig. Bruk gjerne Task Board (lapper på veggen) om man er samlokaliserte. Tar man disse tingene på alvor blir verktøybehovet minimalt. Det er faktisk et eksplisitt mål å holde verktøybruken på et ansvarlig minimum. Verktøy har en tendens til å institusjonalisere oppførsel, både den gode og den dårlige.

Når vi jobber i selvstyrte team må vi være ekstra oppmerksomme på hvordan vi bruker data. Vi ønsker åpenhet og synlighet, men vi må vokte oss for å premiere oppførsel på individnivå. Selvstyrte tem bygger på ”kollektivt eierskap” hvilket lett kan få en slagside om individer premieres eller straffes. Smidig dreier seg mye om å frigjøre seg fra tradisjonell tankegang basert på ”Command and Control” (Les her gjerne ”Freedom from Command and Control” av John Seddon). Om en autoritet tett på teamene (ofte kalt prosjektleder) begynner å bruke data for å styre teamene forsvinner lett dette eierskapet. Autoriteten er tydeligvis den som sitter med eierskapet her…

Det er sterke krefter som virker i motsatt vei av Smidig; Vaner, posisjoner, etablerte ”sannheter”, ønsket om å kontrollere osv. er eksempler på slike. Ønsket om å selge verktøy – eller gleden over et avansert dataverktøy er andre krefter vi må være obs på.

Når vi skalerer opp og må sette sammen mange parallelle team med visse avhengigheter må vi selvsagt håndtere denne kompleksiteten på en forsvarlig måte. I Scrum anbefaler  vi flere verktøyløse mekanismer som Scrum of Scrums, oppmøte på hverandres Daily Scrum og ikke minst tversgående virtuelle team (eller communities som Mike Cohn kaller dem i sin siste bok). Dette er ekte smidige løsninger. Mange vil sverge til mer tradisjonelle løsninger som å ha en prosjektleder som koordinerer, kjøpe seg verktøy som gir styrings- og kontroll informasjon. Dette er ikke smidige løsninger.

Smidig dreier seg om å tilfredsstille brukernes (eller mer generelt interessentenes) behov og det bør stå i sentrum. Idealet er pull (som definert av Toyota) der vi lar oss styre av brukernes behov. Det vi virkelig bør samle data om er brukernes ønsker og om brukernes tilfredshet. Gå gjerne så langt som å kvantifisere og måle de verdiene og produktegenskapene brukerne ønsker seg (se www.gilb.no for mer info om Value Management). Dette gir mer verdifull styringsinformasjon og dessuten risikerer vi ikke å ødelegge de selvstyrte teamene.

Ukas Computerworld pusher Rationals Team Concert uhemmet under overskriften TEMA SMIDIG. I det jeg leser er det ikke noe som tyder på at dette er særlig smidig. Alt tyder på at dette er et verktøy for en prosjektledelse som ønsker å ha kontroll. God gammeldags Command and Control. Jeg har kikket litt på reklamen for verktøyet og får da bekreftet mine mistanker:

Her ser vi at de betrakter Burndown som et redskap til å kontrollere Quality of Planning.. Underlig burndown konsept også om man ser på Planned Work som går oppover. Er Arbeid definert som å bruke timer?

Jeg er redd for at nå en del sterke krefter har kastet seg på smidig-bølgen – uten å være smidige. Man ser at smidig selger og gjør noen justeringer i retning av iterasjoner og inkrementer. Dette er en farlig utvikling som kan vanne ut Smidig-begrepet. Vi mister da den kanskje vanskeligste utfordringen, nemlig å bevege oss vekk fra Command and Control mot selvstyrte team. Computerworld og andre er nyttige idioter som lar seg bruke i deres ”smidige” profilering.

Fakta1: Det har aldri vært noe hemmelighetskremmeri rundt CSM – Certified Scrum Master. Dette er et 2 dagers kurs i regi av en sertifisert instruktør. Verken mer eller mindre. En sertifisert instruktør betyr Certified Scrum Trainer – CST.

Fakta2: Scrum er ikke noe registert varemerke. CSM, CST og de andre sertifiseringene er det.

Fakta3: Scrum Alliance er forpliktet til å holde Scrum (innen systemutvikling – ikke rugby) på et høyt kvalitetsnivå, og å hjelpe organisasjoner i å bli mer effektive ved å hjelpe dem i gang med Scrum.

Fakta4: Scrum er en gedigen suksess med mer enn 60.000 CSM er verden over.

Hva er det som er lureriet her? Om noen blir mektig imponert over CSM på en CV og velger å ansette eller leie inn vedkommende uten å sjekke hva som ligger i begrepet får de skylde seg selv. Maken til naivitet! CSM sikrer ikke kvaliteten til personen. Selvsagt ikke. Men CSM har 2 funksjoner:

1. Det sikrer at vedkommende har lært Scrum av en Certified Scrum Trainer og ikke en selvlært konsulent som gir sin versjon eller tolkning av Scrum. Dette er hovedpoenget.

2. Den gir de som ønsker å satse på å bli virkelig gode et godt fundament å bygge videre på, enten man ønsker å gå videre til neste nivå eller ikke.

Hva neste nivå er? Ser ikke ut som det er så mange nordmenn som interesserer seg for dette – kun 10 stk er Certified Scrum Practitioner (CSP) i Norge, mens over 3000 er CSM.

Vel, en ting må selvsagt Scrum Alliance innrømme. Ordet Master indikerer noe mer enn et 2 dagers kurs. Greit det. Et uheldig ordvalg. Practitioner er altså mye mer verd. Ikke helt logisk det heller.. Men slik er det, og det kommer nok ikke til å endre seg.

Jeg kan ikke fri meg fra og tenke: “Noe har gått litt galt her i Norge”. Vi har verdens høyeste tetthet av CSMer, men antageligvis verdens laveste andel CSP. I CSP ligger det reell verdi og jeg ville lett ansatt en CSP i et Scrum Team (jaja, selvsagt etter å ha gjennomført alle de andre vurderingene da:)) Noe med arbeidsmarkedet her å gjøre kanskje?

Nå har Scrum Alliance innført en eksamen slik at det ikke skal være fullt så lett å sove seg igjennom en CSM. Dere kan lese mer om dette  her. Det spørs om CSM gir noen særlig større verdi på grunn av denne eksamene. Det er fortsatt bare et 2 dagers kurs… Et kurs med høy kvalitet.