Om Scrum sertifisering
På tide med nye tall. Scrumalliance har nylig gått ut med statistikken basert på første halvår 2010. Enten man liker det eller ikke så er tallenes tale klare: Scrum sertifiseringen øker fortsatt!
Om vi tar den desidert største gruppen først så sier tallene at det per første halvår 2010 er ca 90.000 Certified Scrum Masters. Vi ser av grafen at økningen har vært ganske jevn.
*) 2010 tallet er kun for første halvår.
At dette er mest populært i Nordamerika er neppe noen bombe. Europa er en 
klar nummer to her. Og når vi sier Europa mener vi egentlig nord-vest Europa. UK og Skandinavia er et klart tyngdepunkt. Tyskland kommer, det samme gjør Holland, men de Skandinaviske landene holder stand som de med høyest tetthet av CSM’er (se innlegget “vi er verdens smidigste nasjon” http://scrummaster.no/?p=240.)
Scrumalliance jobber stadig med sertifiseringsregimet. Nytt av året er at Certified Scrum Professional kommer inn i stedet for Sertified Scrum Practitioner. (Forkortelsen er fremdeles CSP:))
Les med om sertifiseringen her: http://scrumalliance.org/scrum_certification
5 kjennetegn på de som lykkes med Scrum
I Norge er Scrum nå inne i en slags fase 2 der veldig mange veldig mange organisasjoner har vunnet erfaring. Jeg kommer stadig i kontakt med både ferske og gamle Scrummere og det er tydelig at langt fra alle har entydig gode resultater. Hva mener jeg så med “gode resultater”? Ikke helt enkelt å definere dette, og jeg er ikke i stand til å gi noen vitenskapelig holdbar definisjon. Jeg har ikke gjort systematiske undersøkelser, men bare notert meg inntrykk jeg har fått ved å snakke med folk og ved å observere organisasjoner der jeg er innleid som konsulent. Der team-deltagerne er entusiastiske og positive kan vi anta at dette har vært vellykket. Når jeg snakker med en mellomleder som er veldig fornlyd er det ikke like sikkert at erfarinegen er entydig positiv. Disse har en tendens til å skjønnmale situasjonen…
Uansett så har jeg mer eller mindre systematisk begynt å merke meg hva som skiller de som lykkes fra de andre. Hva er det som kjennetegner disse? Og like interessant – hva er det som kjennetegner de som mislykkes? Hva er avgjørende – er det hvordan de angriper problemet, eller er det Scrum i seg selv som ikke egner seg for alle?
Jeg har kommet fram til 5 avgjørende faktorer:
1. Ser de på Scrum som en endringsprosess?
2. Bruker de Scrum til å forbedre håndtverket?
3. Bruker de Scrum til å oppnå strategiske mål?
4. Ambisjoner og videre læring – fordyper de seg i Smidig systemutvikling?
5. Benytter de Lean tankegang?
1. Endringsprosess?
Erkjenner organisasjonen at Scrum innebærer en endringsprosess? Eller ser de på Scrum som en metodikk for gjelder for utviklingsavdelingen?
Alt for mange “driver med Scrum på IT-siden”, mens ledelsen og forretningssiden tenker tradisjonelt. Hvordan skal man da klare å dra maksimalt nytte av smidig systemutvikling? Om forretningssiden måles på antall nye features de klarer å produsere – vil de garantert mislykkes i å maksimalisere verdiskapningen for brukerne. Om ledelsen ikke er villige til å legge til rette for hyppige releaser, hvordan skal vi da klare å lage topp kvalitet? Mange av organisasjonene jeg møter mangler overordnede langsiktige målsetninger og vilje til å endre på annet enn “IT-siden”. Jeg snakket nylig med noen som hadde kjørt 35 Sprinter, men releaset kun årlig – og det forelå ingen konkrete planer om å øke release-takten…
2. Forbedre håndtverket?
Utnytter de iterasjonene til å stadig forbedre håndtverket? Utvikler de kunnskap systematisk?
Mange nøyer seg med Scrum “prosessen”. Med det mener jeg at de følger alle anbefalingene om 15 minutters morgenmøte, passe store team, faste sprintlengder, har Sprint review og retrospective osv.. Uten at de legger sjela si i retrospectivene! Er det mulig å bli skikkelig god i Scrum uten å ha en solid Definition of Done som stadig blir forbedret? Det er helt tydelig at de som blir gode er også raske til å prøve ut og adoptere ulike XP-teknikker som Parprogrammering, TDD, DDD; BDD, User Stories osv. På forretningssiden vokser det fram andre gode teknikker som Story Mapping, Pragmatic Personas etc.
3. Strategiske mål?
Har ledelsen et helhetlig syn på dette og setter seg mål for Scrum koblet til forretningsstrategien?
FINN.no har kommet virkelig langt – og jeg husker godt hvordan Scrum-innføring bare var et tiltak i et større program for å øke innovasjonsevnen. Schibsted presset på og var villige til å bruke mye krefter på dette. Når ledergruppe forstod at Scrum og Lean tankegang var skreddersydde verktøy for å oppnå de forretningsmessige målene ble det virkelig sving på sakene. Det er alt for få som har et godt svar når jeg spør ledelsen “Hvorfor Scrum?”
4. Ambisjoner om videre læring?
Ser vi en vilje/evne til å fordype seg i “Agile”?
Agile-begrepet er i stadig utvikling og det publiseres en mengde erfaringsbaserte nyvinninger i økende tempo. En ganske god indikator på evnen til å lykkes med Scrum er “læringsambisjonene”. Hvor mange leser bøker, går på konferanser og kurs, leser blogger og andre publikasjoner, deltar på diskusjonsfora eller deltar i lokale nettverk? I Osloområdet har vi er imponerende aktivt “smidig-miljø” som bidrar med små fokuserte kveldssmøter (lean meetup, XP meetup) og større konferanser. (se www.cantara.no og http://smidig2010.no/)
Begynn for eksempelt med Johannes Brodwalls utmerkede blogg:
http://johannesbrodwall.com/2010/05/02/six-ideas-that-improve-your-software-design/
5. Lean tankegang?
Benytter de Lean tankegang og prinsipper?
Dette har blitt en slags kjepphest for meg. Lean og Scrum går “hånd i hånd”. Mens Scrum er en maksimalt enkelt rammeverk, gir Lean en ledelsesfilosofi og en masse nyttige teknikker og tankemodeller som kan gi Scrum-implementasjonen en skikkelig “boost”. I hvor stor grad tenker forretningssiden “Pull” og tar brukernes behov på alvor? Jobber de for å eliminere “waste”? Ser de aktivt og systematisk etter forbedringsområder – IKKE begrenset til retrospectiv-møtene? Osv osv.. Her synes jeg å se en markant forskjell mellom de som tenker Lean og de som ikke gjør det.
Bruk disse 5 faktorene som en sjekkliste i egen organisasjon. Hvordan står det til?
ITIL – et gufs fra 90-tallet
Jeg har alltid hatt et avslappet forhold til ITIL. ITIL er “noen support-prosesser” som tar i mot kundehenvendelser, kategoriserer og enten løser saken eller sender videre til “utviklingsavdelingen”. Trodde jeg. Jeg husker vagt jeg satte meg inn i Problem Management, Service Management, Incident Management, Release Management og sånt en gang for lenge siden. Det virket fornuftig å etablere et standardisert begrepsapparat for slikt, og jeg husker at en av prosessene gikk på læring. Jeg har tenkt at hovedfokuset for en god ITIL implementasjon må være å samle erfaring og å identifisere systematiske feil slik at de kan rettes en gang for alle. Fornuftig det!
Jeg får fra tid til annen spørsmål og hvordan Scrum og ITIL passer sammen – og jeg skjønner nå at jeg har tatt litt for lett på dette spørsmålet. I mitt enkle verdensbilde har ITIL representert 1. linje support – de som avgjør om Scrum teamet skal få saken eller om det kan løses av andre. Alle gode prosesser med fokus på kvalitet (som jo Scrum er) foreskriver at de som forårssaket feilen skal få den rett tilbake så fort som overhodet mulig. Kjører man korte iterasjoner (14 dager eller mindre) og leverer små inkrementer fortløpende vil dette kunne bli helt optimalt.
Jeg leste med interesse innstikket om ITIL i Computerworld for et par uker siden. En lang sammenhengende hyllest til dette rammeverket, med ett lite unntak, nemlig “universalskeptiker” Helge Skrivervik som sier Itil er gammeldags. (Han blir her kraftig marginalisert ved at journalisten gjentar “universalskeptiker” flere ganger i artikkelen.) Uansett, det Skrivervik sa var nok til å pirre nysgjerrigheten min, så jeg satt i gang med å orientere meg litt i ITIL-jungelen. Og det er en jungel med ekstremt mange aktører på kurs og tjenester. Men det var ikke så vanskelig å finne beskrivelser som gjor at en novise som meg kunne orientere meg i dette uten å måtte gå i detalj.
Den gjeldende versjonen er ITIL V3. Dette rammeverket er et gigantisk, altomfattende rammeverk for drift, vedlikehold, release, og nyutvikling. Hvor omfattende dette er kan man få et inntrykk av her og her. Jeg har sett og brukt utallige prosessmodeller opp igjennom tidene. Vi brukte Cleanroom Software Engineering på tidlig 90-tall i Siemens Forsvarssystemer. Jeg har brukt hjemmesnekrede, detaljerte vannfallsorienterte modeller og jeg har brukt RUP. All denne erfaringen har lært meg en ting: Standardisering av arbeidsflyt er fornuftig – så lenge man ikke detaljspesifiserer og så lenge man holder seg til minimumsløsninger. Rigorøse prosesser fører enten til at man sementerer prosessen og dermed umuliggjør systematisk forbedringsarbeid eller det fører til “ulydighet” ved at man omgår prosessen for å klare å jobbe effektivt. Alle prosedyreverk bør starte med et absolutt minimum og så kan vi legge til detaljerte prosedyrer på områder som er spesielt kritisk for oss. Det er mye vanskeligere å begynne med noe stort, komplett og detaljert og så fjerne det vi ikke trenger. Jeg kaller dette på spøk Geirs første og eneste lov: “Det er 10 ganger lettere å legge til enn å trekke fra”. Helge Skrivervik har tydeligvis samme syn.
Helge Skrivervik: FFF: Forandring uten Forenkling er Forkastelig!
ITIL-prosessene er noen store mammuter, eller dinosaurer er kanskje et bedre ord. Jeg finner et 40-talls roller, en mengde store prosesskart som typisk nok blir helt uleselige når de forminskes for å passe inn i et normalt dokument eller en web-side. Jeg ga fort opp å forstå de hierarkisk oppbygde flytdiagrammene. Kan dette være nødvendig da? Det som er helt sikkert er at dette er anti Agile, anti Lean og det sikk motsatte av Systems Thinking. ITIL systematiserer jo alt de John Seddon advarer så sterkt mot.
Ikke nok med det – ITIL er først og fremst laget for å optimalisere feilhåndtering. Hvorfor skal vi det? Dette er jo i utgangspunktet Waste, eller slikt John Seddon definerer som Failure Demand.
John Seddon: Failure Demand is demand on the resources of an organization caused by its own failures.
Mary Poppendieck: Your objective is not to handle failure demand more efficiently; it is to eliminate failure.
Det slår meg at dette rimer veldig godt med god gammeldags vannfallstankegang eller “Command and Control”; Vi håndterer kompleksitet og avhengigheter ved å modellere virkeligheten. Gantt-diagrammer er et godt eksempel på dette. Tenker man Lean vil man i stedet for å modellere eller håndtere avhengigheter redusere avhengigheter. Moderne, effektive organisasjoner verdsetter innovasjon, kvalitet og fleksibilitet, nærhet til kunden og jobber med enkle, fleksible rammeverk som Scrum og Kanban.
Problem Management: Skremmende ineffektiv “handover” prosess – lang avstand til brukeren:
Hva med å kjøre en “Eliminate Waste” på denne ved å bruke Total Value Stram Maps? Ikke helt få køer og prosesstrinn der det ikke foregår mye verdiskapning – om en har på kundebrillene.
Hva oppnår du med Scrum?
Noen har sikkert rett i at Scrum overselges en del, men det er vel egentlig ikke annet å vente tatt i betraktning populatiteten til dette rammeverket. Selv forsøker jeg alltid å legge vekt på: “Scrum er bare et minimalistisk rammeverk – et slags verktøy du kan bruke for å lage bedre produkter. Scrum bør aldri være et mål i seg selv.” Agile (eller Smidig på norsk) kan derimot være et mål. De fleste som fremdeles tenker tradisjonellt vil oppleve at de gjerne skulle vært raskere til markedet, truffet brukernes behov bedre, eller hatt bedre kontroll på prosjektene sine. Da er det høyst sannsynlig at de bør dreie i retning av Agile – og jeg vil ikke nøle med å anbefale Scrum. Og jeg vil i utgangspunktet anbefale å følge “boka”. Problemet er at “boka” ikke er så lett å finne. Scrum er ikke formelt definert og det finnes etter hvert ganske mange ulike “sannheter”. Scrum guiden på Scrum.org er nok det nærmeste vi kommer en definisjon. Problemet med denne er at den er svært dogmatisk formulert og jeg kunne ønsket meg en litt mer veiledende form. Mike Cohns siste bok er til stor hjelp, men vil heller ikke definere Scrum. Scrum Primer fra STI er en annen god kilde. Og så har vi alt det Henrik Kniberg publiserer – denne svensken har etablert stor definisjonsmakt gjennom sin visuelle og pedagogiske måte å kommunisere på. Det er ikke store sprik eller inkonsistens mellom disse ulike kildene, men de fokuserer typisk på ulike ting.
Hva lover Scrum da?
Jeg har her funnet fram en del utsagn som på en kortfattet måte beskriver lovnadene.
Tobias Mayer:
“Scrum makes one promise only: it will help you fail in thirty days or less. That’s it. And it will begin to surface organizational dysfunction in the process.”
Hmmm. Er vi helt sikre på at det er dette vi vil..?
Ken Schwaber:
“imagine that your mother-in-law believed her daughter could do better… and then imagine that she moved in with you… that’s what Scrum is like”
Hjelp! Er Scrum virkelig så ubarmhjertig!!!??
The Scrum Guide:
“Scrum, which is grounded in empirical process control theory, employs an iterative, incremental approach to optimize predictability and control risk.”
OK, det var bedre. Forutsigbarhet og kontroll over risiko er jo bra!
Henrik Kniberg:
“Scrum in a nutshell:
* Split your organization into small, cross-functional, self-organizing teams.
* Split your work into a list of small, concrete deliverables. Assign someone to be responsible for that list and to sort the list by priority. The implementation team estimates the relative size of each item.
* Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration.
* Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
* Optimize the process by having a retrospective after each iteration.”
Greit! Så dette er et knep for å forenkle ved å dele opp organisasjonen, arbeid og tid samt å få i gang en optimaliseringssløyfe. Dette trenger vi!
Selv bruker jeg å selge Scrum ved å si at jeg har jobbet med organisasjoner som beretter om forbedringer på mange områder på en gang:
* Bedre kundetilfredshet
* Bedre trivsel
* Mer innovasjon og effektivitet i utviklingsavdelingen
* Langt bedre oversikt internt
* Bedre samhandling mellom IT og forretningssiden
Men dette er ikke lovnader om noe man kan innkassere bare man følger “oppskriften”. Alle vil selvsagt ikke kunne høste alle disse fruktene med en gang, dette kommer jo an på hvor “dårlige” man er i utgangspunktet.
Det jeg kan love er at du her får all den hjelpen du vil ha til å optimalisere prosessene dine. Men dette er hardt arbeid – som du må gjøre selv!
Management 3.0. Ingen høyere?
Jeg har stor sans for det Jurgen Appelo skriver og sier, men jeg må si jeg ble lett oppgitt når han inviterte til å engasjere seg på et NING nettverk kalt Management 3.0. Kan dette være nødvendig da? Som vanlig kom Jurgen meg i forkjøpet og svarte selv:
Management 3.0 is a silly name. We already have Web 2.0, Government 2.0, Project Management 2.0, Enterprise 2.0, and RSS 2.0. And interestingly enough, Gary Hamel’s Management 2.0 was one of the last to jump on the “2.0″ bandwagon.
Jeg leser Gary Hamel’s Management 2.0 med stor fornøyelse og spesielt artikkelen The Facebook Generation vs. the Fortune 500 gjorde meg sikker på at verden – til tross for en del motstand – er i ferd med å bli smidig. Smidig som i Agile. Og i Scrum. Så vi klarer oss helt sikkert godt uten Management 3.0 i lang tid framover. Men dette nettverket er spennende da! Og Jurgen appellerer tydeligvis til mange for i medlemslista i nettverket finner vi navn som Mike Cohn, Esther Derby og Phillippe Krutchen. Så hvorfor ikke. Jurgen holder på med boka Management 3.0: The Era of Complexity og ideen er selvsagt å få kompetente, engasjerte folk til å bidra til å gjøre boka god. Han bruker sin egen medisin her for ideen hans er at vi må begynne å se på organisasjoner som komplekse sosiale nettverk der innovasjonen får blomstre i stadig raskere tempo ved å la folk selvorganisere og å la energien og kunnskapen selv finne veien dit den skaper mest verdi.
Engasjer eder!
NAV med dårligere service
En av de overordnede målsetningene med NAV reformen var å yte bedre service til brukerne. Alt tyder på at det har gått motsatt vei. Selv NAV-reformens far Dagfinn Høybråten påpeker dette i dagens VG. Som Høybråten selv sier er ansvaret og kompetansen i langt større grad sentralisert enn før. Det virker som alt skal innom NAV forvaltning, som da selvsagt blir en flaskehals. De ulike instansene og fagområdene gjør sin del av jobben og sender saken videre til neste. Man måler de ulike avdelingene isolert, uten å se på helheten. Ble saken faktisk løst? Ble brukeren hjulpet, eller sitter vi igjen med uavklarte spørsmål som vil generere ny saksgang? Sakene hoper seg opp i ulike køer rundt om i systemet, man mister oversikt og brukeren blir sittende og vente. Det er lett å forstå at de ansatte blir slitne, frustrerte og får et rekordhøyt sykefravær – noe som selvsagt fører til enda større forsinkelse og frustrasjon. Jeg føler virkelig med de NAV-ansatte. Svært få av dem er forunt å oppleve en smilende, glad bruker som takker og er lettet over at problemet er løst. For det er jo det som motiverer folk; Det å få oppleve den positive effekten av det arbeidet vi gjør – direkte med egne øyne! MEN det rettferdiggjør ikke å opptre arrogant og nedlatende overfor brukeren. Man skal ikke lese mange leserinnlegg for å forstå et dette er et svært omfattende problem.
Noen tror dette er et problem som kan løses med IT-systemer. Men utallige erfaringer viser at IT ikke er løsningen på problemet. Ofte er selve saksgangen og organiseringen så kompleks at det nærmest er umulig å støtte alt. Her en bare en av mange artikler som forteller at IT i helsevesenet ikke løser problemet. Jeg er kanskje illojal overfor en bransje jeg selv er en del av, men i disse tilfellene står det klart for meg at IT-løsninger kan virke stikk imot sin hensikt. Ved å dreie fokus mot IT-løsninger vil man selvsagt “slippe unna” viktige diskusjoner rundt organisering for styringsfilosofi. Dessuten er det dyrt og krevende for organisasjonen å måtte forholde seg til avanserte IT-systemer i stadig utvikling.
Slik NAV er organisert i dag tror jeg man kan kaste så mye penger man bare vil inn i det systemet uten å verken få mer fornøyde brukere eller ansatte. Problemet virker systematisk og må håndteres som systemfeil. Dette er ansvarsfraskrivelse satt i system. Man må langt opp i hirarkiet for å finne ansvaret, og dermed blir avstanden alt for stor til at dette ansvaret kan utøves særlig operativt. Dette kan føre til helt håpløse tilstander der prinsipper og begrensninger fullstendig overtar for løsningsorientering. Leste akkurat på Paul Chaffeys blogg at man fremdeles sender disketter med pasientdata til fastlegene!
Heldigvis finnes det alternative modeller som fungerer – og som helt sikkert kan brukes i NAV. Felles for de aktuelle modellene er at de tar til orde for:
- Der etterspørselen ikke er konstant over tid eller geografi er det ufornuftig å standardisere saksbehandlingen
- Kompetanse må plasseres så nær kunden/brukeren som mulig
- Ansvar og myndighet må plasseres så nær kunden/brukeren som mulig
- Resultatmål som ikke er direkte koblet til brukerne gir sub-optimalisering og uønsket adferd
- Kvalitet må hele tiden være den mest styrende parameteren
- Gjennomløpstiden for saker må være kort – løs en sak om gangen i stedet for å starte mange på en gang; Jobb i tverrfaglige team.
Dette innebærer jo at hver lokale enhet må få frihet til å organisere seg slik at de treffer sine brukere best mulig. Det skal ikke mye fantasi til å forstå et brukerne på Holmlia skiller seg gaske kraftig fra de på Snarøya. Eller de i Stokmarknes. Om de ulike enhetene får dette ansvaret vil de selv finne sine egne kompetansehuller og begynne å fylle disse. Når etterspørselen av ulike grunner endrer seg vil de raskt kunne gjøre den nødvendige tilpasningene. Langt flere av de ansatte vil på denne måten få en tett kontakt med brukerne. De vil løse saker raskere og oftere oppleve den gode følelsen av å ha utrettet noe positivt for en person. En slik enhet vil virkelig interessere seg for å gjøre en god jobb for brukerne. De vil ikke behøve direktiver – de vil optimalisere sine egne prosesser av egen fri vilje. Saksbehandlerne og fagpersonene må på denne måten jobbe tettere sammen noe som vil føre til kompetanseflyt og ikke minst gi et bedre overblikk over saksgangen. Et slikt system er i mindre grad avhengig av store, komplekse IT-systemer. De helt essensielle funksjonene – som en koplett journal per person – må man nok fremdeles ha, men vi behøver ikke saksbehandlingssystemer som støtter kompleks saksgang.
Dette er (desverre) ikke noe jeg har funnet på selv. Tankegodset kommer fra W. Edwards Deming som spesielt Toyota hørte på på 1950-tallet og som mange gir mye av æren for at Japanerne så fort kom seg på beina som industrinasjon etter krigen. Etter hvert har “The Toyota Way” blitt definert som Lean - som er en ledelsesfilosofi som kan tilpasses veldig mange ulike organisasjoner. Innenfor tjenestesektoren og saksbehandlingssystemer er det nå spesielt Systems Thinking som er mest toneangivende. Spander 1 time på denne videoen der Vanguards John Seddon forklarer hvordan dette konseptet kan revolusjonere saksbehandlingssystemer.
Cultural change is free from Mindfields College on Vimeo.
Er det mulig? For godt til å være sant! Hvorfor gjør vi ikke dette? Jeg tror grunnen først og fremst er fordi disse tankene strider imot en del tillærte “sannheter”. Mange skal avlæres, myter skal overvinnes og kjepphester kastes.
De viktigste mytene som virker mot dette tror jeg er slikt som:
- Sentralisering gir vesentlige stordriftsfordeler
- Sentralisering gjør at vi lettere kan utnytte spisskompetanse
- Man må ha lederstilling for å ta beslutninger
- Medarbeidere og enheter må styres gjennom å sette lokale mål
- Et rettferdig system må være regelstyrt og er avhengig av standardisering
Kan det være likhetstanken som har vært mest styrende her? Ender vi opp med systemer der alle blir behandlet like dårlig – i stedet for å tillate forskjeller med det resultatet at alle blir bedre? Det er jo klart at i et desentralisert system er det lett å frykte at to ganske like saker får noe forskjellig utfall. Men det opplever vi allerede i dag! Se for eksempel innlegget NAV som overdommer på den utmerkede bloggen Marias Metode. Les gjerne de 182 kommentarene også… Reglene er – og vil alltid være – utilstrekkelige. Det MÅ utvises skjønn. Hvorfor ikke da la skjønnet være en naturlig del av prosessen? Hvorfor ikke sikre at skjønnet utøves av kompetente team i tett kontakt med brukeren?
SISTE: Aftenposten: Intern NAV-kritikk ties ihjel: Bekrefter systemfeil – som må rettes om det skal bli bedring. De måles på tid - ikke kvalitet, det er ingen forkus på forbedring, det er ikke lov å si i fra, det brukes masse energi på fortvilelse og “snakk i gangene”. Hele sentraliseringstankegangen må endres om det skal bli bedring!
Verktøy for å få kunnskap, ikke styring
(Dette handler om smidig systemutvikling – les hele:))
Jeg kommer rett fra lørdagens faste spinning-time. Hadde tenkt å legge inn en ganske hard, men ikke for lang treningsøkt. Jeg har lært at det er viktig og ikke presse seg for hardt i treningsperiodene. De virkelig harde intervalløktene skal spares til formtoppingen. Mine mål for 2010 dreier seg om slå egne tider på Birken på ski, sykkel og på beina. Som i år.
Man kan få masse kunnskap om trening blant annet på olympiatoppen.no og på et utall nettsteder med diskusjonsforum. Når det gjelder utholdenhetstrening synes alle å være enige om at mange mosjonister trener for hardt og for lite variert. Dette går utover overskuddet og gir dårlig framgang. Men hvordan kan du vite om du trener for hardt? Første bud er å skaffe seg en pulsklokke. Jeg gravde dypt ned i lommeboka og kjøpte meg en Polar RS800 som kan gi en masse data om hver treningsøkt, basert på pulslogging. Under ser vi loggen fra dagens spinning-time. Jeg har her utfordret melkesyreterskelen min ganske kraftig.
Jeg har faktisk vært i sone 5 i 39 % av tiden – hvilket kanskje er litt for mye. Men, jeg har heller ikke tenkt å trene på et par dager, så jeg får sjansen til å opparbeide meg overskudd igjen før neste økt. I min lille 2-minutters retrospective konkluderer jeg med at jeg er fornøyd med denne økta. Må bare huske å ta det roligere neste økt. Pulsklokka gir meg også direkte feedback underveis i treninga, så jeg kan justere intensiteten etter hvor jeg ønsker å ligge. Veldig motiverende å følge med på dette!
Idrettsfolk er ekstremt avhengig av feedback for å øke prestasjonene. Man har en teori i bunnen om hva som er riktig trening i de ulike fasene. Og så bruker man alle tilgjengelige verktøy for å samle data og måle progresjonen mot målet. Men siden vi her snakker om mennesker så er det til syvende og sist den enkelte utøver som vil gjøre vurderinger løpende underveis. Det er ekstremt vanskelig å jogge rolig om været er godt, musikken på øret er suggererende og kroppen fungerer glimrende. Kommer man i flytsonen er det bare å la det stå til, så får man ta smellen etterpå. All loggingen og feedbacken kan ikke bli mer enn veiledende. Dataene motiverer og må brukes med måte til å øke kunnskapen om egen kropp, ikke til blind styring.
På samme måten er det med smidig systemutvikling. Vi ønsker data som kan gi oss kunnskap om to ting: 1) hvordan vi ligger an i forhold til det vi har forpliktet oss til og 2) data som kan gi oss kunnskap om hvordan det lønner seg å jobbe/samhandle. Scrum – som er det desidert mest brukte rammeverket – legger opp til å klare seg med så lite verktøy som mulig. Vi jobber i små team nettopp for at vi på en pragmatisk og uformell måte kan beholde oversikten. Vi har daglige møter for å koordinere. Vi må ha skikkelig kontroll på alle oppgavene i Sprinten og hva som gjenstår for å bli ferdig. Bruk gjerne Task Board (lapper på veggen) om man er samlokaliserte. Tar man disse tingene på alvor blir verktøybehovet minimalt. Det er faktisk et eksplisitt mål å holde verktøybruken på et ansvarlig minimum. Verktøy har en tendens til å institusjonalisere oppførsel, både den gode og den dårlige.
Når vi jobber i selvstyrte team må vi være ekstra oppmerksomme på hvordan vi bruker data. Vi ønsker åpenhet og synlighet, men vi må vokte oss for å premiere oppførsel på individnivå. Selvstyrte tem bygger på ”kollektivt eierskap” hvilket lett kan få en slagside om individer premieres eller straffes. Smidig dreier seg mye om å frigjøre seg fra tradisjonell tankegang basert på ”Command and Control” (Les her gjerne ”Freedom from Command and Control” av John Seddon). Om en autoritet tett på teamene (ofte kalt prosjektleder) begynner å bruke data for å styre teamene forsvinner lett dette eierskapet. Autoriteten er tydeligvis den som sitter med eierskapet her…
Det er sterke krefter som virker i motsatt vei av Smidig; Vaner, posisjoner, etablerte ”sannheter”, ønsket om å kontrollere osv. er eksempler på slike. Ønsket om å selge verktøy – eller gleden over et avansert dataverktøy er andre krefter vi må være obs på.
Når vi skalerer opp og må sette sammen mange parallelle team med visse avhengigheter må vi selvsagt håndtere denne kompleksiteten på en forsvarlig måte. I Scrum anbefaler vi flere verktøyløse mekanismer som Scrum of Scrums, oppmøte på hverandres Daily Scrum og ikke minst tversgående virtuelle team (eller communities som Mike Cohn kaller dem i sin siste bok). Dette er ekte smidige løsninger. Mange vil sverge til mer tradisjonelle løsninger som å ha en prosjektleder som koordinerer, kjøpe seg verktøy som gir styrings- og kontroll informasjon. Dette er ikke smidige løsninger.
Smidig dreier seg om å tilfredsstille brukernes (eller mer generelt interessentenes) behov og det bør stå i sentrum. Idealet er pull (som definert av Toyota) der vi lar oss styre av brukernes behov. Det vi virkelig bør samle data om er brukernes ønsker og om brukernes tilfredshet. Gå gjerne så langt som å kvantifisere og måle de verdiene og produktegenskapene brukerne ønsker seg (se www.gilb.no for mer info om Value Management). Dette gir mer verdifull styringsinformasjon og dessuten risikerer vi ikke å ødelegge de selvstyrte teamene.
Ukas Computerworld pusher Rationals Team Concert uhemmet under overskriften TEMA SMIDIG. I det jeg leser er det ikke noe som tyder på at dette er særlig smidig. Alt tyder på at dette er et verktøy for en prosjektledelse som ønsker å ha kontroll. God gammeldags Command and Control. Jeg har kikket litt på reklamen for verktøyet og får da bekreftet mine mistanker:
Her ser vi at de betrakter Burndown som et redskap til å kontrollere Quality of Planning.. Underlig burndown konsept også om man ser på Planned Work som går oppover. Er Arbeid definert som å bruke timer?
Jeg er redd for at nå en del sterke krefter har kastet seg på smidig-bølgen – uten å være smidige. Man ser at smidig selger og gjør noen justeringer i retning av iterasjoner og inkrementer. Dette er en farlig utvikling som kan vanne ut Smidig-begrepet. Vi mister da den kanskje vanskeligste utfordringen, nemlig å bevege oss vekk fra Command and Control mot selvstyrte team. Computerworld og andre er nyttige idioter som lar seg bruke i deres ”smidige” profilering.
Scrum sertifisering – en oppklaring
Scrum sertifiseringen har vært gjenstand for en god del angrep i det siste. Spesielt CSM ble heftig diskutert på F**k Scrum seansen til Christian Braarud Hauknes på Smidig2009. Og nå sist av Per Olav Istad i papirutgaven av Computerworld. Istad sammenligner Scrum sertifisering med lureriet i Bjugn saken .. Begge bedyrer at Scrum er helt OK, mens sertifiseringer er null verdt og lureri.
Fakta1: Det har aldri vært noe hemmelighetskremmeri rundt CSM – Certified Scrum Master. Dette er et 2 dagers kurs i regi av en sertifisert instruktør. Verken mer eller mindre. En sertifisert instruktør betyr Certified Scrum Trainer – CST.
Fakta2: Scrum er ikke noe registert varemerke. CSM, CST og de andre sertifiseringene er det.
Fakta3: Scrum Alliance er forpliktet til å holde Scrum (innen systemutvikling – ikke rugby) på et høyt kvalitetsnivå, og å hjelpe organisasjoner i å bli mer effektive ved å hjelpe dem i gang med Scrum.
Fakta4: Scrum er en gedigen suksess med mer enn 60.000 CSM er verden over.
Hva er det som er lureriet her? Om noen blir mektig imponert over CSM på en CV og velger å ansette eller leie inn vedkommende uten å sjekke hva som ligger i begrepet får de skylde seg selv. Maken til naivitet! CSM sikrer ikke kvaliteten til personen. Selvsagt ikke. Men CSM har 2 funksjoner:
1. Det sikrer at vedkommende har lært Scrum av en Certified Scrum Trainer og ikke en selvlært konsulent som gir sin versjon eller tolkning av Scrum. Dette er hovedpoenget.
2. Den gir de som ønsker å satse på å bli virkelig gode et godt fundament å bygge videre på, enten man ønsker å gå videre til neste nivå eller ikke.
Hva neste nivå er? Ser ikke ut som det er så mange nordmenn som interesserer seg for dette – kun 10 stk er Certified Scrum Practitioner (CSP) i Norge, mens over 3000 er CSM.
Vel, en ting må selvsagt Scrum Alliance innrømme. Ordet Master indikerer noe mer enn et 2 dagers kurs. Greit det. Et uheldig ordvalg. Practitioner er altså mye mer verd. Ikke helt logisk det heller.. Men slik er det, og det kommer nok ikke til å endre seg.
Jeg kan ikke fri meg fra og tenke: “Noe har gått litt galt her i Norge”. Vi har verdens høyeste tetthet av CSMer, men antageligvis verdens laveste andel CSP. I CSP ligger det reell verdi og jeg ville lett ansatt en CSP i et Scrum Team (jaja, selvsagt etter å ha gjennomført alle de andre vurderingene da:)) Noe med arbeidsmarkedet her å gjøre kanskje?
Nå har Scrum Alliance innført en eksamen slik at det ikke skal være fullt så lett å sove seg igjennom en CSM. Dere kan lese mer om dette her. Det spørs om CSM gir noen særlig større verdi på grunn av denne eksamene. Det er fortsatt bare et 2 dagers kurs… Et kurs med høy kvalitet.
Smidig verdidebatt
Det skrives og diskuteres mye om kundeverdi for tiden. Selv har jeg nylig tatt opp teamet både her og der. Noen tar til orde for at hele Agile Manifesto er feil og at Scrum er bygd på feil premisser. Bill Caputo skriver i innlegget THE DEATH OF AGILE om hvordan Agile ofte blir misbrukt av toppledelsen for å generere “shareholder value”. Man glemmer da lett sluttbrukerne og at utviklerne motiveres av å lage god software og å generere verdi for ekte brukere.
Tom og Kai Gilb skriver her
“Completely wrong Focus: Agile & Scrum is not focused on delivering values to Stakeholders for a minimum or a reasonable cost”
der de ganske riktig påviser at det er lite eksplisitt støtte for å optimalisere på å generere faktisk verdi for interessentene. For å ta det første først: Agile Manifesto verdsetter Working Software over comprehencive documentation, men sier svært lite om hva man legger i begrepet working software. Men siden man også verdsetter Customer Collaboration kan man jo ane at man er opptatt av å høre på hva kundene verdsetter. Ikke spesielt eksplisitt, men så er det jo grenser for hva man får lagt inn av budskap i 4 korte setninger. Men, det kanskje ikke alle er klar over er at det under Agile Manifesto også befinner seg 12 prinsipper. Den første av disse sier:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Se det! Valuable Software – akkurat det man (Gilb) savnet i selve manifestet!
Når det gjelder Scrum så er det helt riktig at det ikke er mye direkte fokus på å generere kundeverdi. Det forutsettes at Product Owner prioriterer basert på kommunikasjon med interessentene og at han/hun gjør ROI (Return On Investment) kalkulasjoner. Scrum er som kjent bare et enkelt rammeverk med svært lite teknikker og metoder innebygd. Dette må hver og en organisasjon finne ut av selv.
Men jeg er enig med Gilb i en ting: Slik som Scrum praktiseres i dag er det mye å hente på å bli mer fokuserte på kundeverdi og produktegenskaper. Jeg tror virkelig på EVO og på å sette målbare forbedringsmål for produktet. Jeg tror vi skal innrømme at det har vært for mye fokus på å pøse ut funksjonalitet og å måle velocity. Vi trenger virkelig slike som Gilb – som står på barrikadene og som evner å spissformulere såpass at de som trenger det får en skikkelig wake-up call!
Jeg tror Agile Manifesto trenger en 5. setning som sier noe slikt som:
Stakeholder Value over Features
Da kan kanskje dette manifestet få leve i nye 9 år!
Lever verdi – ikke funksjonalitet!
Jeg tror den tiden er forbi da IT-brukere syntes det 
var fasinerende å stadig få levert fler og fler funksjoner knyttet til systemene. Jeg har snakket om MS Office mange ganger (bl.a. her)- som etter min mening er skrekkeksemplet på at vi for lenge siden nådde “Happy User Peak”. Ytterligere funksjonalitet gir ingen merverdi – det bare bidrar til å komplisere det som allerede er der. Siden 1995 har Microsoft levert negativ verdi med hver nye versjon av Word. Etter min mening – og mine behov. De har kunnet holde på på denne måten bare fordi de har en unik standardsettende posisjon i markedet – og vi finner oss derfor i det meste. Men denne tiden tror jeg som sagt er forbi. Selv bruker jeg ofte Notepad nårjeg jobber med en tekst. Det er et lynraskt, enkelt program som ikke gir formatteringsproblemer når denne teksten senere skal over i et annet medium.
Moderne programvare fokuserer på brukernes behov ved at den raskt kommer ut med ganske minimal funksjonalitet, men allikevel med tilstrekkelig interessante egenskaper til at noen vi ta den i bruk. Det er dette vi gjerne kaller Minimal Marketable Features (MMF). De som lykkes i dag ser ut til å være gode til nettopp dette. Fordelene er flere:
1. Produktet kommer raskest mulig ut til markedet
2. Leverandøren kommer i dialog med ekte brukere og kan bygge communities
3. Vi får verdifull feedback på produktkvaliteter og ønsket ny funksjonalitet
En annen egenskap med moderne programvare synes å være at den kommer i form av ganske løst koblede funksjoner (plugins, applets etc..) som man selv kan velge å inkludere. Vi prøver dem ut og så kan vi velge å beholde eller kaskje forkaste igjen. Steinalderen – de store mammutsystemenes tid – er forhåpentligvis snart over!
I Lean er det mye fokus på å levere verdi for kunden og brukerne. Alt som ikke gir verdi er per definisjon søppel (waste). Vi må snakke med brukerne og være helt sikre på hva de verdsetter høyt, og kanskje like viktig – hva de ikke verdsetter i det hele tatt. Brukerne verdsetter sjelden kompleksitet særlig høyt. De vil i stedet verdsette slikt som intuitivitet, rask responsitid, effektivitet o.l. Alle ekte smidige rammeverk – som for eksempel Scrum – bekjenner seg også til denne tankegangen.
I Scrum er det produkteierrollen som sitter med det hele og fulle ansvaret for å prioritere innsatsen for å generere mest mulig verdi. Derfor er det tvingende nødvendig at produkteier har en dyp bevissthet på brukernes egentlige behov og ikke faller for fristelsen til å tro at ny funksjonalitet automatisk gir verdi. De produkteierne som har bakgrunn som selgere synes kanskje å ekstra lett kunne gå i denne fella; Om vi skal kunne ta en god pris for denne oppgraderingen må det komme ut synlig funksjonalitet! Det er desverre alt for mange som ikke ennå har fått denne viktige rollen til å fungere etter hensikten ennå. Jeg blogget litt om dette her.
EVO er i likhet med Scrum et smidig rammeverk. Dette er definert av Tom Gilb (www.gilb.com) og benyttes av en del organisasjoner. Den store styrken til EVO er på prioritering av – og styring mot – behov. EVO 
gir deg et kraftig rammeverk og en tankemodell for å diskutere hva som egentlig er viktig for kunden. Dette er sjelden kaskader av funksjonalitet! Tvert i mot går dette ofte på produktegenskaper, slikt som ytelse, brukervennlighet, produktivitet osv. EVO nøyer seg ikke med å definere produktegenskaper – de skal også gjøres målbare. Det er faktisk mulig å sette opp måleparametere for de aller fleste egenskaper. Da får vi unike muligheter til å bli “ekte smidig” gjennom å la oss styre av kundenes behov.
En god produkteier optimaliserer på kundeverdi ved å
* identifisere de viktigste brukerne og interessentene og forstå hva disse verdsetter høyest
* sette seg mål for den effekten han vil tilby brukerne
* sørge for å komme raskt og hyppig ut til markedet med minimale bolker av funksjonalitet (Minimal Marketable Features)
* sørge for å få feedback fra de viktigste brukerne og interessentene
* ikke være fremmed for å fjerne funksjonalitet om det kan bidra til å øke brukernes opplevde verdi
En god produkteier besitter (som alle andre gode håndtverkere) en velfylt verktøykasse. Heldigvis blir verktøyene bedre og bedre. Det dokumenteres stadig mer empiri på tankemodeller, metoder og verktøy som fungerer godt for produkteiere. Dette er eksempelvis interessentanalyse, User Stories, Story Mapping, Minimal Marketable Features, Kano analysis, Balaned Score Card, EVO og Behaviour Driven Development for å nevne noen.
Jeg har akkurat vært på tre dagers Scrum Gathering i Munchen etterfulgt av to dager med Smidig2009 i Oslo. I begge konferansene var det mye fokus på produkeierrollen og forretningsverdi.
Fra Smidig2009:
Rune Ulvnes, DaVinci: Backlog prioritering basert på Clayton M. Christensens ideer om “The Job to be Done”. Veldig bra tankegods! Pensum for produkteiere.
Geir Amsjø: PO rollens 7 fallgruber. En slags oppsummering av det vi i dag sliter med innen PO-rollen i Scrum.
Christian Braarud Hauknes, Statskraft: Smidig i store porteføljer - om hvordan arkitekturen må med for å unngå kompleksitet om man skal klare å optimalisere på kundeverdi.
Trond Wingaard: Smidige prosjekters verdibløff – og noen botemidler.
Simen F. Jørgensen, Iterate. Bruk Balanced Score Card for å synliggjøre suksesskriterier ved å hele tiden prioritere verdi etter balanserte kriterier.
Trond Johansen, ConformIT: For de som ønsker å være bedre enn konkurrentene. Om hvordan de bruker EVO for å styre konsekvent mot stadig bedre målbar kundeverdi. Og hvorfor dette sjelden fører til mer funksjonalitet, men heller bedre produkegenskaper.
Fra Scrum Gathering:
Serge Beuamonts On Definition of Ready and the “Ready Kanban”: http://blog.xebia.com/2009/09/12/the-ready-kanban-the-product-owners-scrum-board/#more-2488
Andre ressurser:
Kreating Passionate Users:
http://headrush.typepad.com/creating_passionate_users/2007/04/my_favorite_gra.html