Den aller viktigste faktoren…

Jeg har diskutert “kvalitet” i det siste, blant annet på Sikkerhet og kvalitet i din utviklingsprosess hos DnD i Bergen. Hva er det som fører til produkter med ypperste kvalitet?

Jeg tenker ikke her å definere kvalitet, i denne sammenhengen holder det lenge med ordet slik vi bruker det i dagligtale. Når jeg holder kurs og foredrag åpner jeg gjerne med å spørre deltagerne om hvilken ene faktor som betyr mest for å ende opp med høy kvalitet på produktene. Svarene jeg får er gjerne slikt som:

• Godt håndtverk
• Tett samarbeid med brukerne
• God nok tid til å gjøre jobben skikkelig
• Gode testere
• Flinke folk
• De som gjør jobben bryr seg
• Godt team-arbeid
• osv..

Gode poenger alt dette – en fin liste med viktige faktorer. Men jeg har en klar favoritt:

• De som gjør jobben bryr seg

Om de som skal lage produktet virkelig bryr seg om sluttresultatet er mye gjort! Etter mitt skjønn må dette være den aller mest grunnleggende og betydningsfulle faktoren.

Jeg forteller gjerne historien om filosofen og steinhuggerne som jeg hørte av Mary Poppendieck for mange år siden. Den går omtrent sånn:

En filosof gikk tur i fjellene og traff på tre menn som sto og hugget i stein med store hakker. Han går bort til den ene og sier: “Hei der, hva holder du på med?” Svaret er kort og ganske bryskt: “Er du blind, ser du ikke at jeg hogger i stein?” Filosofen går videre til nestemann og sier det samme: ”Hei der, hva holder du på med?” Denne gangen får ha en annet svar: “Jeg står her og tjener til livets opphold, jeg har en famile nede i dalen som trenger mat”. Hmmm. Et helt annet perspektiv på den samme jobben tenker filosofen. Han går så bort til tredjemann og spør det samme: ”Hei der, hva holder du på med?” Og nå får han et tredje svar: “Jeg bygger en katedral!” Samme jobben men nå et tredje perspektiv! Her kan vi spørre oss: Hvem av disse tre vil lete etter de beste steinene? Et retorisk spørsmål selvsagt.

Har du overvekt av steinhuggere, eller katedralbyggere i din organisasjon?

Katedralbyggerne vil anstrenge seg og yte det lille ekstra for at produktet skal bli bra og brukerne fornøyd. Jeg tror vi trenger noen katedralbyggere i alle organisasjoner og team, for å lage bra saker. Jeg ser for meg at katedralbyggeren insisterer på å ikke ofre det gode håndtverket, selv om slutterminen nærmer seg faretruende fort og alle fornemmer at nå er det tid som er pri 1, 2 og 3. Mer om dette her.

Så hva slags forhold har folk til de produktene de jobber med? Bryr de seg om det? Liker de det? Elsker de det, kanskje? Det kan være verd å jobbe litt med dette, om det betyr mye for kvaliteten, ikke sant?

Olaf Lewitz og Dirk Bartels hadde en workshop i idealo Internet GmbH der målet var å undersøke dette. Hva legger folk i utsagnet “I Love my Product”? Hva legger de i “Love” og hva legger de i “Product”?

I følge Olaf medførte dette til et stort engasjement og ikke minst at hver og en virkelig tenkte igjennom hva som betyr noe når det gjelder de produktene de lager. Det dreier seg om følelser. Og følelser er kanskje ikke det vi snakker mest om? Eller naturligst om… Kanskje det nettopp derfor kan være lurt å gjennomføre en workshop med enkle retningslinjer og fasilitering?

 

 Så: Hvilke følelser trigger ditt produkt hos deg? 

 

Slutterminer

Vi må leve med “harde” tidsfrister for når ting må være ferdig. Så det gjelder å ha en god strategi på hvordan vi håndterer dette, enten vi kjører tradisjonelt eller smidig. Som vanlig har smidig tilnæring noen fortrinn. Det finnes gode og dårlige begrunnelser for å sette tidsfrister. 

Dårlig motiverte tidsfrister

Mange mener det er motiverende og gir et sundt fokus å sette milepæler å jobbe mot. Man setter derfor frister som strengt tatt er unødvendige. Psykologen  Dr. Leslie Becker-Phelps skriver om dette i artikkelen How deadlines can be murder on motivation; hvordan kunstige slutterminer er begrenset til å gi ytre (ekstrinsisk) motivasjon, og at dette vil gå på bekostning av indre (intrinsisk) motivasjon. Den helhjertede, indre motivasjonen er det vi egentlig er ute etter mens – som Becker-Phelbs skriver – sluttermin-motivasjonen lett utvikler seg i helt feil retning og faktisk blir en de-motivator. Lystbetont arbeid som man i utgangspunktet setter stor pris på, kan gradvis utvikle seg i negativ retning, da det ikke lenger er lyst som er drivkraften, men snarere plikt eller i verste fall frykt for å mislykkes.

Programvareprosjekter styres ofte mot slutterminer som ikke alltid er velbegrunnede. Fristen er ofte satt av prosjektlederen i samråd med kunden og er ment som en slags forsikring om at leveransen ikke skal “trekke ut i tid”. Ofte avtaler de stilletiende en “hemmelig buffer” på slutten, slik at den reelle tidsfristen egentlig er senere (“vi har jo dårlig erfaring med slike programmeringsprosjekter”). Tanken er at slutterminen blir et styringsredskap basert på tidlige estimater.

Tidsfrister med fast omfang

Vi er vant med å se på omfanget av en leveranse som absolutt. Dette er naturlig, for det er jo slik det er i dagliglivet og i veldig mange prosjekter vi kan observere. Entrepenøren leverer hele broen, ikke bare deler av den. Vi klipper snorer og spretter (eller knuser) champagneflasker for å markere overlevering.

Vi har gjentatt dette til det kjedsommelige: Programvare er ikke det samme som å lage en bygning eller en “ting” som utgjør en opplagt leveranse. Programvare er nesten alltid gjenstand for en mer eller mindre kontinuerlig utvikling – en evolusjon. Tidsfrist mot en hovedleveranse er derfor unødvendig. Ikke bare er det unødvendig, men det er direkte skadelg! Alle som har vært med på slikt vet at stressnivået stiger voldsomt mot leveransetidspunktet. Og det er selvsagt i denne tilstanden, når tiden begynner å bli den altoverskyggende parameteren vi styrer etter, at vi ofrer det gode håndtverket. Vi tester det vi får tid til å teste, dokumenterer lite, får ikke tid til refactoring, selv om alle ser at det burde vært gjort. Vi lapper alt sammen etter beste evne og håper det beste. En uslåelig måte å maksimalisere dette stressnivået er å knytte dagbøter til slutterminen. Da kan du som kunde være helt trygg på at du må slite med anseelige mengder teknisk gjeld i systemet i årevis etter denne datoen.

Smidige slutterminer

Det er rikelig med gode eksempler på at harde terminer har sin berettigelse. Regnskapssystemer må gjerne leveres i ny versjon i forbindelse med årsavslutning. Andre systemer lages for å støtte et arrangement (OL på Lillehammer var en rimelig hard milepæl), og det er forhold som at markedsvinduet snart lukker seg, som gjør at vi trenger en absolutt frist. Så dette må vi takle.

Spørsmålet blir da: “hvordan kan vi styre mot en absolutt tidsfrist, uten å ende i dette uføret der stressnivået øker så mye at vi kaster det gode håndtverket over bord?”

I Scrum styrer vi med variabelt omfang (scope). Så lenge omfanget er variabelt, kan vi holde tid, kost og kvalitet fast. Hvilke implikasjoner har dette? Jo, det har flere, men først og fremst innebærer det at vi kan beholde roen og fokusere på det viktigste, nemlig å gi brukerne og interessentene mest mulig verdi uten å ofre langsiktig kvalitet.

Omfanget ligger altså i en kø med arbeid kalt produktkø, som til enhver tid er prioritert. De ulike elementene er også grovestimert. På denne måten kan vi vurdere de ulike elementene opp mot hverandre og etter hvert som vi nærmer oss slutterminen blir det tydeligere og tydeligere hva som vil komme med.

For at produktkøen skal bli et godt styringsredskap er det selvsagt viktig at vi har en formening om framdriften. Dette får vi gjennom å jobbe i korte iterasjoner og ved at vi grovestimerer produktkøelementene. Bruk gjerne relative størrelsestall på elementene, slik at vi kan skaffe oss empiri knyttet til hvor mange av disse tallene dette teamet i gjennomsnitt leverer i en iterasjon. Planning Poker er en fin teknikk for dette som sikrer at et helt team gjennom en strukturert prosess kommer fram til en felles forståelse av et element og et tall som representerer estimatet. Dette kalles ofte et Story Point.

Fordelen med denne styringsformen er at fokus hele tiden er på “hva er det aller viktigste i dette omfanget”. Det blir helt klart for kunden at han må engasjere seg i denne løpende prioriteringen og bidra til at prosjektet gjør gode valg.

På denne måten vil vi ofte ende opp med et ganske minimalistisk system som har visse mangler. (Vi vil fremdeles estimere feil og vi er fremdeles notoriske optimister, så jeg tror ikke vi skal ha illusjoner om at estimatene vil være veldig nøyaktige.) Så vi kan sette i drift et system som har verdi og som gjør jobben, men som alle vet må videreutvikles senere.

Hovedgevinstene ved variabelt omfang:

1. Vi unngår det høye stressnivået som forleder oss til å ofre kvalitet og tolerere teknisk gjeld.
2. Systemet blir enkelt og ukomplisert der manglene i systemet er et resultat av bevisste valg.

 

 

 

Systemtest

Gitt at
* 10.000 Nordmenn er så syke at de er arbeidsuføre av en mystisk og uklar sykdom og
* ingen har noen kur eller noen god forklaring på årsaken og
* Norske forskere oppdager et stoff som gjør én person frisk og
* de samme forskerne gjennomfører studie på 30 personer der ⅔ av pasientene (som ikke får placebo) får en svært positiv effekt og
* det er godt håp om at denne forskningen kan lede til kunnskap om årsaken til sykdommen.
Når
* de samme forskerne søker om (skarve) 9 MNOK for starte ny, større studie for å forske videre på denne hypotesen og når
* denne søknaden er gjennomarbeidet og formelt korrekt
Så
* skal de få et klart JA fra Norsk Forskningsråd.

Mange slike systemtestbekrivelser gir et rimelig innlysende resultat. Dette er en no-brainer tenker du kanskje. Men ikke så rask der. La oss kjøre denne testen med ME som sykdom, Fluge og Mella på Haukeland sykehus er forskerne og stoffet er Rituximab. Da feiler Systemet! Svaret fra forskningsrådet blir utrolig nok NEI. Hva går galt? Her må noen fram med den store debuggeren…

Crowdfunding som alternativ

Maria Gjerpe er ikke den som venter på at Systemet skal begynne å fungere. Hun er utdannet lege, har selv ME og har vært så heldig at hun har fått være pilotpasient på Rituximab, med veldig god effekt. Hun bruker nå all sin nyvunne energi på initiativet MEandYouFoundation for å finne penger til videre forskning.

Vil du være med og støtte med 200 kr? Send MEANDYOU 200 til 2377

Folk bryr seg! I skrivende stund har allerede over 500.000 kroner kommet inn!

            

 

Det nye testamentet…

Tilsvar til “Det nye testamentet” av Peter Hidas

Peter Hidas reagerer ganske sterkt på artikkelen min kalt “Smidig villfarelse i offentlig sektor” og harselerer på ”Peters Plass” med at jeg fremstår som en slags religiøs predikant med agile manifesto som bibel. Det er greit. Alle som jobber for å endre verden vet at litt provokativ evangelisering må til for å lokke frem reaksjoner. Agile Manifesto ble skrevet for å endre verden – i hvert fall den delen av verden som dreier seg om programvareutvikling.

Om prosjektstyring

Hidas spør: ”er det virkelig sånn at prosjektstyring er uten verdi?” Nei, det mener jeg selvsagt ikke. Prosjektstyring må til for å løse veldig mange av samfunnets store oppgaver. Det jeg mener er at prosjektstyring ikke er formålstjenlig når vi har kompleksitet og usikkerhet. Er det tilstrekkelig av dette vil prosjektstyring ikke bare være verdiløst, men også direkte skadelig.

I Scrum er det ingen prosjektleder og det er selvsagt bevisst. Scrum er helt eksplisitt laget for å håndtere kompleksitet og usikkerhet. Om man leser Scrumguiden eller Agile Atlas blir det tydelig at vi trenger tre og bare tre roller: Produkteier (som utvikler og prioriterer kravene), Scrum Master (som er en ”prosesscoach”) og Utviklingsteamet (som er ansvarlig, tverrfunksjonelt og selvorganiserende). Dette utgjør et fint balansert team som i tett samarbeide med interessentene har alt som skal til for å lage veldig gode produkter. En prosjektleder midt oppe i dette vil ødelegge denne balansen og veldig lett redusere ansvarsfølelsen til utviklingsteamet.

Om smidigforståelse

Jeg har lest Hidas i mange år, og det er tydelig at han etter hvert har fått en ganske god forståelse av smidig. Men han roter det til når han påstår at ”scope creep” er vanlig i smidig. ”Scope creep” er tvert i mot et stort problem som smidig er designet for å løse! Får du dette med Scrum er du sikker på at du ikke gjør det helt riktig…

Det virker som alle er for smidig for tiden. ”Vi vil ha smidig, bare vi ikke trenger å endre på noe særlig” synes å være innstillingen mange steder. Og her er vi ved selve kjernen av problemet. Agile Manifesto var ment som en utfordring til det bestående. De aller fleste steder må det en radikal endring til.

Jeg blir bekymret for den allmene forståelsen av begrepet smidig når jeg ser smidig-initiativene som kommer fra det vi kan kalle ”prosjektstyringsmiljøet”. Disse har opplagt ingen ting å tjene på smidig, og det går da som det må gå: Vi får en blodfattig, tannløs smidig som ikke vil gi noen særlig positiv effekt. Problemet er at det ofte kan gi en viss liten positiv effekt, men langt unna potensialet. Når DIFI lager ny prosjektveiviser kaller de inn det norske prosjektstyringsmiljøet som rådgivere – og resultatet blir deretter. Jeg håper som tidligere sagt at DIFI lytter til andre når de tar fatt på 3.0 versjonen. Det er kanskje ikke så veldig store endringer som skal til. Jeg har ikke problemer med de to første fasene, Konsept og Planlegging. Hovedproblemet er at Gevinstrealiseringen kommer til slutt. Dette må skje løpende om smidig skal ha noen mening.

Om offentlig sektor

Jeg følger Hidas rundt de kulturelle utfordringene i offentlig sektor: ”Offentlig sektor er hierarkisk, ansvaret er vertikalt fordelt, lag på lag” og ”Noen må styre og styringshierarkiet må respekteres”. Mulig dette er sannheter som er så urokkelig at ordentlig smidig er en illusjon. Jeg håper virkelig ikke det! Som skattebetalere synes jeg ikke vi skal sitte og se på at det offentlige kaster IT-kroner ut av vinduet, bare fordi ”kulturen er sånn”. Når du plasserer ”Gevinstrealisering” på slutten av prosjektet innebærer det  også at du sitter med alt for mye av risikoen på slutten; Akkurat der du ikke vil ha den. Det er slik tankegang som fører til at interessentene blir overrasket over at nødnettet ikke fungerer innendørs, helt på tampen av prosjektet.

 

Scrum på norsk

Endelig er alle de viktigste Scrum-kildene å få tak i på norsk.

Vi har oversatt Scrum Guiden som ligger på Scrum.org, Ken Schwaber og Jeff Sutherland sitt nettsted.

Nå er også Core Scrum på Scrum Alliance´s Agile Atlas oversatt.

Begge disse dokumentene er kortfattede beskrivelser av hva Scrum er. Henholdsvis 16 og 9 sider. Beskrivelsene er overlappende og de er ikke motstridende på noe måte, men de fokuserer på litt ulike ting.

Norsk Wikipedia er også oppdatert med henvisning til disse dokumentene.

Agile Manifesto har allerede i noen år vært å finne på Norsk.

 

Smidig villfarelse i offentlig sektor

Artikkelen ble publisert i Norsk Computerworld 1 Februar 2013

Det er nå ganske nøyaktig 12 år siden Agile manifesto for software development (agilemanifesto.org) ble signert og lansert. Tanken var at programvareutvikling må basere seg på en helt annen virkelighetsoppfatning enn den rådende.

Selv har jeg jobbet med agile (eller smidig som vi kaller det på norsk) på heltid siden 2005. Manifestet har hele tiden ligget i bunn. Manifestet er svært kortfattet og består av 4 verdisetninger og 12 prinsipper som kan leses og forstås overordnet på et par minutter. Men for å forstå grunntankene her må man selvsagt fordype seg i emnet. Dette kan man for eksempel gjøre ved å følge et utvalg av de 17 som i sin tid signerte. De fleste har jo skrevet bøker, blogget, diskutert og foredratt om temaet. Og selvsagt blir forståelsen gjenstand for modning etter hvert som man vinner erfaring. I 2013 er erfaringsgrunnlaget enormt, siden smidig i store deler av IT-bransjen har blir en ad-hoc standard.
Rett før jul lanserte DIFI “Prosjektveiviseren 2.0” som skal “støtte smidig” og som har et eget smidig-kapittel. Jeg gikk inn her forleden og det første som fanget oppmerksomheten min var en punktliste midt på siden. Her var det mye bra!

Begrepet «smidig» favner om flere metoder, med noe ulikt fokus. Enig!

Smidige metoder bør imidlertid ha følgende definerende egenskaper:

1. Virksomhetsverdi er det viktigste kriteriet for kvalitet og målstyring. Høres bra ut, selv om jeg ikke helt forstår hva Virksomhetsverdi betyr.
2. Kontinuerlig prioritering av funksjonalitet ut fra kost/nytte. Flott!
3. Tett dialog mellom forretning, brukerinteresser og utviklere. Nå snakker vi!
4. Korte iterasjoner/sprinter med leveranse av kjørbar kode. OK bra. Men hva er egentlig kjørbar kode..?
5. Hyppige leveranser til produksjonssetting. ”… til produksjonssetting”?? Hva betyr dette?
6. Forpliktende beslutninger tas så sent som mulig (rullerende planlegging). I Like!
7. Evaluering, læring og forbedring underveis. Veldig bra!
8. Autonomi: Selvorganiserende, tverrfaglige team. Supersmidig, jo!
9. Fjern overflødig arbeid. Veldig bra!

Det var da jeg tenkte at jeg skulle skrive en positivt ladet artikkel om smidig forståelse for en gangs skyld. Dette her lover jo veldig bra – selv om det er 2-3 litt svake formuleringer så er helhetsinntrykket langt bedre enn jeg noen gang har sett fra offentlig forvaltning og “prosjektstyringsmiljøet”.

Men vent nå litt. Hva signaliserer prosessmodellen øverst på siden? Dette ser da ut som en god gammeldags vannfallsmodell? Har de glemt å oppdatere figuren? Eller har de virkelig tenkt å vente med gevistrealiseringen til hele prosjektet er ferdig? Har de virkelig tenkt å la risikoen akkumulere seg opp på godt gammeldags vis? Hvorfor snakker de om smidig i det hele tatt her? Jeg begynner å forstå punktene 4 og 5 i lista over. Det står kjørbar kode og ikke kjørende kode. Det står ikke noe om å levere ofte!

Det blir verre. Alle fasene har et smidig-kapittel så jeg klikker meg inn på “Smidig i konseptfasen” og leser: “Denne fasen – som alle andre faser i PRINCE2®-modellen – kan organiseres i sprinter for leveranser i henhold til smidige metoder.” OK. Skjønner. Det blir liksom smidig av å kjøre alle fasene i iterasjoner. Huff! Fullstendig misforstått, det vi trenger er Empirisk Prosesskontroll.

Skuffelsen er stor, selvsagt. Nok en gang et initiativ som er egnet til å vanne ut forståelsen av smidig. Nok en gang et initiativ tatt av prosjektstyringsmiljøet der de i praksis tar avstand fra de virkelig grunnleggende “nye” tankene i agile manifesto. Nok en gang et initiativ som ikke kommer til å ta bedre vare på skattebetalernes penger i noen særlig grad. Selv om intensjonene virker ganske gode opplever vi igjen at misoppfattelsene fremdeles florerer og at noen helt sentrale egenskaper ved smidig utelates. Å lage kjørbar kode i hver Sprint vil dessverre ikke gi mye læring underveis. Å kjøre Sprinter i de ulike fasene får det kanskje til å “virke smidig”, men er fullstendig misforstått. Det er ikke faser i “ordentlig smidig”.

Hva er så grunnen til at alle “smidige” initiativ i offentlig sektor feiler (kan her nevne PS2000 sin smidige veileder, DIFIs SSA-S, Danske Digitaliseringsstyrelsens K03)? Misforstår de med vilje, eller har de ikke brydd seg med å sette seg skikkelig inn i Agile Manifesto? Ønsker de kanskje en annen definisjon av smidig, som ikke er så “krevende” kanskje? En som gjør at prosjektstyringsparadimet fremdeles gjelder? For de som ikke er klar over det – smidig har et annet virkelighetsbilde i bunnen enn tradisjonell organisering og styring. Den første setningen i Agile Manifesto lyder: People and Interactions over processes and tools. Setningen i seg selv sier kanskje ikke så mye, men om man investerer noe tid i å følge de som står bak manifestet (Tips: start på agileatlas.org) vil man oppdage at det ligger mye substans her. Samtlige av de 17 opphavsmennene vil i en eller annen form hevde at fokus må vekk fra prosjektstyring og over på de som skaper verdier. De utviklerne, designerne og testerne som skal gjøre jobben må få tillit, få selvorganisere og gjøre håndtverket sitt etter en høy standard. Og de må få levere tidlig og ofte. Programvareutvikling handler også i offentlig sektor om læring underveis – og da må vi få rask og validert feedback på det arbeidet som gjøres.

Jeg tror “ordentlig smidig” vil tvinge seg fram, også i offentlig sektor. Såpass overlegent er det. Men for at det skal skje må DIFI og andre fordype seg i faget. Og de må slutte å kun alliere seg med prosjektledere og de store konsulenthusene. Disse representerer på mange måter fortiden og mange er ikke tjent med noe paradigmeskifte. Smidig truer jo posisjonen til hele prosjektstyringsmiljøet. Jeg håper arbeidet med prosjektveilederen 3.0 starter snart. Da må DIFI snakke mye mer med med utviklerne. Det er de som vet hvor skoen trykker og DIFI vil da få andre svar. Er det en ting vi har lært de siste 12 årene er det at har du motiverte, kompetente, erfarne utviklere som får anledning til å ta håndtverket sitt på største alvor vil mye være gjort.

5 smidige prinsipper for å bli best

Spørsmål: Hva skiller de beste fra de middelmådige?

Smidig produktutvikling er ikke basert på en veldefinert prosess som vi følger slavisk.  Nei, smidig er tvert imot basert på tilpasningsdyktighet og kontinuerlig forbedring. Den prosessen vi følger i dag er ikke nødvendigvis den beste i morgen. Hovedtanken er kontinuerlig å samle erfaring, lytte til markedet og å gjøre små endringer i måten vi løser problemer på. I Scrum kaller vi det gjerne  “inspect and adapt”; Prosessen er i kontinuerlig utvikling.

Hva er det i Scrum som hjelper oss til kontinuerlig tilpasning og forbedring? Her vil mange med Scrum-opplæring svare Retrospectiver! Dette er ikke feil, men det er langt flere mekanismer som stimulerer til dette i Scrum. Og tro meg, det å gjennomføre retrospectiver “etter boka” fører ikke nødvendigvis til denne utviklingen.

Her følger 5 prinsipper man kan velge å følge om man virkelig ønsker å hele tiden forbedre seg:

1. Jobben gjøres i ansvarlige, tverrfaglige team
2. Ta Scrum Master rollen på alvor
3. Jobb i korte iterasjoner med hyppige leveranser
4. Sørg for tett samarbeid mellom produkteier og utviklingsteamet
5. Gjennomfør helhjertede Retrospectiver

I denne rekkefølgen. Retrospectiver kommer nederst på denne listen…

Ansvarlige, tverrfaglige team

Det er ingen tvil i Scrum – de som gjør jobben må få myndighet til å beslutte hvordan jobben skal gjøres – selvsagt innenfor gitte, tydelige rammer. Alt er basert på et grunnleggende positivt menneskesyn (theory Y) nemlig at folk er grunnleggende konstruktive og motiverte – gitt at de får tillit. Folk ønsker å gjøre en god jobb – å bidra til en større helhet.

Jobben gjøres i selvorganiserende team, hvilket innebærer at vi må våge å stole på at teamene løser problemene slik de selv finner best. Teamene må selvsagt ha all den nødvendige kunnskapen og ferdighetene som skal til for å utvikle gode løsninger. Når vi legger til at disse teamene får jobbe tett på markedet/kunden og stadig er i dialog med disse, vil vi kunne ende opp med team som har et fantastisk eierskap til jobben og som vil være genuint interessert i å gjøre en bedre og bedre jobb. Når dette prinsippet er på plass, vil veldig mye løse seg!

Scrum Master rollen

Et selvorganisert team skal ikke styres, men samtidig vet vi at det kan være svært krevende å få en gruppe med mennesker til å danne et velfungerende team med et brennende, kollektivt eierskap til jobben sin. Derfor trenger vi Scrum Master-rollen som er en person som jobber tett på teamet, men ikke er en del av teamet. En god Scrum Master er en menneskekjenner som vet noe om gruppedynamikk og teambygging, er en tilrettelegger og fasilitator, kan noe om coaching, og vet når det er riktig å utfordre Status Quo. Det er vanskelig å være en god Scrum Master om du befinner deg midt i teamet – og er en integrert del av prosessen. Du må faktisk ha en viss avstand for å gjøre gode observasjoner og evne å sette fingern på ting som kan forbedres. (Les gjerne mer om coaching av Scrum team her: )

Ofte vil teamet finne hindringer i organisasjonen de er en del av. Dette kan være i ledelsen, i andre avdelinger eller hos eksterne interessenter, altså steder som er utenfor teamets myndighet. Da er det helt vesentlig at Scrum Master tar med seg disse hindringene og snakker med de det gjelder og forsøker analysere ende-til-ende prosessene med tanke på å fjerne hindringer. Gjør gjerne dette i tverrfaglige workshops, eller inviter dem med i retrospectiver. Gode Scrum Mastere våger å utfordre!

Hyppige leveranser

Jeg har jobbet med faget prosessforbedring siden tidlig 90-tall, og den desidert største hindringen for å oppnå kontinuerlig forbedring var alltid mangel på feedback. Vi fikk kunnskap om hvor god jobb vi hadde gjort på et alt for sent tidspunkt, og dessuten var feedbacken ofte knyttet til en diger leveranse som gjorde det nær umulig å trekke noen konklusjoner. Årsak og virkning ble utvisket og vi var henvist til gjetning når vi skulle forbedre oss. Alt dette blir ekstremt mye bedre når vi klarte å dele opp leveransen i småbiter, levere ofte og få rask feedback. Dette er for meg så innlysende og grunnleggende at jeg kan glemme å presisere det når jeg holder kurs eller coacher.

Et godt team lager funksjonalitet som oppleves verdifullt i hvert inkrement. På den måten får vi alltid verdifull feedback og læring mens vi utvikler produktet.

Det tette samarbeidet mellom produkteier og utviklingsteamet

Scrum er basert på empirisk prosesskontroll og designet for å forhindre sub-optimalisering. Derfor er selve definisjonen av rollene i Scrum veldig tydelig: Scrum Teamet består av 3 og bare 3 roller: Produkteier, Utviklingsteamet og Scrum Master. Det er helt vesentlig at hele Scrum Teamet har en “vi-følelse” og aktivt bygge ned den tradisjonelle kløften mellom forretningssiden og IT-siden. Produkteier må virkelig representere forretningssiden – og ikke bare være en slags stedfortreder.

I gode Scrum team har produkteier jevnlig kontakt med utviklingsteamet (gjerne i forb med daglige scrummøter), de jobber jevnlig (ukentlig fungerer som regel godt) sammen med Product Backlogen der elementer estimeres, bearbeides og stykkes opp i mindre biter. Hver gang større produktikrementer planlegges, vil produkteier kommunisere visjonen til utviklingsteamet og jobbe sammen med dem i workshops for å utarbeide de nødvendige elementene (gjerne i form av User Stories).

Så, når denne kollektive vi-følelsen er på plass vil også utviklingsteamet fatte interesse for de virkelige, forretningsmessige problemstillingene man står overfor når de forsøker å finne bedre egnede metoder og teknikker. Jeg ser desverre svært sjelden at dette tette samarbeidet er på plass. Svært ofte er situasjonen motsatt: Produkteier er oppgitt over at utviklingsteamet ikke holder det de lover, utviklingsteamet skylder på at produkteier ikke var tydelig nok når han beskrev eller fortalte dem hva de skulle lage. Og sist men ikke minst: Retrospectivene blir innadvendte og forbedringene man diskuterer er ikke fundamentert i virkelige problemer. Det blir synsing og akademiske diskusjoner om hvilke teknikker som er best. Jeg kaller dette gjerne systematisk sub-optimalisering.

Retrospectiver

Så, til slutt, er det selve retrospective-møtet. Et vellykket retrospective er ikke i særlig grad avhengig av den prosessen som følges. Eller av de brainstormingsteknikkene man bruker. (Ikke noe feil med boka Agile Retrospectives av Diana Larsen og Ester Derby, men å følge denne prosessen er ikke nok!) Vellykketheten avhenger at punkt 1-4 over! Mangler ett av disse prinsippene vil retroen få begrenset nytteverdi.

Om teamet for eksempel mangler ansvarsfølelsen og eierkapet vil også disse møtene ganske snart ende opp i et kjedelig mønster. Et pliktløp. Og ting stagnerer.

Om de ikke har rett Scrum Master som brenner for sin del av jobben, våger å utfordre autoriteter og som evner å coache som en “servant leader”, vil også interessen for retrospectivene stagnere. Det er lite motiverende å oppleve at de finner hindringer, vedtar å forsøke å rette på disse, men ingen ting skjer…

Alt for få Scrum team leverer hvert produktinkrement. Dette kan vi ofte se på engasjementet i retrospectivene. Om alle vet at det som ble demonstrert på Sprint reviewet på langt nær var ferdig og skal igjennom vidreutvikling og debugging senere, har vi lite håndfast å snakke om på møtet. I team som leverer annenhver uke derimot, vil retrospectivene ta en helt annen form og vil ofte dreie seg om hvordan siste leveranse ble mottatt i markedet. Eller hvorfor en kritisk feil ikke ble detektert av kodereviewet.

Om produkteier ikke er interessert eller ikke en gang er invitert til retrospectivene vil møtene raskt gli over i en introvert, teknisk diskusjon som ikke er forankret i forretningsmessige forhold. Forandring er ikke nødvendigvis forbedring! Forbedring må resultere i en positiv effekt for hele organisasjonen.

 

Svaret på spørsmålet i innledningen blir da: De beste utfordrer kontinuerlig Status Quo gjennom å ta alle de 5 punktene på alvor!

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?

 

• En agile42 blogg

  

• Kurs

  • 04.06.13 Kanban Oslo
  • 10.06.2013 CSPO Oslo
  • 23.09.13 CSM Trondheim
  • 30.05.13 CSM Oslo
  • mer …

• Temaer

  Ansvarliggjøring Brukervennlighet Coaching DRM EVO eXtreme Programming fildeling forretningssiden forskning gruppedynamikk innovasjon ITIL Kanban kommunikasjon kompleksitet kontrakt kundeverdi kunnskapsdeling Kvalitet Lean ledelse ME opphavsrett organisasjon produkteier prosjektstyring saksbehandling Scrum ScrumBut sertifisering Smidig Styring systems thinking ulovlig fildeling

• Siste kommentarer

  • Det smidige hjørne » Den aller viktigste faktoren… on Slutterminer
  • Det smidige hjørne » Det nye testamentet on Smidig villfarelse i offentlig sektor
  • Det smidige hjørne » Smidig villfarelse i offentlig sektor on Empirisk prosesskontroll
  • Jonas Paul on Smidige motkrefter
  • Det smidige hjørne » 5 smidige prinsipper for å bli best on Empirisk prosesskontroll
  • Det smidige hjørne » Empirisk prosesskontroll on Et spørsmål om kompleksitet
  • Det smidige hjørne » Lokalt ansvar trumfer regelstyring on Gjøre det riktige, eller følge regelverket?

• Arkiv

  Select Month 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)