Start med hvorfor!

Hvorfor er himmelen blå?
Hvorfor regner det?
Hvorfor er mamma lei seg?

eller

Hvorfor må vi føre timer i IT-prosjekter?
Hvorfor trenger vi et nytt datasystem for kunderegisteret?
Hvorfor skal vi innføre Scrum?
Hvorfor finner kundene så mye feil i systemene våre?
Hvorfor er vi organisert på denne måten?
Hvorfor skal vi implementere dette kravet på denne (idiotiske) måten?
Hvorfor skal akkurat vi lage dette nye produktet?
Hvorfor skal kundene kjøpe dette nye produktet?

osv osv..

Akkurat som små barn, bør vi stille spørsmål til hvorfor vi gjør ting. Eller hvorfor vi gjør ting på en spesiell måte. Om vi gjør dette rutinemessig vil vi garantert oppdage at ikke alle strukturer og arbeisformer er like velbegrunnede. Ofte er svaret “av gammel vane”, eller “fordi rutinene våre sier det”. Dette er dårlige svar i 2012! Hvor raskt blir ikke en vane FOR gammel i dag? Hvor mange er det som har rutiner og prosedyrer som er så oppdaterte at de reflekterer dagens behov?

Hvorfor som problemløsningsmetode

Toyota er berømte for å ha brukt metoden “5 whys” i mange tiår. Ideen er å finne rotårsaken til et observert problem – som ofte kun er et symptom på noe bakenforliggende. Om vi “løser” observasjonen direkte, vet vi at vi risikerer at det samme problemet dukker opp igjen, akkurat som med løvetannen om vi ikke får opp hele rota. Det viser seg at etter 5 ganger hvorfor så er kjansen stor for at du har kommet til rotårsaken.

Se bare på scenariet:

Oljeflekk på gulvet!
Hvorfor?
Røret i taket er lekk!
Hvorfor?
Vi kjøpte en ladning med billige rør her i fjor..
Hvorfor?
Vi ville holde utgiftene nede!
Hvorfor?
Innkjøpsavdelingen hadde pålegg om å spare penger!
Hvorfor?
En dipp i markedet fikk oss til å tenke kortsiktig!

OK, her har vi rot-årsaken til oljeflekken. Nå må sannsynligvis alle rørene i taket byttes ut. Da vet vi til en annen gang at det er fort gjort å spare seg til fant ved å reagere på denne måten på variasjoner i inntjeningen.

Jeg har deltatt i retrospectiver i mange ulike team og grovt sett kan de deles inn i to kategorier:

• de som diskuterer reelle problemer
• de som diskuterer hvilken metode som er best.

Den siste kategorien gir liten eller ingen verdi. Diskusjoner som ikke er forankret i reelle hindringer, eller ambisjoner om å bli bedre på noe som er reelt for kunden, blir lett endløse meningsutvekslinger som fører til en endring, men ikke forbedring. Når jeg ser dette forsøker jeg å bryte inn og spørre hvorfor vil dere endre på dette? Hvilken effekt skal dette få for kunden? Det er ofte nok til å flytte fokus over på forbedring.

 

Hvorfor som ledestjerne

Simon Sinek skriver og snakker svært overbevisende om slagkraften i alltid å starte med hvorfor når man skal i gang med noe (se http://www.startwithwhy.com/ eller se hans TED-talk.

Hvorfor kan utløse en verdifull fordypning i egen overbevisning. En som er skikkelig overbevist selv vil også lettere kunne få andre med på ideene sine. Et firma som kommuniserer sin overbevisning til markedet – og viser at det de gjør harmonerer med denne – vil utmerke seg. Sinek bruker Apple som et godt eksempel. Steve Jobs var ekstremt god til å selge ideen med produktene og ikke prouktet selv.

Ofte – men ikke alltid – handler hvorfor om følelser og ikke fakta.

Sinek operere med The Golden Circles der det ytterste nivået representerer hva vi leverer eller tenker å lage. Dette er det konkrete. Det som er synlig og taktilt. De aller fleste operere her både når de planlegger, gjennomfører og selger produkter og tjenester. Men de aller beste vil alltid være helt sikre på hvorfor de tror så sterkt på nettopp disse nye ideene. De begynner innerst, og sikrer at alle viktige interessenter deler den samme overbevisningen. De aller fleste begynner i ytterste sirkel, og finner målet etter hvert…

 

Hvorfor lager vi IT-systemer?

En annen som stadig minner oss om viktigheten av hvorfor er Gojko Adjik. Hans helt ferske bok om Impact Mapping er et godt eksempel på kraften i å begynne med hvorfor. Impact Mapping er ment som en metode for å komme fram til IT-systemer som faktisk løser kundens egentlige problemer. Svaret er ikke nødvendigvis en masse nye features!

En Impact Map er et tankekart som består av 4 nivåer. Vi begynner å spørre oss hvorfor skal vi gjøre dette? Dette blir da forretningsmålet. Deretter spør vi hvem kan hjelpe oss å nå målet? Da får vi rollene eller aktørene. Så spør vi hvordan kan aktørene hjelpe oss å nå målet? Og til slutt er spørsmålet hva må til. Dette er ofte Scope eller funksjonalitet om man vil.

Om vi passer på å utarbeide slike tankekart i en tverrfaglig workshop vil vi kunne sikre oss at vi holder fokus på å oppnå målet – og kun det. Når ett mål er nådd kan vi selvsagt sette nye mål. De fleste lesere av denne bloggen forstår her lett av dette harmonerer veldig godt med Smidige metoder og Scrum. Har man gjort denne øvelsen godt, blir det neste skrittet med å lage brukerhistorier også enklere.

 

Hvorfor skal vi iverksette store, smertefulle endringsprosesser?

Agile42 jobber med å hjelpe organisasjoner med å endre seg i retning av Smidig og/eller Lean. Dette gjør vi gjennom opplæring og coaching. Innføring av Scrum vil initiere endring og gjort riktig vil man i teorien gradvis gjøre hele organisasjonen mer og mer smidig. Men i praksis fungerer det sjelden slik. Vi må sette (forbedrings)mål og prioritere tiltak ut fra dette. Vi gjør dette gjennom vår Agile Strategy Map – som også er et slags tankekart.

Ofte er målet “å innføre Scrum” eller å “bli mer smidige”. Dette er ikke gode målsetninger, bare virkemidler som selvsagt kan gi store forbedringer. Så vi forsøker alltid å få kunden til å sette seg mer forretningsmessige mål, før man setter i gang med å gjøre endringer.

Stragegikartet begynner da med en overordnet målsetning, som godt kan være rent forretningsmessig. Deretter kommer vi fram til en rekke mulige suksessfaktorer i en ide-dugnad. Dernest er det å finne konkrete betingelser som må være på plass for å oppnå suksessfaktorene.

 

Forbedringsmålene er som regel er de forretningsrelaterte. Det kan være hyppigere release-takt, bedre kundetilfredshet, kapre nye markeder som verdsetter brukervennlighet etc.. Men det kan også være mer interne mål som skape gjennomsiktighet,  realistiske målsetninger, tåle sterk vekst, øke evnen til å lære av erfaring etc.. Mer info om dette fra Dave Sharrock på accus 2011

Vi bruker kartet aktivt for å følge opp fremdrift mot målet blandt annet ved å bruke fargekoder på de ulike suksessfaktorene og betingelsene. Kartet vil utvikle seg gjennom hele trasisjonen.

De som utmerker seg og vinner i lengden er nådeløse når det gjelder å spørre hvorfor de gjør ting. I 2012 kan du ikke risikere å sovne. Det som fungerte fint i går, gjør ikke nødvendigvis det i dag. Vil du bli en vinner – eller beholde forspranget du har – må du systematisk utfordre Status Quo. Ta deg tid til å spørre hvorfor!

Empirisk prosesskontroll

Når man skal løse et problem, kan man først forsøke å skaffe seg noe erfaring eller empiri før man låser seg til den ene eller den andre løsningen. På den måten vil man kunne få en større trygghet for at løsningen er god.

Når landskapsarkitektene skulle planlegge hellegangene på Universitetet i California, Irvine tenkte de først å gjøre dette på den vanlige måten, nemlig å forsøke å gjette hvor studentene kom til å krysse de store gressplenene, og å anlegge heller der. Men dette hadde de tidligere bare måtelig suksess med. Alltid dukket det opp stygge stier over gresset der studentene fant det for godt å gå. Så, i stedet valgte de denne gangen å bare plante gress. Så ventet de et år, for da visste de jo at det ville danne seg stier på gressplenen – nøyaktig der studentene gikk. Da var det ganske enkelt å legge heller nøyaktig der det var behov for det, for nå hadde de svært god empiri å basere seg på.

Vitenskapelig metode

Om man skal i gang med å løse komplekse problemer som kanskje ingen har løst før – og som man selv bare har vage ideer om løsningen på – blir man jo tvunget til å gjøre noen spede forsøk, som man er forberedt på at kan være et bomskudd. Det gjelder da å finne ut om man er på en farbar vei, så raskt og så billig som mulig, slik at man bruker den nye kunnskapen til å justere kursen. Dette er jo akkurat det vi kaller en vitenskapelig metode. Vi har et problem og vi har en mer eller mindre velbegrunnet hypotese om en løsning. Vi gjennomfører en test, et eksperiment man man vil, og evaluerer så snart man har et resultat. Styrket dette hypotesen, eller ikke? Uansett om den gjorde det eller ikke, bruker vi nyervervet kunnskap til å utføre et nytt eksperiment, kanskje med en noe justert hypotese. Og slik kan man holde på og gjennom gjentagende eksperimenter komme nærmere og nærmere en løsning. (Om hypotesen ikke styrker seg gjennom eksperimentene, gjelder det selvsagt å avbryte – selv om det føles som et nederlag).

Lean Start-up er et konsept som fokuserer sterkt på dette med systematisk læring. Spørsmålet er jo “Hvordan kan vi så raskt og billig som mulig få validert lærdom ut av et eksperiment?” Og ikke minst “Hvordan så raskt og billig som mulig finne ut om en ide ikke er en farbar vei og bør skrinlegges?”

Empirisk versus definert prosesskontroll

Scrum baserer seg på “Empirical Process Control Theory“. Dette er et alternativ til “Defined Process Control“. Det er verd å merke seg at disse to teoriene er eksluderende – det er vanskelig å kombinere de to.

Definert Prosesskontroll

Her er ideen “stepwise refinement” slik at vi jobber strukturert i en kjede av definerte aktiviteter som gradvis løser problemet. Det som er resultatet av en aktivitet mates inn i den neste. Hver av aktivitetene har gjerne en tilordnet rolle eller ansvarlig person. Den aller siste aktiviteten i kjeden produserer sluttresulattet.

Dreier dette seg om programvareutvikling kjenner vi lett igjen vannfallsmodellen, der noen analyserer, andre designer, andre igjen utvikler, så tester vi, integrerer, og leverer. Vi får her begrenset mulighet til å teste ut hypoteser, vi vil være helt avhengige av analysene og planleggingen som finner sted helt i starten holder vann. Dette kan fungere helt fint – om problemet er repeterbart, dvs noe vi har gjort før. Eller sagt på en annen måte: om vi er i “Simple” hjørnet i Cynefin-modellen. Om vi oppdager at analysene og planene våre ikke holder vann  forsøker vi å løse dette gjennom endringsbehandlig – hvilket er en svært dyr og belastende aktivitet som fører til store forsinkelser i fremdriften. Det som ofte forårsaker dette er at vi undervurderer kompleksiteten og det vi i utgangspunktet trodde var enkelt viste seg å være komplekst.

Empirisk prosesskontroll

Her er tanken at vi må eksperimentere og skaffe oss empiri så raskt som mulig slik at vi gradvis bygger opp kunnskap og kommer nærmere og nærmere en løsning på problemet. Dette fordrer arbeid i tverrfaglige team slik at vi sikrer at de som gjør arbeidet totalt sett har nok kunnskap. Vi bryr oss ikke om hvordan de jobber. Akkurat som i vitenskapelig metode vil den initielle hypotesen være ganske avgjørende for effektiviteten, så vi må gjøre en del forarbeid for å skaffe gode nok (men ikke bedre) utgangshypoteser.

Om dette dreier seg om programvareutvikling vil vi ha en hypotese om hvilken teknologi vi bør velge, hvilke arkitekturprinsipper som bør gjelde og selvsagt hvilken funksjonalitet vi skal tilby tidlig.

Etter dette gjelder det å komme fram til resultater som lar seg observere og lære av. Disse resultatene kan i noen tilfeller være så gode at de faktisk kan leveres, men verdien i et slik resultat kan godt være ren kunnskap. Enkelte ganger vil vi ha forhåpninger om at brukerne virkelig ønsker seg dette, men så viser det seg allikevel (huff, disse brukerne er så uforutsigbare!) at vi får tommelen ned. Resultatet vil allikevel ha en verdi for vi vil garantert ha lært en del!

Igjen, er dette programvareutvikling, forsøker vi så tidlig som mulig å sette teknologi- og arkitektur-beslutningene på prøve, og selvsagt å få tilbakemelding på om den tidlige funksjonaliteten vi lager verdsettes av brukerne. 

Scrum lar seg vanskelig kombinere med definert prosesskontroll. Men det var heller aldri meningen – Scrum er laget for innovasjon, å løse komplekse problemer (i “Complex” hjørnet i Cynefin-modellen) og er basert på hypotetisk-deduktiv metode. Vi optimaliserer transparens og gjør “inspect and adapt” gjentatte ganger slik at vi gradvis kommer nærmere og nærmere målet.

Bruker man Lean Start-up-tankegang i kombinasjon med Scrum vil man typisk optimalisere lærdommen man får ut av hvert eksperiment. Og så er det selvsagt slik at jo hyppigere man leverer ting til markedet og jo raskere man får feedback etter å ha utviklet noe, desto bedre læringseffekt får man. De som leverer på Web og er i stand til å gjøre continuos deployment vi kunne eksperimentere med brukerne som en integrert del av prosessen. Dette er på mange måter den ultimate utviklingsprosessen.

 

Lokalt ansvar trumfer regelstyring

Det virker som Norsk forvaltning stadig beveger seg i retning av mer og mer detaljerte styringssystemer. 22-juli rapporten viste at politiet var (for meg) overraskende prosedyrestyrt. I diskusjonen rundt alle problemene i helsevesenet forstår vi at det samme er tilfelle der. Avdelingsdirektør Eivind Tesaker i Kulturdepartementet varslet for noen dager siden av byråkratiet er verre enn sitt rykte. Regelverket skal følges – og det får konsekvenser om noen bryter interne regler. Regelverket ledsages ofte med detaljert målstyring der den enkelte person og avdeling får målsetninger å oppnå – som da er tenkt å gi en forbedring. At NAV er styrt på denne måten har vi visst lenge.

Byråkrati

Når man styrer en organisasjon på denne måten fører det naturlig nok til et behov for kontroll og oppfølging. Regelverket skal vedlikeholdes, noen må følge opp at reglene overholdes og at vi oppnår målsetningene. Dette skaper selvsagt byråkrati. Byråkratiet vokser tre ganger så fort som resten av staten kunne vi nylig lese i Aftenposten. Dette er jo betenkelig og en tydelig indikasjon på at vi kanskje ikke bruker ressursene våre optimalt. Men dette er ikke det verste. Jeg kan leve med byråkrati – dette gir sysselsetning og “vi har råd til det”. Nei det som er ille med denne styringsformen er at beslutninger nå tas av  folk med avstand til virkeligheten og at de som står midt i virkelige problemstillinger langt på vei slutter å ta ansvar!

Ansvar

Aftenposten – Det er en altoverskyggende frykt for å gjøre feil, sier Erik Solheim (SV)

– Jeg har alltid sagt at noe som er fantastisk med Norge, er at folk nede i systemet tør å ta ansvar, sier Erik Solheim. Men så kom rapporten fra 22. juli-kommisjonen, som viste at dette ikke var tilfelle.

Jeg tror vi står overfor et fundamentalt problem når styringssystemet gjør atfrykten for å trå feil overskygger lysten på å gjøre det riktige. Jeg tror Solheim har helt rett – det ligger naturlig for Nordmenn å ha tillt til andre, å delegere ansvar og å være pragmatiske i forhold til regler. Man skal vel ikke lengre enn til Sverige for å oppleve en større autoritetstro. Nordmenn går på rødt lys når det ikke er biler i nærheten. Dette mener jeg er et sunnhetstegn. (Jeg har faktisk opplevd dette flere ganger i et internasjonalt forskningsprosjekt for noen år siden. Nordmenn, Svensker, Tyskere og Franskmenn skal ut og spise og går og småprater nedover fortauet. Kommer til et lysregulert forgjengerfelt og Tyskerne og Svenskene blir stående, mens Nordmenn og Franskmenn rusler småpratende over veien på rødt :))

Kompliserte oppgaver

Hvor bra kan egentlig et slikt system med detaljstyring bli? Dette avhenger selvsagt av kompleksiteten i situasjonen. Enkle, rutinemessige oppgaver kan helt greit detaljreguleres – det er værre med komplekse eller kaotiske probleme. Når helsearbeidere eller politifolk plutselig befinner seg i en vanskelig situasjon og raskt må ta en beslutning – skal de da slavisk følge regelverket som umulig kan være skreddersydd for den aktuelle situasjonen – eller skal de bruke fagkunnskapen og erfaringen sin og agere etter det? Vi så hvordan det gikk når de politifolkene som ankom Tyrifjorden først, nærmest ble hendlingslammede og ventet på beslutninger i stedet for å gjøre som de lokale båteierne og bare handle. Beslutningene ble tatt av overordnede som ikke hadde på langt nær det samme overblikket som de som faktisk var på stedet. Verdifull tid ble sløst bort, og løsningen (en overfyllt gummibåt) var neppe den beste. Jeg bebreider selvsagt ikke politifolkene. De er drillet i å følge regler og har ikke opplæring i å improvisere.

Oppdatering: 8 av 10 politifolk har ikke fått opplæring i krisehåndtering

Vi må lære av erfaring

Vi må gi ansvaret tilbake til de som står midt oppe i problemene. Vi må våge å stole på folk – og vi må lage et system der vi tåler å feile på områder som ikke setter liv i fare. Om vi får raskt tilbakemelding på jobben vi gjør vil vi kunne lære av erfaring og stadig bli bedre. Men da må frykten for å feile tones ned. Det største hinderet for å evne å optimalisere en organisasjon er mangel på læring av erfaring. Hvordan kan vi tro at vi skal få læring når vi ikke kan aksepterer at noen har trått feil?

 

Smidige motkrefter

Smidig har vært på alles lepper siden rundt 2005 – i hvert fall i den delen av IT-bransjen jeg har beveget meg i. Alle så det opplagte potensialet som lå der og ventet på å bli tatt ut. Utviklerne elsket det – de var lei av urealistiske planer lagt av andre, lei av dårlige utviklingsomgivelser og de var lei av å være i brannslukningsmodus hele tiden.

Samtidig foregikk det en tilsvarende prosess på markedssiden og på ledelsesnivå. Man så at man trengte å bli mer dynamiske, respondere raskere på endrede markedsforhold, bli mer innovative og få mer kontroll på hva som foregikk på IT-siden. Begge leire brukte Smidig som begrep (Agile og Agility), men de la forskjellig betydning i det.

 

Nå i 2012 skulle en tro at vi hadde fått nok erfaring med Smidig til at ledelse, forretning, kunder og utviklere hadde fått et mer omforent syn på hvordan vi skal forstå Smidig. Dengang ei. Den endringen Smidig innebærer og krever går svært langsomt. (Alle som virkelig har satt seg inn i Smidig og som har fulgt de som stod bak manifestet i en årrekke vet at for de aller fleste innebærer en “smidiggjøring” en ganske radikal endring av både arbeidsprosesser, tankegang og bedriftskultur).

3 motkrefter

Det er mange grunner til at endringsprosessen tar tid, og jeg vil her peke på 3 momenter som spiller inn:

1. “Slankepillen”. Vi innser kanskje at vi må endre på måten vi jobber på. Noen forteller at vi må gjennomgå en reell snuoperasjon innbefattet en kulturendring – hvilket fortoner seg som reneste marerittet. Heldigvis er det andre rådgivere som sier at neida, det er ikke så ille. Vi har løsningen for deg og den er slett ikke så vanskelig:-) Du må bare ta i bruk verktøyet vårt, innføre iterasjoner, effektivisere endringsprosessen din og fjerne “waste” i organisasjonen. Vi nevner order Lean i samme åndedrag og kunden er solgt.

Vi vil jo så gjerne at det skal finnes en enkel kur! En slankepille. En liten Quick-fix. Verktøyet som fikser det meste. Det er klart vi forsøker dette framfor å gå den lange veien om en mer grunnleggende endring.

2. WTF!?? Smidig hviler på prinsipper og en tankegang som hverken er intuitiv eller i henhold til det vi har lært gjennom et langt liv (beslutningstakerne har gjerne levd en stund). Empirisk prosesskontroll?? Vente til siste ansvarlige øyeblikk?? Kollektivt ansvar?? Bra å feile!!? Ledere som tjenere!?? Jeg har sett vantroen i mange lederes ansikt når jeg har holdt kurs for dem. Alle er for Agile, men når de forstår at de må avlæres og lære seg en helt ny måte å tenke på faller mange av lasset.

3. Rådgiverne. Alle ledergrupper har et lite utvalg av rådgivere de benytter seg av når de skal drøfte organisering og ledelse. Særlig når de forstår at det må endring til. Noen bruker de store, veletablerte management consulting tilbyderne som McKinsey, Accenture, Baines etc.. De fleste lytter til prosjektlederne – som igjen lytter til Project Management Institute (PMI). Og de fleste ledergrupper lytter til sjefsarkitekten og andre “halvtekniske” ledere i egen organisasjon.

Rådgiverne som bremsekloss

Ved ganske mange anledninger de senere årene har jeg oppdaget at kundene som jeg skal hjelpe med innføring av smidig, har et paralellt Lean-initiativ. I utgangspunktet burde dette være positivt – Lean kommer jo fra “The Toyota Way” og har på mange måter det samme opphavet som smidig. Men det viser seg at verden ikke alltid er så lineær som en skulle ønske. Det finnes nemlig Lean-varianter som er anti-smidig, de fører til detaljert målstyring og sub-optimalisering!

De veletablerte ledelses- og prosjektstyrings-konsulentene er ikke tjent med smidig. De stod igjen på perrongen når smidig-toget gikk av naturlige grunner. De hadde jo allerede en lukrativ gesjeft gående og hadde investert masse innsats og prestisje i sine egne modeller. Strategien var åpenbart i starten å forsøke å tie ihjel alt som hadde med smidig å gjøre. “Det går sikkert over – som så mye annet”. Men så begynte flere av de virkelig store – som Google, Amazon og eBay å vise omverdenen at smidig fungerer uovertruffent!

Source Information Service (http://www.sourceforconsulting.com/) har gjort en omfattende undersøkelse der de spurt lederne av 400 store bedrifter hvordan de oppfatter konsulentbransjen og resultatet var ganske nedslående, spesielt for McKinsey.
Dagens Næringsliv hadde en større artikkelserie basert på undersøkelsen: Konsulentselskaper på etterskudd  noe som burde være ganske nedslående lesning for denne delen av konsulentbransjen. Hegnar online skriver også om den samme undersøkelsen: Konsulentselskapene leverer ikke lenger det kundene vil ha, er lite fleksible og trege til å fornye seg.

Det er for øvrig interessant å se at ledern for bransjeorganisasjonen Abelia, Paul Chaffey, her velger å ta denne delen av konsulentbransjen i forsvar og kaller undersøkelsen “helt verdiløs”. Hvorfor denne undersøkelsen er så dårlig har jeg ikke klart å finne ut, selv om jeg forsøkte meg på en diskusjon med Paul i kommentarfeltet og på facebook. Men det er helt tydelig at Abelia ikke ser at de store konsulentselkapende kan virke konserverende på gammelt tankegods. Det er et tankekors for meg at ikke engang Abelia – som skulle være et friskt pust i NHO og representere kunnskapsbransjen og som faktisk arrangerte de aller første CSM-kursene i Norge – er villige til å legge noen krefter inn på å påvirke en endring. Chaffey bedyrer at han ikke er imot Agile. Han er bare ikke så mye for at han vil presse noe på. At IT-skandaler kan unngås og norsk næringslivs innovasjonsevne radikalt forbedres er tydeligvis ikke nok.

Anti-smidig Lean

Sleipe konsulenter selger gjerne “slankepille-Lean”. Den typen som gjør at man kan fortsette omtrent som før, uten smertefulle omfattende endringsprosesser. Man gjør dette på lokalt avdelingsnivå – inne i siloene – slik at toppledelsen slipper å bli særlig berørt. Og man gjør dette ved hjelp av måling. Måling i form av ytelsesmål eller Key Performance Indicators (KPIer) også kalt Management By Objectives (MBO). Teorien er at om alle de lokale målsetningene oppnås vil totalen blir bedre. Man fokuserer på å fjerne lokal “waste” og lokal effektivisering. Det som ofte skjer er at dette fører til sub-optimalisering og slett ikke til hurtigere gjennomløpstid eller høyere kvalitet. Man har plukket ut et lite sub-sett av Lean og ender opp med noe som er både anti-Lean og anti-Smidig. I et forsikringsselskap vet jeg de holdt på med Lean i mange år, uten å få ned gjennomløpstiden på saksbehandlingen. Og det til tross for at alle var enige om at saksbehandlingstiden var alt for lang og en trusel mot konkurranseevnen! Men ende-til-ende prosessen var det tydeligvis for smertefullt å ta tak i!

Ting Tar Tid

Statoil er et selskap jeg stadig trekker fram som spennede og med vilje til å tenke nytt og smidig. De har mange Lean-initiativer, de har Beyond Budgeting (“smidig budsjettering”) og de satser virkelig på Scrum. Men allikevel klarer de det kunsttykket å kjøre et IT-prosjekt i 5 år og svi av 700 MNOK på et system som er ubrukelig for de interne brukerne! Dette er jo komplett umulig med Scrum! Hva skjer?? Vel, det er helt tydelig at selv innenfor ett (riktignok digert) selskap tar det lang tid  før nye arbeidsprosesser får fotfeste.

Jeg tror en langt større andel av norske organisasjoner vil være smidige om 10 år. Men selvfølgelig ikke alle. Det som imidlertid er åpenbart er at enkelte ikke-smidige vil bli utkonkurrert av mer smidige konkurrenter. Dette vil være den største drivkraften som etter hvert vil overskygge de sterke motkreftene. Så gjenstår det å se om offentlig sektor vil våge å sette i verk kraftige nok tiltak til at de får god effekt av smidig.

Gjøre det riktige, eller følge regelverket?

En av de mest gripende TED-talkene jeg vet er Barry Schwartz´Our loss of Wisdom. Anbefales på det sterkeste (se den før du leser videre) om du er opptatt av etikk og moral, og spesielt om du – som meg – er urolig for utviklingen som synes å gå i retning av stadig mer standardisering og regelstyring. Det virker som det er vanskelig å kombinere regelstyring og god etikk.

I videoen hører vi blant annet om renholdere på sykehus som har detaljerte lange lister over arbeidsoppgaver, der ikke står noe om hvordan de skal forholde seg til pasientene. Nei, de har tvert om insentiver som går på å gjennomføre flest mulig av oppgavene på kortest mulig tid, hvilket betyr å overse pasientene. I en intervjuundersøkelse kom det fram at enkelte av disse rengjørerne ville unngå å støvsuge om pasienten har besøk. Eller sover. Andre ville la være å vaske gulvet akkurat nå fordi en pasient som var dårlig til beins var ute og gikk. Enkelte ville altså trosse arbeidsbesinstrukser og insentiver – fordi det var det riktige å gjøre. I min bok er dette hverdagshelter. Man hører også utallige historier fra offentlig forvaltning her til lands (som f. eks NAV) der saksbehandlere senker stemmen og sier av hvis vi dreier bittelitt på sannheten her, så vil vi kunne få en raskere og bedre løsning. Helter.

Jeg kunne ikke la være å tenke det samme når rapporten om 22 juli ble presentert. Politiet opptrådde ganske hjelpeløst når de første ankom Tyrifjorden. I stedet for å ta affære og handle – som de sivile båteierne (heltene) gjorde – ble de usikre og avventet ordre. Ordre fra overordnede som satt langt unna og ikke kunna ha et godt overblikk over situasjonen! Og det var prosedyrer å følge. Og ambulansene fikk beskjed om å holde seg langt unna til politiet hadde fått kontroll på situasjonen, mens ambulansjepersonalet ristet på hodet og skjønte at dette ville forsinke dem unødig. Hvorfor opptrer staute politifolk på denne måten? Hvor er initiativet? Hvorfor kan de ikke improvisere når situasjonen er ekstrem og tiden er ytterst knapp?

Professor Paul Otto Brunstad mener at dette er en helt fundamental utvikling i samfunnet, og som starter i skolen. Fra artikkelen i Ukeavisen ledelse – Utdanningen vår strøk 22. juli

“Han viser til at hvis du skal få til større frihet hos folk som jobber i direktorat og politi, så krever det at du har mennesker der som er modne og selvstendige. Mennesker som ikke er avhengig av ha klare instrukser for å handle. Brunstad etterlyser et samfunn som setter evner som som fantasi, frivillighet, vilje til forpliktelse og initiativ til å løse problemer høyere, og her mener han at skolen og utdanningssystemet spiller en viktig rolle.”

Vi kan ikke bebreide politifolkene som ankom først. Det viser seg at de er en del av et system som er langt mer prosedyrestyrt enn de fleste av oss var klar over. De var ikke opplært til – eller vant til – å improvisere. Det viser seg at alt (Systemet) er basert på at regelverket skal kunne dekke alle mulige situasjoner! Hvor fornuftig er det?? Finnes det virkelig folk som er så smarte at de klarer å forutse alle mulige situasjoner og lage et regelverk som er effektivt over alt? Selvsagt ikke. Det er like umulig som å lage en komplett og riktig kravspesifikasjon for at stort og komplekst, nytt IT-system…

For et par måneder siden hadde vi i agile42 “Coach Camp” i Berlin og jeg var så heldig å få en hel dag sammen med Dave Snowden – mannen bak kompleksitetsmodellen Cynefin (Jeg har skrevet om modellen her). I Cynefin har vi fire ulike “kompleksitetsnivåer” og Snowden sier at det kun er for de enkle problemstillingene at detaljerte prosedyrer og regelverk vil fungere godt. I det komplekse området kan det til en viss grad fungere, men du vil måtte basere deg på “ekspertuttalelser” for å finne rett løsning på et problem – vi må altså tillate noe skjønn. I det komplekse området finnes det ingen riktige svar; vi må gjøre forsøk og evaluere og lære mens vi jobber (typisk bl.a. for IT-prosjekter). Skal dette fungere godt må de som gjør jobben få myndighet til å gjøre egne vurderinger og ta selvstendige beslutninger. Og man må jobbe i tverrfaglige team (som i Scrum). Og så har vi det kaotiske området, der vi brått blir kastet ut på dypt vann. Dette er typisk katastrofer og kriser. Skal vi løse kaotiske problemer må vi improvisere. Ingen tid til særlig analyse. Ikke mulig å følge detaljerte prosedyrer. Utøya 22 juli var et svært godt eksempel på et “problem” i det kaotiske området.

Cynefin-modellen har også et femte område kalt disorder. Det sorte feltet i midten. Enkelt sagt er dette der du havner om du ikke er bevisst på kompleksitetsnivået. Det er da det virkelig kan gå galt. Jeg tror det er her vi ganske systematisk bommer fatalt. Vi forsøker å holde oss til regelverket, selv om vi ikke lenger befinner oss i det enkle området. Og mennesker som er drillet i og er vant til, enkle problemstillinger vil være fullstendig uforberedt når de plutselig blir kastet inn i kaos. Det synes som regelvante mennesker gradvis mister evnen til å “tenke sjæl”. Dette er dypt tragisk og trist. Men ennå tristere blir det når de som ennå ikke har mistet evnen, allikevel ikke handler og gjør det riktige.

 

 

 

 

Vil Wikispeed ryste bilbransjen?

Alle som er opptatt av disruptiv innovasjon bør følge Wikispeed nøye. Det de har gjort er er å ta software-teknologi og -tenkemåte med seg inn i et helt nytt domene og har begynt å produsere modulære, ekstremt miljøvennlige biler gjennom “crowdsourcing”.

Joe Justice, grunnlegger og CEO jobber fremdeles som konsulent i for software-selskapet SolutionsIQ og han har tatt med seg en rekke prinsipper fra programvareverdenen: Open Source, Agile, Test Driven Development (TDD), Lean / Kanban, Scrum og Objektorientert Programmering (OOP). Justice er Key-note speaker på Agile2012 i Dallas i August og utvilsomt en “coming star” innen Agile. Her er en liten presentasjon.

Wikispeed har klart å lage svært konfigurerbare biler som består av 8 moduler. De kan etter alt å dømme utrolig raskt lage varianter av bilen og gjøre kundetilpasninger langt raskere enn de beste i den tradisjonelle bilbransjen. De deler CAD beskrivelser på tvers av landgrenser og oppretter mikro-produksjonslinjer over hele verden. Pr i dag har de produksjon i 15 land, og gjør dette med frivillige som bruker mer eller mindre fritid for å få det til.

Måten de får til dette på er selvsagt med smidige metoder og Lean tankegang. De bruker Scrum og har Sprinter på 1 uke(!) – og de har demoer som vise ferdige produkter på slutten av disse. Designet av de første prototypene ble også gjort med Scrum. De benytter også Kanban og deler og visualiserer alt som skjer med Kanban-boards og “Information Radiators”.

Status nå er at bilene er fullt ut brukbare “commuting cars”, er sikre (passerer strenge crash-tester i USA) og kjører mer enn 100 MGP (Miles Per Gallon). Dette drivstofforbruket er bedre enn de fleste hybrid-biler! De får til dette med ekstremt lav vekt (joda det blir dyre materialer) og aerodynamiske karosseri. Det som nå står igjen er komfort. De mest innovasjonsorienterte kundene kan sikkert klare seg uten all verdens komfort, men skal de lykkes i stor skala må de selvsagt også konkurrere på komfort. Prisen er foreløpig ikke så lav, omtrent som en Toyota Prieus i USA. Det som driver kostnadene opp er Crash-testene og kompositt-materialer. Men som all annen modulær, disruptiv innovasjon med et stort marked vil helt sikkert prisene kunne tvinges nedover med økt volum.

Wikispeed har ingen planer om å lage et tradisjonelt selskap. De skal derimot skape en organisasjon uten hierarki, byråkrati og annet “waste”. De vil fokusere alt på å skape små, tverrfaglige team som gjennom lokalt eierskap, selv-organisering, tett samarbeid og ekstremt korte sykluser blir ultraeffektive. Dette kaller de XM – eXtreme Manufacturing. De vil være et distribuert fellesskap a´la Wikipedia.

Wikispeed er i utgangspunktet crowd-funding og non-profit, men dette “er for tiden under revidering”. De nøyer seg ikke med biler, traktorer kan se ut til å bli det neste satsningsområdet  (John Deere som har produsert traktorer siden 1837, er visstnok interessert i samarbeid!)
Metodene de bruker er universelle og de ønsker også å gjøre rent samfunnsnyttige prosjekter med crowdsourcing og Scrum.

Joe Justice forteller at han ble svært overrasket over reaksjonene fra “de store gutta” når de på et digert Autoshow i Detroit ble plassert midt i mellom Ford og Chevrolet. Han var redd de ville le, eller fnyse av bilen han stilte ut, men de var i stedet veldig interesserte og ville vite hvordan de gjorde dette. Han fikk faktisk klapp på skulderen! Joe Justice forklarer dette med at dette er smarte mennesker som veldig gjerne skulle ha jobbet på denne måten selv. Men i de selskapene de er i i dag er det så mange barriærer og så mye gammeldags tankegods i veggene at det blir litt utopisk å få det til. De ønsker faktisk at Wikispeed skal lykkes og dermed bevise at det finnes radikalt andre måter å organisere seg på.

Jeg gleder meg til fortsettelsen og ønsker Wikispeed hell og lykke på veien!

Oppdatering: Dette er gjennomsiktighet – her kan alle som har lyst se hva som foregår til enhver tid. Har du verktøyet Scrumy Pro kan du følge det i sanntid!

 

ScrumAlliance innfører eksamen med terskel (igjen)

Det er nok alvor denne gangen. Testen du må ta i etterkant av gjennomført Certified Scrum Master kurs vil bli en reell test der du kan stryke. Som mange vet har det lenge vært en multiple choice type test som du må ta innen 90 dager etter kurset for å bli sertifisert. Men det har ikke vært noen reell test, siden du vil bestå selv med 0 rette svar.

ScrumAlliance har selvsagt benyttet testen til å gjøre eksamenen bedre og bedre. De har lært hvilke spørsmål som er lette å forstå og er nå trygge på at de har en stor, god pool av spørsmål som skal gi en reell pekepinn på om deltagerne virkelig har forstått.

Denne testen er kontroversiell. Det synes som de ca 150 Certified Scrum Trainers er delt i tre. En tredjedel mener en slik test aldri vil kunne verifisere reell, dyp forståelse for Smidig og Scrum, og er dessuten redde for at dette vil føre til et for stort press på å tilpasse undervisningen til testen. En tredjedel synes det er på høy tid med en slik test. Den siste tredjedelen er nøytrale.

Testen vil bestå av 35 spørsmål og terskelen skal ligge på 24 riktige svar. Terskelen iverksettes 1. September.

Det er uvisst hva som vil skje med Certified Scrum Product Owner (CSPO), der er det pr i dag ingen test og ingen konkrete planer meg bekjent.

Oppdatering: Info er nå ute på Scrumalliance.org.

Smidig produkteierskap

I Scrum har vi Product Owner rollen, men uansett hvilket smidige rammeverk man velger vil den eller de som er ansvarlig for visjonen og verdien til produktet måtte beherske metoder og teknikker som harmonerer med smidige prinsipper. Hva er så alle disse metodene og teknikkene? Denne posten har til hensikt å gi et overblikk over dette fagfeltet.

Situasjonsbestemte suksessfaktorer

Det ofte slår meg at vår trang til å generalisere lett kommer i veien for å lykkes. Situasjonen, rammebetingelsene, modenhet, forutsetninger etc vil variere, men allikevel har vi lett for å svelge samme medisin. Produkteierrollen i Scrum er veldefinert. Du eier visjonen og skal på bakgrunn av denne lage en liste over produktkøelementer som da skal prioriteres i henhold til forretningsmessig verdi. Men hva er nå forretningsmessig verdi for de ulike produkeierne der ute? Det kan være utrolig mye forskjellig. Hvilke teknikker, metoder og hvilken tankegang skal du bruke for å lage en best mulig produktkø som gir mest mulig verdi? Dette “kommer an på”…

Verktøykassa til en produkteier

Det publiseres mye innenfor smidig produkteierskap for tiden, og det finnes helt ok gamle ting å være klar over. Jeg har laget en oversikt her.

Denne skyen er selvsagt ikke komplett på noen måte, men kan brukes som en rikholdig verktøykasse som er i utvikling. Hvordan velge riktig verktøy for den jobben som skal gjøres? Alle produkteiere behøver ikke beherske alle disse prinsippene og teknikkene. Men som produkteier bør du har en oversikt over hvilken del av verktøykassa som er relevant for deg.

Jeg har skrevet litt om tilpasning av selve Produkteierrollen her: https://scrummaster.no/?p=276. Vinklingen er at rollen er svært ulik avhengig av graden av innovasjon, av type kundeforhold og av avtale/kundeforholdet. Men hva bør en produkteier beherske av teknikker og metoder, avhengig av slike forhold?

Produktets livssyklus

Det er helt annerledes å lede produktutviklingen i et lite start-up enn i en veletablert organisasjon som vedlikeholder et modent produkt. Vi som lever av å veilede og kurse innenfor smidig må ha en solid forståelse av disse ulikhetene.

Figuren under viser de ulike fasene et programvareprodukt gjennomgår.


I oppstartsfasen gjelder det å opparbeide en visshet om at selve ideen og forretningsmodellen er levedyktige. Når beslutningen om å skalere opp utviklingen kommer, bør vi være tryggest mulig  på at investeringen vil bære frukter. Derfor ønsker vi å så raskt som mulig komme ut med et lite produktinkrement, eller lage noe som ligner produktet, slik at man kan komme i en god dialog med potensielle kunder. Lager man web-baserte tjenester “i skyen”, kan man gjennom smidig tankegang svært raskt komme i mål med et kjørbart, lite inkrement som man kan få noen interessert i å prøve. Om dette ikke er mulig kan man ty til prototyper av ulik art. Formålet med dette bør være å få mest mulig validert læring ut av innsatsen. Her vil blant annet tankegodset til Eric Ries med Lean Start-up være særlig relevant.

I utviklingsfasen gjelder det å gradvis bygge opp en organisasjon som er i stand til å levere de viktigste featurene til markedet. Dette er den fasen ren Scrum i utgangspuktet er laget for. Produkteier vet at de løpende vurderingene og prioriteringene han gjør vil være avgjørende for suksessen. Han vet også at han må jobbe hardt for å komme i dialog med de rette brukergruppene slik at han kan få god feedback på Sprint Reviewene. De som leverer på web, og som er i stand til å levere virkelig ofte, har muligheten til å teste ut nye ideer på markedet, og således få enda bedre feedback og beslutningsgrunnlag enn Sprint Reviewet vil kunne gi.

Innhøstingsfasen er det vi gjerne kaller vedlikeholdsfasen (jeg liker ikke helt det begrepet fordi dette arter seg veldig annerledes for programvareprodukter enn for fysiske produkter). I denne fasen vil fokus være på lave utgifter og høy inntjening. Det er jo her man skal høste fruktene av de to foregående fasene. Produkteier vil her fokusere mest på kost-nytte vurderinger. Mange vil ha SLA-avtaler som til en hviss grad regulerer prioriteringene som gjøres. Enkelte opplever mye bug-fix i denne fasen og da vil man lett komme i en “brannslukningsmodus” som gjør at Scrum fungerer dårlig. Man klarer rett og slett ikke å planlegge særlig store deler av neste Sprint. Kanban fungerer nok da bedre.

Modenhet

Smidig modenhet er i denne sammenheng et ganske meningsfullt begrep. Det er stor forskjell på å være produkteier der kulturen er tradisjonell/konservativ og der endringsviljen er stor. Det er stor forskjell på å operere i et miljø som har årlige leveranser, kontra firmaer som leverer ukentlig eller oftere. Dette er det også viktig å ta høyde for når man velger verktøy fra verktøykassa.

De med høy smidig modenhet leverer ofte, og er satt opp med stor grad av selvorganisering. Disse tingene henger sammen, det er vanskelig å tenke seg svært hyppige leveranser i et tradisjonelt, kommandoorientert selskap.

De med lav modenhet vil måtte fokusere på Release Planning og Road Map, samt å hente så mye og god feedback som mulig på Sprint Reviewer. Her vil også Produkteier måtte jobbe tett sammen med Scrum Master og fjerne organisasjonsmessige hindringer. En god produkteier vil evangelisere for hyppigere releaser, læring underveis og å innarbeide mer selvorganiserende arbeidsform.
De som har høy modenhet vil kunne fokusere på mer “avanserte” teknikker og metoder som A/B testing, Innovation accounting, MVP osv.

Kompleksitet

Det er stor forskjell på å kjøre komplekse og enkle prosjekter. I IT-bransjen finnes det faktisk en del forholdsvis enkle prosjekter. Dette kan være installasjon og tilpasning av standardsystemer som Visma eller SAP. Her kan tradisjonell, planorientert tenkning fungere fint. Andre er mer kompliserte, men allikevel ikke i det komplekse området i Cynefin modellen. Her kan det også fungere OK med en ganske tradisjonell tilnærming, gjerne kombinert med Kanban for å gradvis optimalisere. Men i det komplekse området er det selvorganisering og løpende læring som gjelder. Hvordan få validert løsninger og funksjoner raskest mulig, blir da spørsmålet. Scrum er skreddersydd her.

Statens Smidige Standardavtale

Jeg har levert kommentarer til Difis nye utkast til smidig standardavtale SSA-S.

Og jeg har startet en linkedin gruppe for å diskutere dette.

Og jeg har deltatt på et XP-meetup der vi presenterte synspunkter og ikke minst debatterte avtalen.

Dette har vært en interessant modningsprosess for meg. Dessuten er dette potensielt svært viktig for hele IT-bransjen m/kunder som sårt trenger til Smidig.

Jeg har hatt to fokusområder i denne prosessen:

1. Hvordan kan et slikt dokument øke sannsynligheten for at offentlige IT-prosjekter skaper mer verdi for pengene enn i dag.

2. Et slikt dokument vil ha definisjonsmakt og vil av enkelte bli brukt som en slags lærebok i smidig. Hvordan sikrer vi at teksten fremstår som pedagogisk og “riktig” i forhold til Agile Manifesto? Har skrevet litt om “riktig smidig” her.

Hvis du er interessert kan du lese kommentarene her: Høring SSA-S

 

Vitenskapelig om teamarbeid

Harvard Business Review publiserte en usedvanlig interessant artikkel kalt The New Science of Building Great Teams  her om dagen. Forfatteren er Alex “Sandy” Pentland, professor ved MIT, og director of MIT’s Human Dynamics Laboratory.

Målinger

De har utstyrt medarbeidere i en mengde team av forskjellige typer med “sosiometriske sensorer”, og målt en rekke parametere som kan fortelle hvordan folk interagerer med hverandre. Dette er ting som:

* Stemmehøyde og stemmeleie
* Kroppens posisjon og retning i forhold til hverandre
* Kroppsspråk og fakter

Deretter visualiserer de dataene og ser etter mønstre. Og ikke minst ser de etter forskjellene mellom vellykkede team og mindre vellykkede team. Resultatene er mildt sagt interessante!

Energi og Engasjement

Illustrasjonene i artikkelen er utvetydige. De vellykkede teamene har et balansert energinivå og engasjementnivå  mellom teamdeltagerne. Enkelt sagt er energinivået graden av inflytelse et individ har, mens engasjementnivå står for mengden av interaksjon mellom teamdeltagere.

I det beste teamet er det tydelig at alle sammen interagerer med hverandre, og de har et like stort engasjement. Forskerne på MIT har funnet ut at dette helt entydig kjennetegner de beste teamene. Og det er verd og merke seg at et balansert, lavt energi- og engasjementnivå er bedre enn et høyt, men ujevnt nivå. I det nest beste teamet er alle like engasjert, men her ser vi at enkelte teammedlemmer interagerer mye med de andre, mens andre har svært lite med de andre å gjøre. Vi aner her et team med en leder/ledelse som er et slags team i teamet. Artikkelen viser at slike team ikke er særlig vellykkede. Det dårligste teamet har samme ubalansen i interaksjonen og i tillegg svært ulik energi (illustrert med størrelsen på ikonet).

Utforskning

I tillegg til energi og engasjement måler forskerne graden av utforskning (Exploration). Datavisualiseringen i artikkelen viser hvordan enkelte team har mye uformell interaksjon ut av teamene, mens andre har lite. Denne uformelle utforskningen er også udelt positiv i følge MIT.

Former for kommunikasjon

Disse studiene har også bekreftet det vi vet, at muntlig kommunikasjon og samlokalisering er smart.

The most valuable form of communication is face-to-face. The next most valuable is by phone or videoconference, but with a caveat: Those technolo- gies become less effective as more people participate in the call or conference. The least valuable forms of communication are e-mail and texting.

De nevner ikke en gang kommunikasjonsformen som fremdeles er rådende i IT-bransjen, nemlig å putte tekst inn i dokumenter og så sende hele dokumentet – og håpe det beste.

Individuelle egenskaper

In fact, we’ve found patterns of communication to be the most important predictor of a team’s success. Not only that, but they are as significant as all the other factors —individual intelligence, personality, skill, and the substance of discussions—combined.

For oss som tror på teamarbeid framfor  individuelt arbeid er dette gode nyheter.

En god “team player”?

Så, skal vi ta denne artikkelen på alvor, kanskje vi skal se nærmere på både ansettelsesrutinene og måten vi utvikler medarbeidere på. Hva er det som kjennetegner den ideelle teamorienterte medarbeideren?

In both productivity- focused and creativity-focused teams, we have discovered the data signature of what we consider the best type of team member. Some might call these individuals “natural leaders.” We call them “charismatic connectors.”

Hmmm skal vi nå bare ansette karismatiske personer? Hvor mange slike finner vi i IT-bransjen i Norge tro? Nei, heldigvis er det enklere enn som så:

Badge data show that these people circulate actively, engaging people in short, high-energy conversations. They are democratic with their time—communicating with everyone equally and making sure all team members get a chance to contribute. They’re not necessarily extroverts, although they feel comfortable approaching other people. They listen as much as or more than they talk and are usually very engaged with whomever they’re listening to. We call it “energized but focused listening.”

Artikkelen viser også at man kan aktivt bruke slike målinger for å “optimalisere organisasjonen”. Om man utstyrer de ansatte med slike instrumenter kan man finne ut av hvordan team fungerer og så gjøre visse grep der det er svakheter. Lurer litt på hvordan datatilsyn og fagforedninger her i landet ville stille seg til dette? Uansett, spennende forskning som bør kunne gi smidigentusiaster verden over vann på mølla i argumentasjonen for å bekjempe “handover”.

 

• 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)