Scrum feiler ikke!

Jeg er vant til at enkelte blir litt provosert over dette utsagnet. Kanskje ikke så rart, det er unektelig en bastant påstand!

Jeg berørte dette sammen med Sergey Dmitriev på XP meetup i Trondheim her for leden med overskriften Scrum fungerer alltid!

Poenget er selvsagt at Scrum er et enkelt rammeverk – som egner seg utmerket som basis til å lage seg en metode. Man må se på dette som et verktøy. Om du kjøper deg en skikkelig hammer og leser et par “Gjør det selv-bøker” blir du ikke nødvendigvis en god snekker, vel? Ikke umiddelbart i alle fall. Vil du da skylde på hammeren? Har du talent og praktiserer og øver så kan du komme ganske langt, selv uten fagutdannelse.

Veldig mange mislykkes dessverre med Scrumsatsningen sin. Dette skyldes sjelden rammeverket. Rammeverket er jo laget for å legge til rette for øving. Scrum kan skape en fantastisk gjennomsiktighet. Du kan analysere delleveransene og arbeidsmetodene dine om igjen og om igjen om derigjennom bli veldig god – hvis du er villig til å legge arbeid og dedikasjon i å optimalisere metoder og verktøy.

Gartner Group har nok forstått at Agile-toget forlot perrongen mens Gartner stod med ryggen til og de forsøker stadig å posisjonere seg inn igjen. Det siste innspillet fra Peter Hidas på Peters Plass i Computerworld gikk på at Scrum er ikke nok – Gartner mener vi trenger Enterprise-class Agile Development. Mulig det. Om du bruker Scrum etter intensjonen vil du oppdage dette og innlemme dette i egne Scrum-baserte prosesser. Man trenger ikke noen Gartner-modell for det vel?

Jeg har sans for måten Ken Schwaber uttrykker det:

Scrum is like chess. You either play it as its rules state, or you don’t. Scrum and chess do not fail or succeed. They are either played, or not. Those who play both games and keep practicing may become very good at playing the games. In the case of chess, they may become Grand Masters. In the case of Scrum, they may become outstanding development organizations, cherished by their customers, loved by their users, and feared by their competitors.

Store overskridelser i IT-prosjekter. Hva så?

Forskeren Magne Jørgensen resonnerer om overskridelsene i IT-prosjekter i en ny kronikk i Computerworld. Advokaten Jan Sandtrø kommenterer her. De har mange gode poenger, men adresserer ikke det viktigste: De definerer ikke “vellykket” på noen klargjørende måte.

Jeg har vært i IT-bransjen i snart 25 år og når jeg tenker tilbake i tid, kan jeg lett finne eksempler på programvareprosjekter som har vært vellykkede i den forstand at de har levert i henhold til spec, i rett tid og innenfor budsjett. Men jeg finner langt flere eksempler på prosjekter som ikke har vært vellykkede i samme forstand. Det som imidlertid slår meg er at denne vellykketheten ikke betyr mye for den reelle verdiskapningen.

Verdiskapningen må vurderes av interessentene. Interessentene kan vi grovt sett dele i to grupper: De som skal bruke systemet og de som skal vedlikeholde systemet. Om et prosjekt har resultert i en fantastisk forbedring for mange brukere spiller det liten rolle om det har levert på avtalt tid. IT-prosjekter er uansett komplekse og nyskapende og vi bør ikke lure verken oss selv eller kunden til å tro at vi klarer å estimere omfanget med særlig grad av presisjon. (Les mer om ønsketenkning her)

Jeg har observert prosjekter som har levert på tid/kost/omfang, men som har bommet fullstednig på behovene. Eller like ille – som har etterlatt seg en elendig kvalitet og et unødvendig komplekst produkt som er lite vedlikeholdsvennlig. Samtidig er det også lett å finne prosjekter som har vært fullstendig mislykkede etter prosjektdefinisjonen tid/kost/omfang, men som allikevel har skapt fantastiske verdier for interessentene.

Jeg håper og tror IT-bransjen snart begynner å bli moden nok til å begynne å diskutere verdiskapning i stedet for leveranse i h.t avtale. Den dagen forskerne og advokatene interesserer seg mer for dette enn for overholdelse av kontrakt tror jeg vi har kommet et langt steg i riktig retning!

Det smidige manifest – fase 1 er over

De første 10 årene med Agile Manifesto har rystet IT-bransjen. På tide å oppsummere.

Om et par måneder er det 10 år siden 17 personer møttes på “The Lodge” i Wasatch mountains of Utah der de etter noen dager med diskusjoner signerte det smidige manifest (Norsk utgave her: http://agilemanifesto.org/iso/no/). Dette var representanter for Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development og Pragmatic Programming – alle ulike retninger og metodeverk som hadde det til felles at de brøt fundamentalt med tradisjonell prosjekttankegang. En slags visjon for et gigantisk endringsprosjekt! Som vi vet ble de enige om 4 overgripende utsagn som skulle beskrive de endringene IT-bransjen måtte gjennomgå for å utvikle bedre softwarebaserte systemer:

Personer og samspill fremfor prosesser og verktøy
Programvare som virker fremfor omfattende dokumentasjon
Samarbeid med kunden fremfor kontraktsforhandlinger
Å reagere på endringer fremfor å følge en plan

Hvordan er tilstanden her 10 år etter? Setter vi menneskene og kommunikasjon høyere enn prosedyrer? Setter vi fungerende programvare over dokumentasjon? Har vi blitt bedre til å samarbeide kunde – leverandør? Har vi klart å frigjøre oss fra detaljplanen og blitt gode til å håndtere endringer med største selvfølgelighet? Ikke lett å svare på dette selvsagt, men en viss bevegelse har det utvilsomt vært!

De fire utsagnene er veldig overordnede og umulig å bruke som målestokk for en framdrift fra høyre mot venstre. Da er det kanskje mer matnyttig å gå de tolv underliggende prinsippene litt etter i sømmene. Man finner norsk utgave at prinsippene her: http://agilemanifesto.org/iso/no/principles.html. Her kan det være på sin plass med en presisering. Manifestet har blitt forsøkt marginalisert og bagatellisert av tradisjonelle prosjektledere. Utsagnene sier ikke mye om graden av endring – det skal innrømmes – men jeg vil våge påstanden at samtlige av disse 17 både da og den dag i dag vil mene at det man er ute etter et et paradigmeskifte. Altså ikke prosjektstyring med visse justeringer og presiseringer.

En subjektiv evaluering

Jeg snakker med mange “smidig-entusiaster”, deltar på konferanser og meetups og jeg har jobbet med ca 25 ulike organisasjoner de siste 2 årene. Så jeg tenkte jeg skulle våge meg på en enkel og høyst subjektiv evaluering av “tingenes tilstand” i Norge ved inngangen til 2011.

De 3 første prinsippene gjelder enkelt sagt hyppige leveranser og kontinuerlig verdiskapning. Bemerk: Når manifestet sier leveranse betyr dette leveranse helt ut til brukeren og altså ikke ut på en test-server eller lignende. Her må vi nyansere litt, for det er en del tilfeller der hyppige leveranser er meningsløst. Dette er spesielt der hardware/firmware utvikling er sentralt samt enkelte markeder som av natur gjør store lanseringer av nye produkter (som f.eks spillbransjen).
Tilstand: Her er det enorme forskjeller; jeg kjenner til organisasjoner som har vært “smidige” i tre år og kun har levert en gang i året. Samtidig finnes det organisasjoner i Norge som leverer ukentlig med største selvfølgelighet. Det er nok spesielt innen kontraktsregulert systemutvikling at man fremdeles leverer sjelden.

Det 4. prinsippet tar til orde for daglig samarbeid mellom forretningssiden og utviklerne. Jeg tror mange kan oppnå stor forbedring om man ikke nødvendigvis har kontakt daglig – men prinsippet er godt.
Tilstand: Store forskjeller her og, men spesielt der hvor man driver egenutvikling av IT-systemer er det mange som får til dette. Igjen er det mest å hente i kontraktsregulerte prosjekter.

Det 5. og 6. prinsippet sier at vi må fokusere på motiverte, flinke folk som samarbeider tett og som får tilgang på den infrastrukturen og de hjelpemidlene de trenger.
Tilstand: her er vi blitt ganske gode i Norge! Mitt inntrykk er at de fleste føler at de blir hørt når de ber om bedre utviklingsomgivelser. Når teamene henvender seg til linja som team eller via en Scrum Master så blir de ofte hørt på og behovene tilfredsstilt. Unntak her synes å være de store organisasjonene som har utpreget kostnadsfokus. Distribuerte team er kanskje den største hindringen.

Prinsipp 7 sier rett og slett “Fungerende programvare er det primære målet på fremdrift.” Vel, dette krever jo at man har noe ferdig produkt å vise fram med jevne mellomrom.
Tilstand: I likhet med de tre første prinsippene varierer dette naturlig nok voldsomt. De som kjører kontraktsbaserte prosjekter vil ofte “rapportere framdrift” på en ganske tradisjonell måte.

Prinsipp nummer 8 tar til orde for å jobbe i et jevnt tempo.
Tilstand: De fleste som bruker Scrum har utnyttet dette med ganske stabile team over tid – og mange har sluttet å kjøre småprosjekter for å få ting gjort. Dette lager en fin rytme og stabil framdrift over tid. De som har lengst vei å gå her er nok de med veldig spesieliserte folk og de som jobber i kontraktsbaserte prosjekter.

I prinsipp 9 skal man ha kontinuerlig fokus på “teknisk kvalitet”. Dette henger igjen tett sammen med det å lage noe helt ferdig ofte slik at man får synliggjort og evaluert denne kvaliteten.
Tilstand: Ingen overdrivelse å si at dette varierer kraftig – det er veldig mange som sliter med gammel teknisk gjeld og når de innfører Scrum så blir det helt tydelig at dette smerter. De som er så heldige at de kan få starte fra scratch vil uten unntak (i min erfaring) ha stort fokus på “clean code”, enkelt design, kode-review og lignende tankesett for å addressere dette.

Det 10. prinsippet er “Rema 1000-prinsippet”; “Det enkleste er ofte det beste”. Unngå å lage mer funksjonalitet enn brukerne virkelig trenger. Brukervennlighet. Unngå å lage fancy, generiske komponenter – sørg i stedet for at arkitekturen består av løst koblede moduler som alle lar seg videreutvikle separat.
Tilstand: Igjen, de som er så heldige at de kan få starte fra scratch vil ofte angripe systemutviklingen på denne måten. Men dette problemet synes å leve i beste velgående i større offentlige prosjekter der men over tid har akseptert en voldsom kompleksitet. Når resepten blir et “SOA-prosjekt” er det slett ikke gitt at ting blir mye bedre…

Det 11. prinsippet tar til orde for å jobbe i selvstyrte team – hvilket jo er et krav i Scrum.
Tilstand: Mye står igjen her over hele linja. Selvstyrte team fordrer en ganske voldsom endring i kultur, holdninger og lederstil – hvilket selvsagt ikke skjer over natta. Jeg har sett noen få virkelig selvstyrte team som tar kollektivt ansvar og som har stor myndighet og selvstendighet. Men ikke mange.

Til slutt det 12. og kanskje viktigste prinsippet som handler om kontinuerlig prosessforbedring.
Tilstand: De aller fleste som bruker Scrum har retrospectivemøter som siste gjøremål i en iterasjon. Slett ikke alle klarer å utnytte dette til fulle – her ligger det etter mitt skjønn store gevinster å høste. Igjen er det nok de som har kontraktsbaserte prosjekter som sliter mest med uttellingen. Ikke helt opplagt at det lønner seg å legge sjela si i å forbedre metoder, verktøybruk og arbeidsformer i et midlertidig team i et tidsbegrenset prosjekt..

Konklusjon

Agile Manifesto har hatt en stor påvirkning på IT-bransjen. Ingen ignorerer dette lenger, men det er veldig varierende hvor omgripende endringer man er beredt til å innføre. Vi får jo her bekreftet at organisasjonsendringer nødvendigvis må ta tid. De siste 3-4 årene har det virkelig skjedd mye i Norge og i store deler av verden, men jeg har en følelse av at vi bare så vidt har begynt. Spesielt der man kjører kontraktsbasert utvikling – kanskje særlig innen offentlig sektor – kan man tjene mye på å utfordre prosjekttankegangen og ikke minst å fokusere mye mer på å forenkling, å fjerne konpleksitet og å unngå å pådra seg teknisk gjeld.

Scrum støtter ikke dette!

Vel overstått enda en Smidig-konferanse og igjen på tide med litt ettertanke. Har vi kommet videre? Har vi mer verdifull erfaring enn i fjor? Har vi en dypere forståelse av smidig? Av Scrum? Ser vi tegn til at misoppfattelsene er færre? Jeg har sett igjennom en hel del av lyntalene fra Smidig2010 og vil konkludere med at svaret er “ja, litt”.

Men jeg har lyst til å gripe fatt i ett fenomen som er en slags fellesnevner i en del av lyntalene; “scrum fører til …” eller “scrum støtte ikke …”. Og en undergruppe av disse er de som har erfaring med Scrum-prosjekter der de forsøker å få “prosjektlederoppgaver” til å passe inn i Scrum. Dette er jo ikke lett – vi skal jo nå klare oss med de tre rollene Product Owner, Scrum Master og Teamet. Og helt ærlig – veldig mange (de fleste?) klarer seg utmerket godt uten prosjektbegrepet. Men for de som jobber på kontrakt med ekstern kunde forstår jeg at det fremdeles er prosjekt som gjelder. I denne settingen vil vi operere med prosjekter og prosjektledere en god stund til. Men jeg mener bestemt prosjektlederrollen er utdøende i svært mange situasjoner. Unntaket er der man er nødt til å starte store, omfattende endringer på IT-systemer. Om man ikke i fremtiden klarer å unngå de store prosjektene da.

Vi må altså ikke glemme at vi er på en lang reise som på et vis startet i 2001 med Agile Manifesto. Manifestet er en slags visjon for en omfattende endring som hittil har pågått i 10 år. Vi er kanskje fremdeles i startgropa. De av oss i IT-bransjen som sverger til dette manifestet må aldri glemme at det er lang vei igjen til kundene og organisasjonene rundt oss legger til rette for smidig. Smidige kontrakter, smidig budsjettering (beyond budgeting), smidig linjeledelse osv vil gradvis bli vanligere. Men inntil vi er der, må vi stå på og kjempe for forandring – samtidig som vi må forholde oss til den virkeligheten vi er midt oppe i. Ikke helt enkelt det der!

Smidig er basert på en ledelsesfilosofi som bygger på Lean og Systems Thinking – som er et motstykke til tradisjonell tankegang som bygger på Frederich Taylor´s Scientific Management. Det jeg synes prosjektlederne som snakker om Scrum gjør er å forsøke å etablere strukturer basert på Taylors ideer om ledelse for å kompensere for manglene i Scrum. “Smidig er bra, men hvordan tilpasser vi Scrum slik at den funker i en vanlig prosjektsetting”. Disse prosjektlederne snakker lite om hyppige leveranser eller det å forbedre arbeidsmetodene gjennom hyppige retrospectiver…

Jeg forstår at hverdagen til en del prosjektledere og -deltagere er vanskelig. Balansegangen mellom å pushe kunden mot smidig, samtidig som vi må forholde oss til status quo er ikke lett. Men om vi lener oss tilbake og slutter å trykke på vil vi ikke få særlig endring – det bestående er trygt og vil lett vinne over endring som er ukjent og “farlig”.

Dette er også et pedagogisk dilemma. Vi MÅ lære bort Scrum slik det er tenkt å være i smidige omgivelser. Samtidig må vi klare å formidle at vi ikke kan unnlate å forholde oss til den virkeligheten, den “smidig-modenheten” omgivelsen er i i dag. Jeg synes det er trist å høre Craig Larman bli sitert slik: “Da må bare omgivelsene endre seg da” med dårlig skjult håpløshet i stemmen. Jeg betviler ikke at Craig kan ha sagt noe sånt – men den samme mann vil også gjerne snakke om at endring selvsagt vil ta tid – om man vil høre på det øret.

For ordens skyld: Scrum er mangelfull – og det er også meningen. Scrum er bare et maksimalt enkelt rammeverk med masse huller som man må fylle med fornuftige ting selv. Hele poenget er “Inspect and Adapt”, gjennom hyppig læring tilpasser vi oss og etablerer bedre og bedre praksiser som svarer på våre forretningsmessige behov. Dette ansvaret må vi ta selv. Vi kan med andre ord ikke skylde på Scrum om vi ikke lykkes.

Hvorfor deler de beste kunnskap hele tiden?

Eller: Hva er det som gjør at kunnskap flyter med største selvfølgelighet rundt om i noen organisasjoner, mens alt synes å stoppe opp andre steder?

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

Motivert av belønninger

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

Passer på sin posisjon

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

Jobbsikring

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

Mangel på helhetssyn

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

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

For øvrig – akkurat som foreskrevet i Scrum 🙂

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

Ønsketenkning som ledelsesfilosofi

Jeg liker å filosofere over ting jeg observerer, og fra tid til annen dukker det opp problemstillinger som gjelder både privat og jobb. Et eksempel på dette er menneskers tilbøyelighet til å tro på ting de skulle ønske var sant. Ønsketenkning er et godt eksempel på en menneskelig svakhet som vi alle har i større eller mindre grad.

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

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

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

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

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

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

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

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

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

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

—

Om 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” https://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!

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