Tittlen er et kjent slagord fra miljøbevegelsen når det gjelder hvordan man skal bekjempe klimaproblemene vi står ovenfor. Jeg føler det samme slagordet gjelder for smidige metoder og hvordan man best klarer å få smidige metoder til å fungere i sin organisasjon.
Smidig systemutvikling handler veldig mye om kommunikasjon og mellommenneskelige relasjoner. Likevel er dette et element som veldig skjelden blir adressert hverken i prosjekter eller i debatter om smdige metoder. Allistar Cockburn har skrevet en del om dette i sin utmerkede bok Agile Software Development, likevel føler jeg at det er et poeng han og mange andre glemmer å adressere: kulturelle forskjeller.
Kulturelle forskjeller utgjør den store forskjellen
Kommunikasjon mellom mennesker i jobbsammenheng i Norge og for eksempel i Tyskland er veldig forskjellig. Tyskland har en mer hierarkisk måte å forholde seg til hverandre enn hva man har i Norge. Tilsvarende er det forskjeller mellom Japan, USA, Polen, Svergie, Danmark også videre også videre. Disse kulturelle forskjellene mener jeg er noe man i større grad bør adressere når man diskuterer hvor smidige metoder skal gå videre nå.
Veldig mye av litteraturen om smidige metoder handler kommer fra USA og er veldig farget av hvordan arbeidsmiljøet er der borte. Måten man jobber på i USA er veldig forskjellig fra hvordan vi gjør det i Norge. Dette gir seg særlig utslag i en av de viktigste delene av en smidig metode, nemlig retrospectives. Et interaktivt forum hvor man skal åpent utviksle erfaringer og forbedringer vil kreve ulike teknikker i et amerikanske arbeidsmiljø enn i et norsk. Grunnen er at norsk arbeidskultur har et helt annet sett med grunnverdier enn det som er vanlig i blant annet USA.
Gjør lokale tilpassninger
Når du og din organisasjon har begynt å jobbe med smidige metoder er noe av det viktigste dere kan gjøre når dere har fått litt erfaring er å forsøke gjøre lokale tilpassninger. Still spørsmål rundt hvorfor dere gjør tingere dere gjør? Hvorfor gjør vi stand-up? Fungerer retrospectives slik vi gjør de? Passer stand-ups til de menneskene vi har i vår organiasjon? Har vi personligheter som gjør at vi får noe ut av retrospectives?
Dette er noen av spørsmålene som dere bør stille dere slik at dere kan gjøre lokale tilpassninger til smidige metoder som f.eks Scrum. Still spørsmål ved alt og se på hvordan det passer til din organisasjon. Deretter gjør dere endringer eller justeringer slik at dere får en metode som passer dere organiasjon.
Norsk smidighet
Jeg føler at det mest konstruktive man kan gjøre når man snakker om å videreutvikle smidige metoder her i Norge er å gjøre lokale tilpassninger som tar høyde for hvordan man nordmenn kommuniserer og arbeider i Norge. Særlig ville jeg lagt vekt på hvordan retrospektives gjøres, for her er ikke nordmenn særlig flinke. Vi er generelt altfor positive og tilgivende ovenfor dårlige rammebetingelser. Dette er noe som er et problem ettersom man da ikke får gode tilbakemeldinger på hvordan metoden fungerer.
Det er vitkigere å komme med tillegg til det smidige manifest enn å lage komersielle innpakninger for å selge konsulenttimer slik som man har gjort med Agile 2.0. Miljøet rundt smidige metoder i Norge er veldig levende og det er veldig mange flinke folk som bidrar i debatter. Jeg er sikker på at det norske smidige miljøet kan ta smidige til det neste steget ved å gjøre tilpassninger som reflekterer hvordan man samarbeider i norsk arbeidsliv.
I andedammen her i Norge har skeptikerne til smidige metoder virkelig fått vann på mølla ettersom flere og flere “står frem” med sine historier om hvordan de ikke har vært på et eneste bra smidig prosjekt.
Smidige fundamentalister vil gi deg følgende svar: “Hvis det ikke virker, så gjør du det feil”. Hvilket egentlig ikke er noe svar siden det ikke gir den som sliter noen løsning. Særlig ettersom svaret på “hva er riktig måte?” ofte er: “Du må bare tilpasse og plukke det som passer fra Scrum”. Igjen er dette svaret like nyttig for en som ikke får til smidige metoder som det vil være å si til en nyfødt baby: “Hvordan skal vi ta på bleien idag?”. Uten god kunnskap og erfaring vil hverken du som nyfrelst Scrum bruker eller babyen klare å velge riktig fremgangsmåte.
Å tilnærme seg en smidig systemutviklingsprosess med disse tankene i hodet er en nøkkel til å lykkes med smidige metoder. Akkurat som kampsporteleven må også organisasjoner / prosjekter gå gjennom de tre stegene for læring. Det viktigste er å innse på hvilket nivå man faktisk er.
Hvis du er ny til Scrum så mener jeg du bør følge det du har lært til punkt og prikke som en mal (du er i Shu stadiet). Dette helt til du har målt og erfart hvilke teknikker som ikke passer for din situasjon (du er kommet til Ha stadiet). Da har du oppnådd større innsikt til å gjøre kvalifiserte valg og tilpassninger. Etterhvert vil du se fler og flere ting som du kan gjøre av tilpassninger for at det skal passe i din organisasjon (du har nådd Ri stadiet).
Det viktigste er at du må gå gjennom alle tre stadiene. Du er ikke si at du er så smart at du kan gå rett på å tilpasse smidige metoder uten erfaring.
Forsøk å i ikke tenke til å begynne med, det vil hjelpe i det lange løp.
Smidige prosjekter handler også om teknologi
I iveren etter å være smidig glemmer mange at metoder som Scrum faktisk ikke sier noe som helst om den tekniske gjennomføringen av et prosjekt. Derfor ender mange prosjekter med å “glemme” viktigheten til de fundamentale teknikkene som du finner i blant annet eXtreme Programming:
Test drevet utvikling
Kvalitet på testkode
Automatisert utrulling
Objekt orientert design
Ivrige Scrum-praktikere glemmer ofte bort viktigheten til det å ha smidig teknologi og smidige metoder for å jobbe med teknologi. Hvis du ikke fortsetter å ha fokus på disse grunnleggende tingene vil du aldri lykkes med smidige prosjektmetodikker. Du vil feile om og om igjen inntil du innser viktigheten av å se smidig systemutvikling i en helhet, hvor du må velge teknikker så lenge du ikke ødelegger balansen mellom dem.
To ting kreves for å lykkes med smidige metoder
Ikke tenk når du er ny til smidige metoder, gå igjennom de tre stadiene av læring.
Ikke fokuser utelukkende på prosjektmetodikk, men også tekniske metoder for systemutvikling.
En smidig tilnærming til samarbeid og problemløsning er ikke noe som bare gjøres i programvareutvikling, det gjøres også når man skal bygge enorme konstruksjoner. I Discovery Channel programmet Build It Bigger viste de historien om hvordan Washington fikk et nytt baseball stadion for sitt lag Washington Nationals.
Det at man lager enorme stadioner i USA er ikke noe oppsiktsvekkende, men det som gjorde meg “varm under kraven” var hvordan de gikk frem for å bygge denne stadionet. Arkitektene og byggmesterne hadde utrolig dårlig tid for å få stadionet ferdig til sesongstart. Derfor valgt de å dele opp byggingen i “10 pizzastykker” og utviklet den helhetlige arkitekturen og utseende for stadionet underveis. Nå dette høres veldig kjent ut og høres ut som hvordan man gjør smidig systemutvikling.
En av tingene man høre om en iterativ måte å arbeide på er at man “mister oversikt over helheten”. Hvis en team med utbyggere og en gjeng arkitekter klarer å bygge et enorm baseball stadion, så burde vel det være mulig også i programvare utvikling?
Erfarne og kompetente fagfolk gjør iterativ, inkrementell og evolusjonær utvikling uten at noen trenger å fortelle dem det. Erfaring kalles egenskapen som gjør at du er i stand til å holde øye med helheten samtidig som du kan fokusere på detaljene. Jeg tror nøkkelen til å mestre balansen mellom disse tre tingene og dermed også til å bygge gode arkitekturer i smidige prosjekter ligger i å ha mennesker med erfaring fra smidige prosjekter til å ha oppsyn med det. Her er det viktig å presisere at du må ha erfaring fra smidige prosjekter. Jeg mener mange gjør feil i å ikke bytte ut eller oppdatere sine beslutningstagere før de begynner med smidig systemutvikling. Manglende praktisk erfaring er en av hovedårsakene til at mange føler de ikke lykkes med smidig systemutvikling.
Kravene til en arkitekt i smidige prosjekter er litt anderledes enn i tradisjonelle prosjekter. Du må kommunisere mer og justere oftere enn hva som er vanlig. Tiden du får til å komme opp med løsninger er også begrenset, slik at du må i lang større grad dyrke frem en arkitektur fremfor å bruke månedsvis på å designe den i UML og PowerPoint. Denne evnen er ikke noe alle arkitekter har i blodet og dette er en utfordring man må forsøke å løse.
Mitt råd er å enten leie inn erfarne arkitekter fra smidige prosjekter eller kjøre små pilot prosjekter hvor dine folk kan prøve og feile. Hvis du ikke gjør det tror jeg du vil ha store problemer med å innføre smidige metoder i din organisasjon.
I anledning Software 2009 skal jeg holde en lyntale hvor jeg tar opp et tema jeg, og veldig mange andre jeg har snakket med, føler smerten til på daglig basis:
Programvare arkitekter som ikke jevnlig utfører praktisk utvikling påfører sine bedrifter enorme kostnader
Hvordan kan jeg påstå noe slik når det jo er de beste som får det store ansvaret av å være arkitekter? Årsaken mener jeg ikke er manglende kompetanse, men snarere en gradvis fjerning fra der hvor den faktiske produksjonen skjer. Denne distansen gjør at man i stadig mindre grad er i stand til å gjøre gode vurderinger på enkelt saker.
Gjennom å i stadig mindre grad ta del i det daglige arbeidet havner arkitektene i en situasjon hvor man stort sett kan beslutte på generelt grunnlag og gammel kompetanse. Konsekvensen for bedriftene er at man ofte får en teknisk infrastruktur som stagnerer og som tilslutt må byttes ut til enorme kostnader. I stedet for at man har gradvis forbedret og oppdatert infrastrukturen har man hele tiden kjørt “safe” og med det man kan godt fra før.
Kontinuerlig forbedring
Hvordan unngår du så at de som tar beslutninger har detaljkunnskap og praktisk erfaring nok til å kunne holde seg oppdatert? Arkitekter må plasseres ut i praktisk arbeid. Dette heter eat your own dog food eller Pain Driven Development. Gjennom å la arkitektene føle på kroppen hvordan det er å utføre vanlige systemutviklingsoppgaver etter retningslinjer de selv har lagt vil også de føle på kroppen behovet for kontinuerlig forbedring av arkitektur og infrastruktur. Gjennom å skape en kultur for endring og kontinuerlig forbedring vil bedriften spare store summer gjennom at de slipper store prosjekter for oppdatering av utdatert arkitektur.
Hvis du synes dette høres spennende ut, så kom på Dataforeningens Software 2009.
Hvis man til enhver tid har øyne og ører åpne vil man kunne lære noe nytt i de mest pussige situasjoner. Dette gjelder også når du ser TV på en lørdag kveld. Jeg så Chris Rock sitt Kill The Messenger show på SVT2 denne helga. Ikke bare var showet hysterisk morsomt, men det inneholdt også jobb relaterte råd! Hvem hadde trodd at en av de mest reflekterte uttalelsene jeg har hørt siste året om jobb kommer fra Chris Rock?
Spørsmålet han stiller publikum var: har du en jobb eller har du en karriere? Chris var kjempefornøyd med at han ikke lengre måtte ha en jobb nå som han hadde en karriere. En jobb er noe du gjør 9-17 og du får lønn (i Rock’s tilfelle var det å skrape reker på en rekerestaurant i Brooklyn). En karriere derimot er noe du har når du virkelig tjener penger.
Du skaper din egen karriere
Jeg har sett mange kolleger og andre i bransjen som alltid har veldig mange årsaker til hvorfor de ikke gjøre ulike ting. “Jeg kan ikke jobbe test drevet fordi prosjekt lederen gir meg ikke tid”. “Prosjektet suger fordi vi bruker utdatert teknologi og arkitekten er en dust”. Denne typen uttalelser kommer oftest fra de som har en jobb og som ser på det de gjør som en jobb.
Hvis du derimot ser på det du gjør som en karriere lar du ikke detaljer som lite tid og inkompetente arkitekter hindre deg i å gå videre i din karriere. Du finner måter å komme deg rundt hindringene på slik at du kan komme videre.
Hvis alt du kommer opp med er unnskyldninger til hvorfor du ikke gjør ulike ting, så er det heller ikke rart du ikke får nye arbeidsoppgaver eller at du aldri får gjøre noe du synes er spennende. Muligheten til å gjøre spennende ting skaper du selv og du kan ikke vente på at de lander i fanget ditt. Du må ta det du gjør som en karriere og ikke en jobb du får betalt for. Hvis du er en utvikler som ser på det du gjør som en jobb og er fornøyd med det, så må du heller ikke forvente å gjøre spennende ting. Du må jobbe for å komme i riktig posisjon, du må ta sjanser, du må stille spørsmål.
Så still deg selv spørsmålet: Har jeg en jobb eller har jeg en karriere?
Elegante løsninger?
Det Chris sier her sammenfaller veldig med ideène som Mathew E. May skriver om i The Elegant Solution: Toyota’s Formula for Mastering Innovation. Boken handler om hvordan Toyota har skapt et system for kontinuerlig inovasjon og at dette er nøkkelen til at de er verdens beste bil produsent. Arbeidsgivere må i følge boken få sine ansatte til å føle at de har en karriere, langt mer enn at de har en jobb.
Desverre kunne ikke YouTube finne akkurat sekvensen jeg refererer til, likevel så legger jeg med en godbit fra showet Kill The Messenger:
Hvis man til enhver tid har øyne og ører åpne vil man kunne lære noe nytt i de mest pussige situasjoner. Dette gjelder også når du ser TV på en lørdag kveld. Jeg så