Å holde foredrag på konferanser eller for selskaper er noe jeg ikke slutter med, men det er ikke noe jeg gjør som et eget selskap. Hvis du ønske å ha meg til å komme til din bedrift eller konferanse så kommer jeg gjerne.

I ånden av skamløs selvpromotering så legger jeg ved en link til intervjuet jeg ga til Mine Verktøy. Der kan du også lese om hva historien er bak maskinen under (det som ikke står er at den kostet meg 500 kroner donert til WWF og den har Dell Enterprise support!!).

Hva har DU laget?

Det er både inspirerende og lærerikt å lese om hva andre bruker av verktøy og utstyr, men minst like spennende er det å se alt de sinnsykt kule de lager. Fordi det er hva jeg føler det å være programmerer handler om. Ikke en søken etter en eller annen høyere form for forståelse av programmering, det handler om hva du lager. Du har ikke min respekt om alt du kan gjøre er å referere til hvordan du ville gjort ting eller hva andre gjør. Vis meg hva du har gjort, og du vil få min anerkjennelse. Hvis du kun kan referere til tomt snakk, så får du prøve igjen (når det er sagt, hvem er vel egentlig interessert i hva jeg mener?;)).

Det er riktignok en ting som har slått meg etter å ha reflektert over det som ble sagt under konferansen. På meg virket det som det var en opplest sannhet, og da er det alltid grunn til å bli skeptisk, at det var viktigere å stadig “bli smidigere” enn å “være smidig”. Under konferansen så tenkte jeg: “ja, det er vel bedre enn ingenting”, men i ettertid så er det ikke tvil om at det nok ikke nødvendigvis er slik.

Typisk norsk å være…

Typisk norsk å være middelmådig pleier jeg som regel å si. Vi nordmenn er oppdratt til å senke seg oss ned på nivå med gjennomsnittet gjennom tidlig innføring i jantelov og sosialdemokratiske prinsipper. Derfor er det jo bare naturlig at vi også viderefører dette i arbeidslivet. Hvorfor skal vi ikke være puristiske å kreve at man faktisk gjør det som kreves for å oppnå full effekt av smidige metoder? Det at enhver som prøver litt skal slå seg på brystet og si jo vi jobber iterativt, inkrementell og evolusjonært (dette er Reidar Sande sin herlige definisjon av smidig fra Smidig 2008 i lyntalen Ble Mona Lisa malt iterativt, inkrementelt eller evolusjonært?) trekker de som virkelig får det til ned i gjørma.
“Vi jobber stadig smidigere, og derfor vil vi vinne over de som er smidig” var noe som ble ytret på konferansen. Det utsagnet er såpass meningsløst og flåsete at det kunne vært tatt ut av FrP sitt program. Fordi man har manglende evne til å innføre smidige metoder så skal man være likeverdig med de som faktisk får det til? I stedet for å jobbe hardere så påberoper man seg en offerrolle hvor man føler seg urettferdig behandlet av “de andre” som bare er ønsker å heve seg over “folk flest”.

En gris er fremdeles en gris selv om du tar på den hatt og frakk

Du vet at det er noe fishy på gang i det noen sier: “vi kjører smidig, men..”. Etter men så kommer det alltid en eller annen bortforklaring eller tåkelegging rundt de delene som ikke er smidig. “Vi er smidig, men leverer tre ganger i året”. “Vi er smidig, men vi har design up front og massevis av kontrakter”. Det hjelper ikke å ha en intensjon eller en visjon om å være smidig. Du må faktisk legge inn den jobben og gjøre de grepene som kreves for å kunne etterleve det.
Jeg synes ikke det skal være nok å stadig “være smidigere”. Det er bare en unnskyldning for manglende evne til endring og man bruker smidig ordet bare fordi det er trendy. De som snakker om dette vil på et blunk kunne bytte til “det neste hotte”, fordi de i praksis alltid kjører som de alltid har gjort.
Hjelper ikke om du kler ut din rigide tungrodde prosess med smidige hatter og skjerf, du er hva du er uansett kostymer.

Det er bare hardt arbeid som får deg i mål

Min oppfordring er at vi skal slutte å godta at smidig begrepet dras gjennom gjørma og gruppevoldtas av tilfeldig praktikanter ved passende anledninger. Vi skal konfrontere og kle av alle de som poserer som smidig fordi det er trendy. Hvorfor skal man senke ambisjonene bare fordi ting er litt vanskelig? Hvorfor skal vi godta at “bli litt smidigere” er likeverdig med å faktisk være smidig?

Å jobbe smidig er knallhardt arbeid som tar veldig lang tid, så det er bare naturlig at mange sliter med å få det til. Derfor er det så utrolig viktig at man ikke stopper halvveis også sier det er nok. Ingen har sagt at det å få til smidig utvikling i en organisasjon er enkelt, så det er bare å brette opp armene og erkjenne hvor man står og fortsette arbeidet.

En takk går til programkomiteen som lot meg slippe til med et tema som kanskje er litt utenfor, men som likevel så ut til å være spennende for mange. Personlig trodde jeg at det enten ble meg og noen gamle kolleger som kom dit, men det var utrolig gledelig å se et pakket rom. Det var utrolig spesielt å snakke foran en tydelig engasjert gjeng som også stilte en rekke veldig bra spørsmål etter jeg var ferdig, så tusen takk til dere som kom.

Det å presentere

Veldig mange sier at det å holde foredrag handler 80% om det å presentere og 20% om innholdet. Jeg er veldig enig i dette, hvis ikke den som står på scenen faktisk gir av seg selv og forsøker å gjøre det spennende for de som hører på så burde egentlig hele salen gå. Personlig gjør jeg dette veldig ofte, klarer ikke den på scenen å skape en kobling med de som hører på så kan du heller lese slidene etterpå eller se videoen. Du får ingenting ut av å sitte der.

Selvsagt er det utfordringer ved å fokusere mye på hvordan man presenterer, fordi det er ikke alle som da klarer å få med seg hovedbudskapet. Dette forstod jeg da jeg så artikkelen Slik tapte vi for Spotify på digi.no, hvor journalisten hadde valgt å fokusere på de tabloide utsagnene som ikke var en del av hovedbudskapet som gikk på innovasjon og det å starte opp selskaper. Det er selvsagt nyttig erfaring å ta med seg videre og forsøke gjøre det slik at enda fler får med seg det viktigste. Heldigvis var nok journalisten i mindretall, for jeg fikk mange gode tilbakemelding på nettet og fra folk som var i eller hadde jobbet i oppstartsfirma at jeg hadde noen gode poenger.

Hvordan jobbe med presentasjon?

Det er mennesker som skriver bøker om emnet og holder foredrag om nettopp dette. Personlig så har jeg ikke lest noe særlig av slike ting, fordi jeg har en enkel filosofi: Jeg holde kun foredrag om ting jeg bryr meg om.

Dersom jeg skulle holdt foredrag om andre ting, ja så kanskje hadde jeg hatt behov for en metode eller lignende for å komme frem til en presentasjon. Kanskje hadde jeg måtte øve mye og trent på hvordan levere ting. Gitt at jeg alltid snakker om noe jeg brenner for eller som jeg er veldig engasjert i så har jeg ikke behov for noen metode for å komme opp med foredraget (ok, kanskje avsnittene nedenfor kan regnes som en metode, hva vet jeg). Det bare kommer av seg selv, fordi jeg har noe å si.

Til årets JavaZone brukte jeg i underkant av ti timer på å forberede foredraget. Det gikk med litt tid til å få slidene til å matche musikken på introen, men til å sette opp selve foredraget så brukte jeg lite tid. Siste uka før konferansen begynte jeg å sette opp selve presentasjonen. Før det hadde jeg satt opp noen mind maps hvor jeg hadde lagt inn hoved poengene og utover det foregikk forberedelsene i hodet mitt. Jeg føler at det er bedre å gå å gjøre presentasjonen i hodet en del ganger, visualisere hvordan det skal gjøres, fremfor å begynne å hacke ting inn i slides.

Å lage slides er like kjedelig som å skrive manuelle test script

Å lage slides er, for meg, en svært lite kreativ prosess og noe jeg forsøker å bruke minst mulig tid på. Det er som når man skrev stil på skolen og måtte føre inn med penn (ja, så gammel er jeg at jeg ikke kunne levere stil elektronisk). Oppsett av slides er å føre inn for meg, kjedelig men nødvendig likevel. Jeg gjør det slik fordi jeg vil ha mest mulig frihet til å tenke på hvordan ting skal leveres på scenen så lenge som mulig. Det å sette opp slides gjør ting veldig endelig og det er mye jobb å rette opp i ting etterpå. Ved å ha mind maps og ting i hodet så er det ekstremt lett å gjøre justeringer :)

Det eneste som jeg pleier å øve på er introen. Den aller første setningen må sitte og der er det etter min erfaring veldig dumt å ta det på sparket. Kommer du skeivt ut allerede i det du sier hva du skal snakke om, så kan det fort gå bare nedover fra der. Derfor sørger jeg alltid for å ha helt klart for meg hva første setning er. Alt etter det tar jeg på sparket. Å gjøre selve foredraget er noen ganger litt sånn ut av kroppen opplevelse. Det har hendt at jeg har blitt både overrasket og flau når jeg har sett meg selv på video etterpå fordi jeg trodde virkelig ikke at jeg sa det.
Jeg tror at om jeg hadde øvet inn alt jeg skulle si, så hadde ikke foredraget blitt noe bra. Alt jeg øver inn er første setning og etter det ser jeg bare på flyten i presentasjonen og at det er en bra historie som fortelles. Det er langt viktigere at slidene danner en bra ramme som jeg bare kan snakke ut i fra uten å ha trent inn noe.

Sannelig virker det som jeg har en metode likevel når jeg leser dette her, men jeg tror ikke jeg vil anbefale noen andre å følge den. Finn ut av hva du må gjøre for å føle deg trygg når du skal levere noe også gjør du det. Ikke les en bok eller hør på sånne som meg. Lag din egen måte å gjøre det på, så kommer det helt sikkert til å være veldig mye bedre enn å adoptere andre sine metoder. Dette gjelder ikke bare det å gjøre presentasjoner, men også ting som blogg innlegg. Skriver du fra hjertet om noe du brenner for så blir det stort sett bra og folk skjønner det. Ikke hør på en eller annen “kjendis blogger” som skal fortelle deg hvordan du skal gå frem for å skrive blogg. Det er egentlig veldig enkelt: Har du noe på hjertet, så skriv det. Hvis du ikke egentlig har noe å melde, vel så la være å skriv det blogg innlegget. Vi trenger virkelig ikke flere innholdsløse blogger på nettet :)

Kjære konsulent med fin tittel, kom deg ned av scena!

På JavaZone er det ekstremt mange konsulentselskaper som ønsker å profilere seg og det har hjulpet konferansen til å vokse seg til å bli en av de største. Problemet med dette er at de samme selskapene tvinger folk som aldri burde stått foran et publikum til å holde foredrag fordi de har en tittel som tilsier det. Jeg har en bønn til alle dere som tvinger i utgangspunktet veldig dyktige mennesker til å gjøre noe de åpenbart ikke er skikket til. Du bør settes foran et publikum bare fordi du er flink, du skal være foran publikumet fordi du klarer å formidle et budskap. Å kunne lese opp dine egne slides holder rett og slett ikke.

Det handler om å levere

Jeg konstaterte på at det var noe murring om nordmenn som ikke snakket på engelsk og slike ting. Det er godt mulig de snakket om meg også her, for jeg hadde tittel og slider på engelsk men snakket på norsk. Hvorfor gjorde jeg det? Først og fremst av respekt for de som kommer å hører på. Nå tenker du kanskje at det var en rar ting å si ettersom det kan være noen som ikke forstår engelsk i salen. Jeg mener det er bedre å faktisk være i stand til å formidle noe til 80-90% av salen, fremfor å stå der å stotre på håpløs engelsk og bruke all energi på å forsøke å huske hva faen det var du skulle si. Flere foredrag jeg så på JavaZone var på såpass dårlig engelsk at jeg strengt tatt tror de engelsktalende hadde problemer med å forstå det likevel. I tillegg så var det folk som jeg vet kan holde bra foredrag som fremstod som ubrukelige fordi de ikke gjorde det på sitt morsmål.

Derfor mener jeg det er en respektfull ting å gjøre å faktisk innse at, nei jeg kommer ikke til å klare å levere en bra presentasjon som engasjerer de som hører på om jeg gjøre det på engelsk så jeg gjør det på morsmålet mitt. Da er det i vertfall en viss kvalitet på det jeg gjør og jeg kan skape den stemningen jeg ønsker. De som ikke forstår norsk kan forlate salen og heller se på slidene, eventuelt snakke med meg etterpå. Jeg skulle selvsagt ønske at jeg hadde tid til å øve tilstrekkelig slik at jeg kunne gjort foredraget på engelsk, men det var ikke mulig i år. All respekt til de som gjorde det og klarte det bra, dere er mer dedikert og flittig enn meg :)

Digital samhandling

Det skulle være to typer funksjonalitet i applikasjonen:

• søke frem produsenter hos Matvaretilsynet for å se detaljinformasjon
• hente frem informasjon om alle merker en produsent hadde.

Elektronisk samhandling er veldig i vinden om dagen, men det er åpenbart at veldig mange har veldig mye å lære når det gjelder hva dette innebærer. Tilgjengeligheten på tjenestene fra Mattilsynet sett fra en programmerer si ståsted er ekstremt dårlig. De to kallene jeg behøvde å gjøre hadde et API som ikke lignet i det hele tatt. Det kunne like gjerne vært fra to ulike aktører. Dette er selvsagt altfor dårlig. Elektronisk samhandling er mulig dersom aktørene forstår hva slags ansvar det innebærer og er profesjonelle nok til å sørge for å ha konsistente APIer på tvers av sine tjenester.

Enkel brukerflate for en enkel applikasjon

Applikasjonen består av to helt enkle skjermbilder hvor brukerne kan søke frem produsenter. Begge skjermbildene var med i første leveranse som ble utviklet.

En utfordring ved å benytte WebServices støtten i Flex 3 er manglende støtte for vanlig HTTP autentisering, men takket være god hjelp fra andre utviklere som har vært i samme situasjon var dette løst raskt. Utover dette var det datamengden i skjermbildet for visning av antallet merker som var en stor utfordring og er noe som skal løses i kommende leveranser.

Tur-retur på fire timer

Hurtig utvikling ved hjelp av Flex rammeverket kombinert med AIR teknologien gjorde det mulig å implementere og installere hos kunden en applikasjon i løpet av 4 timer. Siden den gang har applikasjonen blitt utvidet med mer funksjonalitet, men dette har vært tillegg og ikke store omskrivninger. Du kan jobbe utrolig raskt og med høy kvalitet takket være Flex rammeverket’s muligheter til å bygge datadrevne applikasjoner. Å ta en rask prototype for så å bygge den ut er enkelt når du følger dette ene prinsippet.

Overgangen fra prototype til ferdig applikasjon opphører og det sparer en for tid og penger. AIR rammeverket sin innebygde støtte for automatisk oppdatering gjør det enkelt å stadig legge ut nye versjoner til brukerne uten at det blir noen drift- eller forvaltningskostnader i forbindelse med utrullingen.

Heldigvis tok det seg veldig opp etter dette og fokuset var ikke så mye på åpen kildekode, men langt mer om deling av data og tilgjengeliggjøring av disse gjennom åpne standarder. I tillegg var det noen spennende keynote speakers fra utlandet som var med å krydre konferansen. Blant annet Stefan Engeseth sitt foredrag om å “bli i ett med kunden” var et friskt pust hvor han ikke var redd for å tal de store og suksessfulle midt i mot.

Fri programvare i Statens pensjonskasse

Nedenfor er mitt foredrag på GoOpen hvor jeg fortalte om hvordan Statens pensjonskasse forholder seg til fri programvare og hvordan SPK bidrar til miljøet.

Fri programvare i Statens pensjonskasse from Friprogsenteret on Vimeo.

Alle foredragsholdere mottok en hvit konvolutt hvor det lå en donasjon til Leger Uten Grenser på noen kroner. Dette var et veldig bra tiltak og langt bedre enn ostehøvler og andre ting. Kan være noe å tenke på for andre konferanser i Norge også? Jeg ser på dere JavaZone og Smidig.no Alt i alt en kul opplevelse å delta på GoOpen og det er ingen grunn til ikke å møte opp der igjen neste år.

Lille speil på veggen der…

Jeg hadde gleden av å delta på Mike Cohn’s Scrum Master “Sertifisering” i fjor og en av tingene jeg sitter igjen med er det Mike sa om at:

“Scrum løser ingen problemer, den bare viser deg problemene dine”

Dette er selvsagt ikke noe som du nevner når du selger inn metoden, ettersom ingen vil ha noe som bare viser deg problemene uten noen løsning. Følgelig blir veldig mange skuffet når det viser seg at Scrum kun visualiserer og bringer for dagen alle problemer du tidligere har forsøkt å feie under teppet. Du titter i speilet og alt du ser er utfordringene du har slitt med tidligere og dette fra noe som alle mener er så bra. Naturlig nok sitter en ofte skuffet tilbake og begynner å se etter neste ting som lover å løse dine problemer uten noe jobb. Det er også en del andre ting som Scrum lover og dette snakker Geir Amsjø om i Hva oppnår du med Scrum?.

Arbeit macht frei

Arbeidet skal sette deg fri, og slik også når det gjelder metodearbeid. Hvis du skal lykkes med å implementere en metode må du være beredt på at det krever endringer. Gjerne store endringer som vil gå langt utover f.eks et prosjekt. Scrum vil i stor grad vise deg hvor problemene er og hvorvidt du skal få ønsket effekt ved å bruke Scrum avhenger 100% av din evne til å endre omgivelsene. Uten store endringer i både prosjekt og i omgivelsene vil du aldri lykkes særlig bra med Scrum.

Klarer du ikke å ha hyppige leveranser fordi du har en driftsorganisasjon som evner å ta i mot mer enn 1 gang i året? Vel, da må du ta tak i det. Hvis du ikke har noen som kan fungere som produkteier eller være kravstiller, ja så må du ta tak i dette å stable noe på beina.

Når Scrum ikke er nok..

Dette med endringer rører ved noe av det som mange snakker om i disse dager, nemlig at Scrum er en metode for prosjekt gjennomføring. Et prosjekt er noe flyktig som har en start og en slutt, mens organisasjonen som betalte for prosjektet består. Mangelen på helhets fokus er hva jeg mener er Scrum’s akilleshæl. Metodikken gir deg kun hjelp til å belyse mangler og gjennomføre et prosjekt. Utover dette er du på egenhånd og får liten hjelp. Organisasjoner trenger et helhets fokus og en måte å tenke på som hjelper i mer enn bare praktisk prosjektgjennomføring.

Lean, the “new” kid on the block

Veldig mange har begynte å snakke om Lean som et svar på manglene vi har erfart med Scrum. Mytologien rundt Lean har mange ingredienser som gjør at det er en sikker hit blant IT-folk: et ekskluderende vokabular av Japanske ord, har sitt opphav i østlige tanker og er noe nytt. Tiltross for all hypen som vi har sett, og som vi kommer til å se enda mer av i årene som kommer, så tror jeg faktisk at helhets fokuset i Lean er hva Scrum mangler for større organisasjoner.

En ting jeg åpnebart formidlet uklart var dette rundt spesialistenes rolle i smidige prosjekter. Mange tolket mine utsagn til at man skulle ha spesialister som kun jobbet med sin spesialitet og at ingen andre på teamet gjorde det. Dette er like dumt som bare å ha generalister og mitt poeng er at du må sørge for å utnytte spesialisten slik at du hever kompetanse på resten av teamet. Spesialisten må selvsagt kunne gjøre mer enn sin spesialitet og det er viktig å sørge for at spesialistens kunnskap kommer resten av teamet tilgode.

Det var også nevnt i diskusjonene at spesialister som får jobbe i fred på sine egne ting er et kjempeproblem når denne personen ikke lengre er til stede, og igjen er jeg helt enig her. “Smarte” programmerere er et kjempe problem dersom de sitter alene å koker opp noe, så de må selvsagt tvinges til å jobbe med noe annet også.

Lyntaler er ofte slik at de fungerer best om man ikke tar med de grå nyansene, og jeg holder de som regel med Caps lock’en på. Slik at det er selvsagt mange nyanser rundt tingene jeg snakker om i Det Smidige Sosialdemokratiet, men det blir en kjedelig tale om jeg tar med det også.

Takk til alle som kom med spørsmål og feedback under Meetup’en, det var utrolig gøy å få snakke der og jeg gjør det gjerne igjen.

Du vil i tillegg til å få med deg mange spennende taler også ha mulighet til å diskutere med de som holder dem, så det er din mulighet til å komme i dialog.

Hvis ikke får du nøye deg med videoen nedenfor av lyntalen min.

Det Smidige Sosialdemokrati from leif on Vimeo.

Begrepet brukes til veldig mye rart og har blitt en viktig ingrediens i alle dokumenter om visjoner og strategier. Alt skal være enkelt. En annen setting hvor enkelhet nevnes hyppig er i diskusjoner rundt konkrete løsninger. Her brukes begrepet ofte som hersketeknikk hvor den som kommer med “men det er jo ikke enkelt” eller “det er unødig komplisert” forsøker å parkere andre forslag. Det er i denne andre konteksten hvor det hele tiden har skurret i hodet mitt. Veldig ofte bruker man begrepet enkelt på en måte som tilsier at noe skal være banalt eller simpelt. Løsninger som involverer teknikker eller noen biblioteker blir ofte merket som kompliserte (ofte med unødvendig som prefix).

Enkelhetens lover

Enkelhet kan oppnås på mange måter, hvor en av de er å redusere og fjerne noe. Dette er grunntanken de fleste forbinder med enkelhet, men etter å ha lest John Maeda sin The Laws Of Simplicity ble jeg klar over at dette er bare en av veldig mange teknikker som kan brukes til å oppnå enkelhet.

Maeda oppsummerer enkelhet i ti lover som kan brukes i et arbeid med å oppnå enkelhet i løsninger. I det daglige hører jeg stortsett snakk om å oppnå enkelhet gjennom Lov 1: Reduser. Det er selvsagt en viktig teknikk for å oppnå enkelhet, men den er overvurdert særlig i forbindelse med å løse problemer som oppstår under systemutvikling. Dersom det er en problemstilling som ikke er triviell, så er det faktisk slik at det er en del andre lover som faktisk gir bedre resultat enn bare å redusere kompleksitet og å “dumb it down”. Organisering og kunnskap fører veldig ofte til enkelhet i løsningen, på tilsvarende måte som loven om å redusere.

Simplifisering mer enn bare å redusere

Hvis du må lage et rammeverk for å utøve f.eks mapping fra ett objekt til et annet, så kan det gjøres enkelt dersom du sørger for at rammeverket er godt organisert og hvis du sørger for å la de som skal bruke det få økt kunnskap gjennom eksempler og dokumentasjon.  Veldig mange vil si at å lage et rammeverk strider imot det å gjøre noe enkelt, men det blir for enkelt mener jeg. Et godt skrevet rammeverk som er testet og skrevet brukervennlig vil jeg si er essensen i enkelhet. Du gjør en ofte utført operasjon enkel for flere. Hvorvidt det ligger avansert kode i rammeverket er egentlig uinteressant. Ingen stiller spørsmål rundt hvorvidt Spring rammeverket bruker noe avansert for å oppnå det de gjør. Hvorfor skal man i prosjekter måtte gå kanossagang om man ønsker å benytte seg av noe som av enkelte oppfattes som avansert?

Balanse

Enkelhet består ikke i å fokusere på reduksjon eller bare å se på tidsbesparelser. Evnen til å vurdere flere av lovene slik at de balanserer hverandre ut som er nøkkelen til å oppnå enkelhet.

Det viktigste er likevel å innse at for å oppnå enkelhet kreves mer enn reduksjon. Hvis du synes utvikling av web applikasjoner er vanskelig med Java verdens mange rammeverk, så blir det ikke bedre av å redusere alle slike å bare bruke servlet klassene. En slik drastisk reduksjon er ofte fundert på en tanke om enkelhet, trukket altfor langt. Ofte bunner slike på manglende kunnskap eller behov for å bevise noe, som begge er krefter som trekker i retning av “dumbing down”: ikke enkelhet.

Årets utgave av Smidig var langt bedre enn fjorårets. Lyntalene var bedre, spissere og mer variert enn fjorårets. Innholdet i talene var også langt mer givende enn før. Alt dette fine til tross så sitter jeg igjen med en liten følelse av å være litt skuffet. Vi har kommet langt, men det er en ting som jeg synes mangler fullstendig i all iveren etter å være smidig og det er fokuset på forretningen i det hele. Jeg snakker her ikke om forretningssiden, som er veldig mye omtalt i smidige metoder. Nei, jeg snakker om hvorfor smidige metoder er økonomisk bra og er fornuftig business. Statoil-Hydro adopterer ikke Beyond Budgeting fordi de er idealister, nei de gjør det fordi de skal effektivisere sine prosesser.

Utviklere liker gjerne å tro at smidige metoder vinner nytt terreng fordi all ønsker dem godt og at alle setter pris på godt håndverk utført i trygge omgivelser. Jeg mener dette bare er en heldig sideeffekt som de fleste ikke egentlig bryr seg om. Smidige metoder brer om seg fordi det er bra business, ikke fordi alle ønsker en bedre verden. Det var ikke noe fokus på forskuttering, måling av effekt eller andre økonomiske aspekter. Dette er tross alt hovedgrunnen til at stadig fler bruker smidige metoder, nemlig at det er kostnadsbesparende og gir mer verdi igjen for en investering.

Det norske smidig miljøet er veldig god på å fremheve og fokusere på de mykere sidene ved smidige metoder, men vi ignorer i veldig stor grad fundamentet for at smidige metoder lykkes. Nemlig de forretningsmessige aspektene ved metoden og hvordan man  i smidige metoder skaper et samspill med den administrative / økonomiske delen av en organisasjon.

Oppsummering

• Kanban er fett og vi sier alle Fuck Scrum!
• Par-programmering er hva de unge kule driver med
• Statoil-Hydro, smidigere enn hva som møter øyet
• Deler av UX miljøet i Norge mener de er så viktige at de må ha en egen prosess helt alene uten inblanding når de utøver sin magi (uten at noen vel egentlig har sett noe magi fra dette miljøet noen sinne)
• Rock’n roll har sin plass i smidige metoder, det beviste Christian B.Hauknes!

Igjen så må jeg rose arangørene av årets Smidig konferanse, dere leverte virkelig varene i år. Eneste forbedring er at middagen burde vært i et øl telt ute på Youngs-torget!

Se foredraget The Essence of User Interface Programming og legg gjerne inn din kommentar. Takk til JavaZone for å arrangere en bra konferranse og det er alltid morsomt å delta!

• Les detaljene om lånekalkulator oppdraget
• Se lånekalkulatoren

Jeg har tidligere vært med på å forsøke etablere en tjeneste som forsøkte å gjøre musikk tilgjengelig for folk på en ny måte gjennom musikk tjenesten Ezmo. Vi forsøkte hele tiden å spille på lag med platebransjen i et forsøk på å etablere en ny måte å selge musikk på gjennom venners anbefalinger direkte i en musikk spiller. Det triste med platebransjen er at de uansett forslag eller forretningside er hemmet av hvordan musikk distribueres idag. Vi i Ezmo ønsket å være en global musikk tjeneste, hvilket skulle vise seg å være ekstremt vanskelig ettersom platebransjen deles inn i regioner hvor du må kjøpe rettighetene i alle disse. Hvilket betød at vi i Ezmo måtte ha betalt for rettigheter i alle soner dersom vi skulle være en global tjeneste.

Dette problemet er noe som Spotify har fått erfare i det siste, sanger har “forsvunnet” fra Spotify og jeg antar det er fordi de har begynt å få mer oppmerksomhet fra platebransjen og dermed kommet i kontakt med disse tingene. Jeg synes Spotifyer utrolig spennende, men jeg ser desverre ikke noe håp i at den vil overleve. Årsaken er at loven om opphavsrett håndheves på en slik måte at det er mer eller mindre umulig å drive forretning uten å ha absurde ressurser til å betale for rettigheter rundt om i alle mulige soner platebransjen er delt inn i. Nettopp opphavsretten og hvordan den kommer til å måtte endre seg var temaet for dokumentaren Digitale Pirater.

Techno Brega – en avansert russe-konkurranse

Techno Brega er en ekstremt populær musikk genre i Brasil. I techno brega tar artistene en hit låt fra f.eks USA og remikser den til å ha beats som er basert på den tradisjonelle braga musikken. for så å lansere den som sin egen. Disse artistene gir bort CDene gratis og bruker CDer som rene promoteringsartikler. I techno brega er det ulike soundsystems som konkurere om å være de beste (ikke helt ulikt hvordan man i Norge konkurerer om det beste anlegget på russebiler). Festene som soundsystemene arrangerer er stedet hvor man tjener penger. De tjener penger på inngang og alle slike ting, men i tillegg tar de opp DJ setene som artistene spiller for så å selge de på CD idet festen er over. Artistene har funnet en måte å effektivt tjene penger på sin kunst uten å måtte bekymre seg særlig for pirater. Dette konseptet er noe som andre artister har forsøkt kopiere i vesten, men uten særlig hell.

Nigeria-wood

I dokumentaren intervjues representanter for en av verdens største film industrier, nemlig den Nigerianske. Nigeria er ett av verdenes mest folkerike land og det er nigerianere spredt rundt om i alle verdenes hjørner. Den nigerianske film industrien er en av de største produsentene av filmer i verden i dag . Det pussige er at dette skjer uten at det forekommer piratkopiering av filmer i Nigeria. Dette fordi de selger filmene veldig billig og det er produsentene av filmene selv som står for distribusjon og salg. Digitalt film utstyr kan nå kjøpes relativt billig og det kreves ikke mer enn en relativt bra datamaskin til å gjøre redigering. Gjennom at ikke bare den rike delen av verden har tilgang på produksjonsutstyr for film har gjort at en helt ny gener filmer produseres i Nigeria.

Produsentene av filmene selger filmene veldig billig og fra sine egne butikker. Produksjonskostnadene er veldig lave ettersom alt er digitalt. Den største faren for Hollywood er at disse filmmakerne fokuserer på historier som bygger på afrikanske verdier og tradisjoner. Disse filmene snakker direkte til mennesker rundt om i verden som er av afrikansk opprinnelse. Dette har gjort at nigerianske filmprodusenter nå har den afro-amerikanske befolkningen i USA som sin neste målgruppe og det gir grunn til bekymring for Hollywood. Filmer som snakker direkte til afro-amerikanere kan vise seg å være en større trussel mot den etablerte filmindustrien.

Opphavsretten vil endres

Dokumentaren viser en herlig kontrast mellom representanten fra MAAA (Motion Picture Association of Americ) og en av de mest kjente film produsentene i Nigera. Hvor den nigerianske produsenten ikke engang tenker på piratkopiering som noe galt, mens MPAA helst vil ha SWAT teams inn i alle tenåringers soverom dersom de ser ulovlig film. Alle eksemplene i dokumentaren viser hvordan definisjonen av opphavsrett blir nødt til å endre seg på grunn av grunnleggende endringer i produksjonsmidlene. Det er uunngålig at måten vi ser på opphavsrett vil endre seg de nærmeste årene. Utviklingen er ikke til å stoppe, så spørsmålet er hvem vil være med?

Jeg tror på ingen måte at musikk- eller film industrien vil dø. Historien om videokasetten vil gjenta seg og disse bransjene vil komme til å finne måter å overleve på. Det eneste som er sikkert er at måten de tjener penger på vil endre seg og jeg tror også hvordan man definerer opphavsrett

Min tidligere arbeidsgiver Open AdExchange har denne uken gått live med sin løsning for relevante annonser for store medie hus. Uten noe skryt eller bravour har de etablert seg i Danmark som den største spilleren i det danske markedet. Jeg tror disse gutta har evnene og forretnings forståelsen til å kunne lykkes i å faktisk bli en viktig aktør i det digitale annonse markedet.

Gratulere til alle sammen og lykke til i Danmark!

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.

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.

Flere nivå av modenhet

Allistar Cockburn skriver i en av de beste bøkene om smidig systemutvikling, Agile Software Development, om hvordan man i kampsporten Aikido går gjennom tre stadier for å lære nye teknikker: Shu-ha-ri.

Å 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.

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?

Iterativt, inkrementelt og evolusjonært

Reidar Sande snakket på Smidig2008 om hvorvidt Mona Lisa ble malt iterativt, inkrementelt eller evolusjonært og det er her man kommer inn på hvordan de klarte å bygge en baseball stadion på en smidig måte.

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.

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.

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: