Helgen viste meg noen av de beste mulighetene man har til å utnytte open space. Her er et utvalg av sesjoner og hva som gjorde dem bra:

• På min første sesjon “Certified Scrum Dev exercises” ba jeg om ideer og innspill til hvordan å gjennomføre et kurs for folk som vil bli bedre utviklere. Det var bare seks personer som møtte opp og vi hadde en ganske kort diskusjon, før jeg spurte de som var til stede om de hadde lyst til å prøve en praktisk workshop jeg hadde lest om. Så brukte vi 30 minutter der vi programmerte “Elephant Carpaccio”. Jeg hadde lest litt om øvelsen før workshopen og jeg har selv deltatt på øvelsen for et halvt år siden. Ut over det hadde jeg ikke gjort noen forberedelser.
• Jeg deltok på Olaf Lewitz sin open space om “Scoping techniques“. Olaf tegnet opp et sett med teknikker på en flipover: Feature Injection, BDD, User Story Mapping, Effect Maps. Noen i publikum spurte “kan du fortelle litt mer om feature injection,” og så tegnet Olaf opp en skisse som demonstrerte arbeidsflyten. Noen foreslo andre teknikker, for eksempel så forklarte jeg modellen Evo. Olaf skisserte det jeg beskrev på en flipover. Olaf hadde forberedt seg med noen tanker på forhånd om hvilke teknikker han ville ha med seg og hvordan han kunne fremstille disse.
• Karianne gjennomførte en liten open space sesjon med tittelen “Refactoring dojo“. Hun hadde tatt med et kodeeksempel hun hadde brukt før og en PC, og de som møtte opp gjorde forbedringer i koden. Karianne koblet sin PC opp på en projektor og det gikk på omgang hvem som satt ved tastaturet og hvem som observerte og kommenterte det som ble gjort.
• Jeg hørte fra noen som hadde deltatt på Joh og Simon sin open space “Breaking big rocks“. Her hadde facilitatorene forberedt et nøye planlagt opplegg: De beskrev et eksempel på et “stort problem” (“big rock”). Så delte de opp gruppen i grupper på 3 og ba hver gruppe komme opp med noen store problemer på post-its. De hang opp problemene på en flipover. Så ba de gruppene om å velge et problem hver og diskutere hva som gjorde det stort. Når gruppene hadde diskutert, samlet de sammen beskrivelsene og demonstrerte hvordan de problemene folk hadde samlet inn egentlig var veldig like. Jeg fikk inntrykk av at Joh og Simon hadde brukt litt tid på å planlegge sesjonen og bestemme seg for hvilke spørsmål de skulle stille til gruppen.
• Jeg deltok på en annen sesjon med Olaf Lewitz – “Lean procrastination“. I introduksjonen fortalte Olaf at han hadde holdt en keynote med denne tittelen for et par uker siden. Vi hadde en projektor tilgjengelig, så deltagerne spurte om han kunne gå gjennom presentasjonen for oss. Resten av sesjonen ble en uformell presentasjon med slider.
• Jeg foreslo en kvelds-open space med tittelen “how to fix devs“. Jeg introduserte med “vi klager alltid over prosjektledere, kunden, produkteiere, arkitekter osv. Nå vil jeg klage litt over (oss) utviklere”. Vi hadde en liten diskusjon og jeg presenterte noen tanker om hvordan vi burde justere på rammene for utviklere, for eksempel at “i stedet for at utviklere gir estimater for oppgaver, hva om produkteier gir budsjetter for oppgaver”. Jeg hadde tenkt mye på temaet før open space og fikk masse bra feedback på hvilke av disse tankene som virket fornuftig som jeg kan ta med meg videre.
• I en tidsperiode der jeg ikke fant en sesjon som jeg inspirerte meg, gikk jeg rundt og hørte på litt forskjellig. Jeg ble sittende på slutten av en sesjon som het “Definition of Agile Coaching“. I løpet av sesjonen hadde gruppen produsert denne definisjonen: “Agile coaching is a 100% client-focused engagement which enables continuous improvement, because the client owns aligned goals and purpose across organisational levels and the people doing the work define the steps towards those.”
• Jeg holdt en siste open space på søndag, denne om “non-violent communication“. Jeg introduserte med “jeg har lest en bok som ga meg masse tanker jeg synes var spennende, jeg vil gjerne diskutere dette med dere”. Diskusjonen var ustrukturert og springende, men det var mange som deltok og alle følte at de både bidro og fikk utbytte av alle de forskjellige diskusjonene. Jeg noterte meg noen ord på et par flipovers, men notatene var ikke mulige for noen som ikke hadde deltatt å forstå. Diskusjonen skapte mye tanker om hva vil det egentlig si å tvinge noen i en diskusjon. Vi fikk en positiv atmosfære i gruppen som ga en fin avslutning på helgen.

Om jeg skal trekke noen konklusjoner: Man kan komme til en open space med forskjellig grad av forkunnskap og forskjellige forventninger. Du kan stille med med en ferdig presentasjon, en plan med spørsmål, en liste over relevante spørsmål og ideer, eller bare med et tema (som da jeg foreslo “non-violent communication”). Resultatet kan bli at man gjennomfører en øvelse sammen, produserer et resultat, kommer opp med en liste med ideer som folk kan sjekke ut etterpå eller at man bare har en hyggelig samtale.

Vellykkede open spaces kommer i mange størrelser og fasonger. Et av prinsippene bak open space er “whatever happens is the only thing that could have happened”. Eksemplene mine fra Agile Coach Camp demonstrerer dette prinsippet: Man kan komme til en open space med forskjellig grad av forkunnskap og forskjellige forventninger. Når gruppen får en sjanse til å forme innholdet, blir opplevelsen verdifull for alle.

På kick-off i år vil Steria feire “The Power of Sharing” ved å vie den faglige delen til Open Space. Her har alle som deltar anledning til å skape dialog om ting som interesserer dem. På en open space kan du ta opp ting du er flink til som du ønsker å dele, ting du ikke er flink til som du ønsker å lære, måter du ønsker andre endrer seg på eller hva enn som interesserer deg.

Praktisk fungerer det slik at deltagerne foreslår sine temaer ved oppstarten av open space. Du vil få ti sekunder på scenen å fortelle hva du vil diskutere og så får du plassere temaet i programmet som vi henger opp på en stor tavle. Når “din” sesjon starter er du ansvarlig for å ønske velkommen og etter det kan du lytte eller snakke så mye eller lite du ønsker. Du trenger ikke å forberede noe før en open space (men du kan om du vil). Alle diskusjonsgruppene vil ha flipover og noen få vil ha projektor.

Her er eksempler på ideer som andre har tenkt å bidra med på Sterias open space:

• ABC of ICT
• Slik kommer du igang med brukertesting
• Hvordan få til tverrfaglige løsningsteam i smidige prosjekter
• Hvordan få brukertesting inn i alle Sterias systemutviklingsprosjekter
• Hva bør en SharePoint-konsulent være?
• Hvordan bli en bedre leder og hvordan få en bedre leder
• Kommuniksasjonsstil: Er du grønn, gul eller rød
• Bli med og leke med CoffeeScript
• Skal vi bidra til et open source prosjekt?
• Sterias bidrag til FNs tusenårsmål
• The rise and fall of Intranets
• Trender og utvikling i IT-bransjen
• Kan en kontrakt være smidig?

Som deltager på open space er du ansvarlig for ditt eget utbytte. Så det er lurt at mange tenker litt på forhånd om hva de vil diskutere! Så gjør deg selv og dine medmennesker en tjeneste: Bruk ett minutt på å tenke på hva du kunne tenke deg å dele, å lære, å endre sammen med de du jobber med. Skriv gjerne en (uforpliktende) kommentar med et mulig tema.

Reduksjon i informasjonsmengden – bedre kvalitet og oversikt
Et av målene for opprydningen var en reduksjon i informasjonsmengden, slik at det er mulig å få bedre oversikt, både for redaktører og for besøkende på nettsiden. Det ble satt harde krav til hva slags informasjon som skulle kunne publiseres på de nye sidene. Samtidig ble webpublisering gjort mer sentralisert.

En ting som overrasket meg underveis i prosessen var hvor viktig de ulike avdelingene synes det var å få med mest mulig stoff om seg selv på de nye sidene. Underredaktørene la ned et betraktelig antall timer på telefon og e-post for å overbevise ansatte og beslutningstakere i organisasjonen om at all denne informasjonen ikke var like interessant for publikum. Kommunikasjonsjobben var minst like viktig som innholdsproduksjonsjobben.

Innholdsproduksjon tar tid
Innholdsproduksjon tar som regel lenger tid enn man tror. I følge innholdsstrategiguruen, Kristina Halvorssen er dette en svært hyppig årsak til at prosjekter blir forsinket. Arbeidet med innholdsproduksjon for Forsvaret.no var av avhengig av fagpersoner “ute i bruket”. Å samle inn webtekster, som skal være bedre enn de gamle, men mye kortere, er svært tidkrevende. Mange av tekstene ble derfor skrevet av redaksjonen og det ble flere runder med korrektur, sletting, godkjenning og omkalfatring før innholdet var klart til publisering.

Tusener av klikk spart
Utviklerkollegerne mine i Steria laget et smart script som gjorde at informasjonsstrukturen, som var laget i MindManager, ble importert i SharePoint og at sidene med tilhørende maler ble opprettet automatisk. Dette sparte webredaktørene utallige museklikk. Det var likevel ikke til å komme fra at publisering i SharePoint hadde sine utfordringer, spesielt i starten. Du kan lese mer om strukturgenerering i  presentasjonen SharePoint 2010 for Internet – Issues and solutions through a case study (Slideshare)  fra Norwegian Developer Conference tidligere i år.

Excel-oversikt og innholdsdugnad
En innholdsoversikt i Excel ble laget for de nye sidene. Kvalitet og eier av hvert innholdelement ble lagt inn. Dette var et godt oppfølgingverktøy for innholdsproduksjon i innspurten. Innhold ble skrevet på dugnad og det var mange bidragsytere.  

Forsvaret.no  var et kundedrevet prosjekt. Som konsulenter kunne vi dra videre til andre kunder da prosjektperioden var overstått. Forsvarets  webredaktør uttalte ved lansering at “det er nå arbeidet begynner”. Du, som er opptatt av webting, har kanskje oppdaget at Forsvaret.no har en helt tradisjonell venstremeny. Det er flere grunner til det, men det er en annen historie.

Eli Toftøy-Andersen er medforfatter av boken Praktisk brukertesting og  blogger til vanlig på brukskvalitet.no. Høsten 2011 holder hun workshop sammen med kollega Jon Gunnar Wold på  brukervennlighetskonferansen Yggdrasil 17-18 oktober og foredrag på Meetup for interaksjonsdesignere, IxdA 12. oktober.

Bloggposter fra brukskvalitet.no:
10 gode grunner til å gi avslag på publiseringsønsker 
 5 tips for brukertesting av innhold
Brukervennlighet – et folkekrav  

Andre relevante lenker:
SharePoint 2010 for Internet – Issues and solutions through a case study:
http://www.slideshare.net/jmkristiansen/ndc-presentationfinal

Innboksen som arbeidslivets kjellerbod:
http://sterkblanding.no/blog/2011/09/28/innboksen-som-arbeidslivets-kjellerbod/

For de som ikke hadde mulighet til å bli med denne gang såg vi følgende videoer:

• Elizabeth Gilbert on nurturing creativity
• Matt Ridley: When ideas have sex
• Sir Ken Robinson says school kills creativity
• Cameron Herold: Let’s raise kids to be entrepreneurs
• Adora Svitak: What adults can learn from kids
• Mick Ebeling: The invention that unlocked a locked-in artist

Takk til alle som ble med for nok en hyggelig aften med #TEDatSteria!

Men de ferske øynene kan føre til problemer…

Verdien av ferske øyne

Det er lett å se seg blind på egen kode. Når man skriver den har man det veldig klart for seg hva det er en prøver å utrette. Man tar sin egen forståelse av problemet for gitt og leser koden utifra denne egne forståelsen. Men ikke alle ser problemet i samme lys som en selv. Resultatet er ofte totalt uforståelig kode for andre.  Derfor er det kjempeviktig at andre også leser koden og flagger eventuelle uklarheter jevnlig. Det er tross alt vanskelig for en selv å vite hva det er en har tatt for gitt, ettersom man… har tatt det for gitt.

Faren ved ferske øyne

Det er likevel ET problem med ferske kritiske øyne. Spesielt hvis de får jobbe med koden helt uten tilgang til de opprinnelige forfatterne. På seg selv kjenner en andre, og jeg vet med meg selv at jeg fort tenker “Å herregud, hva er det her for noe dritt?!?!!” når jeg ser på andre folk sin kode. Spesielt hvis de ikke er der for å forsvare seg. “Dette kunne jeg gjort 1000 ganger bedre selv”. “Hvorfor har de gjort det SÅNN, når det er så utrolig mye bedre å gjøre det sånn.” Også setter man igang og skriver det hele selv fra scratch. Man bare MÅ! Det klør i fingrene. Dette fører da typisk til at de opprinnelige forfatterne reagerer med tilsvarende avsky mot min “forbedring”. Etter 10 år som programmerer har jeg sett andre gjøre dette mot hverandre gang på gang, jeg har gjort det selv altfor ofte og jeg har fått min egen kode skjelt ut og omskrevet (av meg selv til og med) Denne prosessen kan fort kaste bort mye tid og skape et dårlig arbeidsmiljø der ingen stoler på hverandre og man nesten ikke får lyst til å sjekke inn kode fordi man vet at folk kommer til å slenge dritt. I åpent landskap der man hører høyt og tydelig hvordan folk beklager seg over dårlig kode blir dette enda verre.  Selv om det ikke er ens egen kode det blir klaget over.  Det at folk akker og ojer seg over ting de ikke liker skaper en negativ atmosfære.  Jeg har selv lidd i slike miljøer. Og det plager meg at jeg sikkert har vært skyld i tilsvarende situasjoner på arbeidsplassen. Det er ikke konstruktivt. Jeg akter å forbedre meg og håper andre følger etter.

Pust, tell til 10 og involver de som skrev koden.

Det er som sagt viktig å få flagget kode som bør forbedres. Praktisk talt all kode kan forbedres. Kode som ikke er tydelig nok, kode som er for komplisert, kode som ikke er bra koblet sammen. Men det kan gjøres på bedre måter enn å himle med øynene, stønne, banne og sverte høylytt og så skrive om alt på nytt uten å involvere forfatterne. Jo lengre du sitter og “fikser” andres kode, jo mer irritert blir du på dem, og jo mindre vil du stole på deres evner i fremtiden.  Dette er ikke bra for team-spirit’en.  Snakk heller med personen som skrev koden og spør hva bakgrunnen for løsningen de har valgt er. Vær åpen for at du kan få et veldig godt svar. Kanskje løsningen er full omskrivning, og kanskje koden fortjener en høylytt OMG WTF, men løsningen kan også bare være bedre navngivning av metoder eller andre enkle refaktorerings-tiltak, eller kanskje du har totalt misforstått, og koden er så god den kan være.  Kanskje forfatterene er helt enig i at koden bør skrives om og kanskje de har gode ideer til hvordan dette kan gjøres.  Hvis vi jobber og snakker sammen, også der vi er uenige, får vi et mye bedre samarbeid og et mye bedre arbeidsmiljø.

En code kata er en enkel øvelse for å skjerpe programmeringsferdighetene dine. Det vil si – du trener bare problemløsning den første gangen du utfører øvelsen. Så gjentar du øvelsen, om og om igjen, til det sitter i fingerspissene. Og hver gang prøver du å gjøre det litt kjappere. Hensikten er å trene hastighet, teknikk og verktøy.

I klippet under lager jeg en variant av Minesweeper kataen i JavaScript.

(Kjør den i fullscreen for å se koden mer tydelig)

Merk: Jeg bruker testdrevet utvikling gjennom det meste av prosessen. På slutten dropper jeg TDD når jeg gjør det visuelle og selve spillmekanikken. Dette kunne også testes fra kode, men jeg droppet det for å gjøre den mer artig å se på.

Du kan se på koden i github-kontoen min. Hver commit er en separat gjennomkjøring av øvelsen fra scratch.

Jeg brukte følgende libraries og verktøy:

• Underscore.js
• jQuery
• Grid.js
• clAutotest
• TextMate

Dag to begynner de på badet,  men mye tid går bort fordi en nybegynner klarte å bruke dobbelt så mange spiker som man trenger da han satte opp nye veggplater. Som proffesjonelle arbeidere kunne de ikke stå for slikt, så de rev ned alle platene og satte opp nye med “riktig” antall spiker.  Er du som kunde fornøyd med slik bruk av tid og ressurser?

Når de endelig nærmer seg slutten, får den ene arbeideren en dødskul ny flis-kutter. Den kutter fliser mye bedre og mer nøyaktig enn den de brukte da de satte opp flisene, så da tar de ned igjen alle flisene og setter opp nye.  Er du fornøyd?

Jeg bare spør, jeg. Rent hypotetisk, selvsagt.  For det er vel ingen som kjenner seg igjen i denne typen praksis?

Denne samlingen satte vi et samlet tema for foredragene. Det som går igjen i alle videoene er kunnskap. De drøfter både hvordan få tak i informasjon, men like mye hvordan bruke den. Sistnevnte omhandler i stor grad også hvordan visualisere den og hvorfor det er et kraftig virkemiddel.

Fredag 4. februar viste vi følgende videoer:

• David McCandless: The beauty of data visualization
  Som åpning viste vi et foredrag av David McCandless, en journalist med sansen for statistikk som har fått øye på illustrasjon. Foredraget viser hvor fint informasjon kan illustreres og ikke minst hvor nyttig det kan være.
• Nicholas Christakis: How social networks predict epidemics
  I dette foredraget bruker Nicholas Christakis visualisering av sosiale nettverk til å predikere epidemier. Dette kan brukes til både se sykdom som sprer seg, lansering av et nytt produkt i markedet og mye mer.
• Tim Berners-Lee: The year open data went worldwide
  Tim Berners-Lee utviklet World Wide Web som et deltidsprosjekt for omtrent 20 år siden. Den tid skjønte ikke folk hva en skulle bruke det til. Nå etterspør han rådata om alt. Hva skal vi med det? Han viser veldig klare eksempler om hvordan bruke kombinert rådata.
• Hans Rosling: Let my dataset change your mindset
  Innen visualisering av informasjon er Hans Rosling et kjent navn. Hans entusiasme på senen ilag med  funnene han gjør og historien han forteller gjør alle hans foredrag verd minuttene og mer til. Rosling skal blant annet holde et foredrag under ISFIT i Trondheim 13. februar.
• Malcolm Gladwell on spaghetti sauce
  Verden gikk lenge uten å tilfredsstille sitt spagettisaus-ønske, uten at noen visste om det. Ved å stille de rette spørsmålene, og innse at for noen spørsmål finnes det ikke ét rett svar, fikk verden spagettisausen de faktisk likte best.

Var temaet interessant og ble samlingen bedre når vi holdt oss til et tema? Vi tar gjerne imot tips til både tema og videoer for neste samling!

Et godt foredrag starter med at du snakker om noe du kan. Og du kan mer enn du tror. Det er som regel sånn at de tingene du kan selv, føles som selvfølgeligheter. Men de erfaringene du har og de opplevelsene du har, de er unike for deg. Kanskje det er mange som har interessert seg for de sammen tingene som du har, men det er lite sannsynlig at de har samme perspektiv på tingene. Du bringer noe unikt til bordet. Velg et tema du har erfaring med, og du har tatt første skrittet til et fascinerende foredrag.

Når du skal bestemme deg for nøyaktig hva du vil snakke om, hjelper det å tenke på hvordan du vil påvirke ditt publikum. Publikumet ditt kan noe når de kommer til foredraget ditt. Ta utgangspunkt i at de vil noe med det de kan. Hvilket problem eller behov har de når de kommer inn i salen? Et vellykket foredrag kanaliserer denne viljen til handling: Hva vil du at de skal gjøre når de har hørt foredraget ditt? Skriv ned den (for deg) perfekte tilhørers kunnskap, vilje og handling etter at han eller hun har hørt foredraget. Dersom du kan beskrive en transformasjon som engasjerer deg, har du tatt skritt nummer to til et fascinerende foredrag.

For å oppnå noe, kreves arbeid. Når du holder et foredrag er det viktigste arbeidet du gjør å trene på å snakke. Bruk under 30 minutter på å strukturere tankene dine før du prøver å holde foredraget første gangen. Hold det for deg selv, men snakk høyt. Tren mange ganger. Tren foran andre om du kan. Tren minst tre ganger på foredraget før du lager en eneste slide. Tren mange ganger på foredraget ditt, og du vil komme i mål med et fascinerende foredrag.

Dersom du får med deg hodet (kunnskapen), hjertet (viljen) og kroppen (treningen), så er du garantert å holde et bra foredrag.

Øvelsene kan tjene som inspirasjon til dine egne retrospektiver og workshops.

Jeg brukte tre workshop-øvelser under hele workshopen:

• “Tenke og svare”: Et retrospektiv kan være en sjelden anledning til å bare sitte og tenke uavbrutt. I “tenke og svare” øvelser får deltagerne to minutter i stillhet til å tenke på svaret til et personlig spørsmål. Etter to minutter får alle fortelle svaret sitt, mens resten av gruppen og moderatoren lytter.
• “Tre svar på tre spørsmål i grupper på tre”: Deltagerne blir delt i grupper på tre som alle skal finne tre svar på hver av tre spørsmål. Etter ti minutter avgir gruppene ett svar hver. Dersom spørsmålene krever handling, kan deltagerne i plenum stemme fram hvilke svar de ønsker å handle på grunnlag av
• “Snakker og lytte”: Det er overraskende sjelden vi blir lyttet uavbrutt i ett minutt, eller lytter oppmerksomt til en annen i et minutt. I “snakke og lytte” øvelsen får deltagerne et personlig viktig spørsmål og blir delt i grupper på to og to. I hver gruppe skal én person snakke og den andre lytte i ett minutt. Etter ett minutt bytter parene roller.

På Smidig 2010 kjørte jeg workshopen som et retrospektiv av den første dagen på konferansen. Øvelsens form var delvis inspirert av “Agile Retrospektives” av Diana Larsen og Esther Derby. “Agile Retrospekives” anbefaler en fem-stegs prosess som ledet hovedstrukturen for workshopen:

1. Set the stage: “Tenke og svare” øvelse med på spørsmålet “Hva har vært høydepunkter så langt”
2. Gather data: “3×3 spørsmål” øvelsen der to av spørsmålene var for å samle data. (“hva har overrasket meg” og “hva har jeg lært”)
3. Generate insights: “Lytte og snakke” øvelsen med spørsmålet “hva vil gjøre meg lykkeligere”. Av praktiske grunner gjorde jeg den etter det siste spørsmålet fra “3×3 spørsmål”.
4. Decide what to do: Det tredje spørsmålet fra “3×3 spørsmål” var “hva vil du lære mer om”. Etter at ti grupper hadde kommet opp med ett svar hver, stemte vi i plenum på de mest interessante temaene.
5. Close the retrospektive: Å tenke og svare på spørsmålet “hva håper du å oppleve” var øvelsen som avsluttet retrospektivet.

For å få en mest mulig konstruktiv dialog, forsøkte jeg å strukturere spørsmålene etter inspirasjon fra “Appreciative Inquiry”. Ola Ellnestams blogpost om Appreciative Inquiry Retrospectives var en viktig kilde til inspirasjon.

Hvilke spørsmål kan du tenkte deg å stille til “tenke og svare”, “3×3 spørsmål” og “snakke og lytte” øvelser? Hvilke spørsmål kan hjelpe gruppen å generer innsikter, samles om et mål og gå ut av retrospektivet fulle av ideer og håp for fremtiden?

Jeg har vært så heldig å være på et prosjekt med en produkteier som har sørget for at vår innsats har blitt brukt til å effektivt skape verdi for brukerne av systemet. Jeg vil trekke fram mine observasjoner om hvordan produkteieren på dette prosjektet brukte produktkøen, hvordan han skapte dialog med brukerne og hvordan han kommuniserte effektivt med utviklerne.

Produktkøen

Produktkøen er produkteiers fremste verktøy for å styre prosjektet dit han ønsker. Det viktigste med produktkøen er derfor at den er representert i et verktøy produkteieren er komfortabel med å bruke. Vår produkteier brukte Excel, noe som fungerte godt for dette prosjektet. Hver brukerhistorie var en rad i et regneark. Når vi skulle endre prioritet, kunne vi dra og slippe en brukerhistorie til riktig sted. (Dette er et lurt knep å lære i Excel).

Etter hver iterasjon gikk jeg som Scrum master og produkteieren gjennom alt som var levert i iterasjonen. Vi markerte i produktkøen hva som var levert og hva som ikke var levert. I iterasjon 4, 5 og 6 skjedde noe merkelig. Iterasjon 4 hadde vi planlagt 7 brukerhistorie-poeng, men leverte 4. I iterasjon 5 hadde vi planlagt 7 og leverte 7. I iterasjon 6 hadde vi planlagt 7 og leverte 10. Det som skjedde var et en stor brukerhistorie var nesten ferdig på slutten av iterasjon 4. En ny stor brukerhistorie var nesten ferdig på slutten av iterasjon 5, og denne brukerhistorien fikk vi endelig levert i iterasjon 6. Produkteier insisterte på at en brukerhistorie var enten ikke ferdig (0%) eller helt ferdig (100%). Dette gjorde at det aldri var noen skjønnsvurdering om hva vi hadde levert.

I prosjektet vårt skulle vi erstatte et eksisterende system. Produkteieren var veldig bevisst på å prioritere et sammenhengende sett med brukerhistorier som gjorde at brukerne kunne benytte de leveransene vi ble ferdig med i løpet av prosjektet. Det var to viktige vurderinger som produkteier tok: For det første må brukerne kunne utføre en arbeidsoppgave i den nye systemet, og ikke måtte hoppe mellom det nye og det gamle. For det andre må leveransene inneholde funksjonalitet som er interessant for brukerne.

Personer og samspill

Men produktkøen er den minst viktige delen av produkteiers jobb. Det smidige manifestet sier det selv: “Vi verdsetter personer og samspill over prosesser og verktøy.” Det er to viktige grupper som produkteieren må forholde seg til: Brukerne og utviklerne.

Involvere brukere

Før prosjektet startet, hadde produkteieren involvert brukerne i prosjektet. Mange brukere var blitt spurt om hva de mente var viktig med det nye systemet og noen brukere var valgt ut til en fokusgruppe. De to mest involverte brukerne deltok hele veien i prosjektet. Produkteieren identifiserte to brukere som de andre brukerne respekterte faglig, som forsto dagens system godt, som hadde meninger om hvordan ting burde være, og som ikke var redd for å si disse meningene.

Så snart vi hadde et produkt som kunne vises fram, satt vi dette i drift i demoversjon som brukerne kunne teste ut. Det viste seg å være vanskelig å få brukerne til å prioritere å teste det nye systemet. Det hjalp litt når produkteieren ga dem en oppgave de skulle utføre med det nye systemet (hjemmelekse). Det hjalp veldig når brukerne kunne bruke det nye systemet mot produksjonsdata som en del av jobbe sin.

Ekspertbrukerne deltok på alle demoer. Ettersom en av de bodde i Rogaland og en i Hedmark, var det vanskelig for dem å reise til Oslo for hver eneste to-ukers iterasjon. De første iterasjonene var de alltid til stede, men etter dette kjørte vi kun demo annen hver iterasjon. Etter et halvt år i prosjektet forsøkte vi også å kjøre noen demoer med screen sharing (go-to-meeting, tror jeg) og telefonkonferanse. Det fungerte ok, men vi fikk mye nyttigere feedback når vi møttes ansikt til ansikt. Ekspertbrukerne hjalp oss å bli flinkere og validerte arbeidet vårt når et var bra.

Kommuniserer med programmere

For å ha framdrift, var prosjektet avhengig av at produkteier og utviklere møtes hver dag. Produkteier deltok på standup-møtene hver morgen. Etter standup-møtene hadde han satt av opp til en time der en utvikler kan vise fram ny funksjonalitet og få tilbakemeldinger, der produkteier kan gi tilbakemeldinger til en utvikler på funksjonalitet han testet i går og der produkteier kan forklare detaljene rundt nye brukerhistorier.

Når produkteieren forklarte brukerhistorier, var han flink til å være konkret. Dette er alfa og omega når en produkteier snakker med utviklere. Forskjellen på å vise fram en skjermbildeskisse og å forsøke å beskrive et abstrakt behov er gigantisk. Forskjellen på å fortelle et eksempel og å forklare en abstrakt arbeidsprosess er enorm. Ved å bruke eksempler til å forklare brukerhistorier var produkteiers forklaringer gode for utviklerne.

Til slutt var produkteieren vår rask til å bestemme seg. Dersom det var et uklart valg, fikk vi ofte en avgjørelse der og da. Når produkteier måtte sjekke med andre, tok det en eller to dager før han kunne gi oss en beslutning. Noen ganger fant han senere ut at han måtte ombestemme seg. Da utførte vi ganske enkelt den endelig løsningen i en senere iterasjon. Det er mye mer effektivt å utvikle noe som er en rimelig hypotese, få tilbakemelding og så utvikle det riktige, enn det er å vente på en beslutning.

For å lykkes som produkteier, må du kunne bruke produktkøen effektivt, du må involvere brukerne dine gjennom hele prosjektet og du må kommunisere med utviklerne hver dag. Da vil du ha et vellykket Scrum-prosjekt!

Systemutviklere er både heldige og uheldige. Vi kan tilegne oss kunnskap og ferdigheter helt på eget initiativ, men vi tvinges også til å gjøre det for å holde oss relevante, ettersom teknologi endrer seg raskt.

Selv synes jeg at det er topp å plukke opp nye ting – her er noen metoder for å lære…

Bredde eller dybde?

Tenk på kunnskap som personøkonomi. Ikke invester alt i en aksje (“Jeg kan bare Java!”). Spre eggene dine over flere kurver. For all del: legg ned tid i mainstream-teknologi som er populær idag. C# og Java f.eks er lavrisiko med grei avkastning. Men se også på nisje-teknologi (la oss si F# eller Scala, for eksempel) Disse er mer høyrisiko fordi det absolutt ikke er sikkert de blir populære i fremtiden. Smale temaer gir til gjengjeld langt høyere avkastning hvis de slår an: du får et fortrinn fordi du var tidlig ute.

Balanse mellom generelle og spesialiserte emner. Brede, eviggrønne felt (f.eks OO-design, regular expressions, statistikk) hjelper deg i mange år, uavhengig av domener og platformer. Men ikke overse domenekunnskap og platformspesifikke verktøy (Oracle og Microsoft) som gjør deg mer ettertraktet i prosjekter her og nå.

Kultiver personlige styrker. Hvis du bare kan “litt om alt” så er det vanskelig å utmerke seg. Finn en eller to ting som er dine hovedpillarer, som du stadig forbedrer og behersker bedre enn andre. Hva gjør at du skiller deg ut? Hva er ditt “Unique Selling Point”?

Studieteknikk-kungfu

Du har et enormt arsenal av studieteknikker. Min erfaring: jeg lærer meg ting langt mer effektivt nå enn da jeg var i skoleverket eller på universitetet. Dels fordi jeg har blitt flinkere til å lære, men mest fordi vi har fått flere måter å tilegne oss kunnskap. Her er en liten godtepose av muligheter:

• Universiteter verden over legger ut åpen “courseware”: videoforelesninger, notater, pensum, oppgaver, fritt tilgjengelig på nett.
• Screencasts er en fin blanding av foredrag og praktiske demonstrasjoner. Noen av dem må du betale for. De er derfor ofte optimalisert for å levere lærdom og verdi, mer enn en umotivert foreleser på Blindern noengang blir…
• “So You’d Like To…”-guidene hos Amazon.com er i noen tilfeller knallbra utvalg av faglitteratur og fungerer bra som utgangspunkt for selvstudium.
• Online nyhetsblogger og foredrag fra konferanser gjør deg oppdatert på tilstanden i fagfeltet ditt.
• Podcasts og lydbøker gjør iPoden din til en forelesningssal – kanskje mens du tar oppvasken?
• Møt andre engasjerte i meetups, brukergrupper, code camps og online studiegrupper. Få feedback fra likesinnede, ikke gjem deg bort!
• Open source lar deg kikke bak kulissene og se hvordan andre utviklere jobber og tenker.
• Mindmapping er en sterk måte å ta gode, raske notater mens du studerer.

Og dette var bare en tilfeldig utvalg. Med andre ord: dersom du begrenser deg til å kun lese en papirbok i ny og ne så handicapper du deg selv. Du har mange muligheter!

Absorber som en svamp. Hvis jeg har en ekstrem “læredag” så hører jeg på en podcast når jeg går til stasjonen på morran, leser litt i en relatert bok mens jeg sitter på toget, plugger inn iPoden igjen når jeg bytter over til tbanen til jobben, samme opplegg på veien hjem på ettermiddagen, og setter meg ned og koder en prototyp etter at ungene har lagt seg. Teknikkene nevnt i forrige avsnitt gjør det stadig enklere å presse inn læring flere steder i hverdagen enn man kunne før.

Jevn progresjon. Store skippertak kan fungere, men det er i lengden bedre å lære litt hver dag istedet. Når man er student så fungerer sånne “overdoser” til en viss grad, men det blir vanskeligere når du har jobb og familie. Tenk bærekraftig tempo…

Bruk det du lærer

Jobb med relevante prosjekter i arbeidstida. Dette er idealsituasjonen, men lar seg ikke alltid gjøre. Prosjekter krever vanligvis at vi leverer det vi allerede behersker, ikke det vi ønsker å lære mer om. Derfor kan det bli nødvendig å…

Lage ting på fritida. Bruk det du har lært til å gjøre sideprosjekter på egenhånd. Ambisjon og omfang trenger ikke være all verden, bare du lager noe konkret og nyttig. Du kan lage et verktøy eller en tjeneste som bare du selv trenger, eller slippe det som open source eller en kommersiell tjeneste for hele verden. Poenget er at du anvender kunnskapen til noe konstruktivt. Det kan være slitsomt å bruke fritida til dette – til gjengjeld eier du selv det du lager. Og du får en “portfolio” å vise til.

Lær det bort til andre! Når du formidler til andre (f.eks via kurs, blogging, foredrag) så tvinges du selv til å få bedre grep på stoffet ditt. Du trenger ikke være guru for å lære bort ting – det holder at du har noenlunde grep om temaet og evner å formidle det godt.

Robert “Uncle Bob” Martin sa på et av foredragene sine at en profesjonell utvikler må bruke tjue timer hver uke på å forbedre seg som håndtverker. Dette er kanskje ekstremt – men hvor mye gjør du selv? Og hvordan lærer du nye ting? Del gjerne av egen erfaring i kommentarene under!

Bedre kommunikasjon

• Inkluder produkteier på morgenmøtene: Daglig kommunikasjon mellom kunde og leverandør har en dokumentert enorm effekt på hvor vellykket et prosjekt blir. Teamets fokus blir mye bedre dersom det er noen på de daglige standup møtene som er interessert i å prøve ut det som har blitt laget i går, som er interessert i å komme med innspill på det som lages i dag og som har myndighet til svare på avklaringer angående dagens oppgaver.
• Programmér sammen: Utviklere på prosjekter innehar enorm kunnskap, både om de delene av systemet man lager og om programmering generelt. Når man programmerer i par og roterer hvem som jobber sammen hyppig, blir denne kunnskapen spredt til alle. Spe også gjerne på med seanser der hele teamet går gjennom deler av koden på storskjerm.
• Bruk en Scrum-tavle: For å hjelpe alle å huske på hva som er målet med sprinten, er det lurt om teamet holder standup møtene rundt en tavle med lapper for alle aktiviteter teamet har planlagt i iterasjonen. Lappene henger i kolonner “venter”, “under arbeid” og “ferdig”. Hver lapp bør ha et så lite omfang at teamet flytter flere lapper til “ferdig” hver dag.

Bedre kvalitet

• Verifiser krav med funksjonelle tester: Når teamet skal jobbe med en oppgave i en iterasjon, er det viktig at alle har konkret forståelse av oppgaven. Produkteier bør beskrive eksempler for å gjøre oppgavene konkrete. Om mulig, bør produkteier uttrykke eksemplene i et verktøy for automatisert funksjonell testing (for eksempel FitNesse eller Cucumber). Teamet kan da kjøre testene og automatisk sjekke at de oppfyller produkteiers forventning
• Skriv enhetstester før koden den tester: For å kunne utvikle funksjonalitet inkrementelt, må man kunne endre på kode som allerede har vært ferdigstilt, samtidig som man er (rimelig) sikker på at endringen ikke ødelegger noe som har virket før. De funksjonelle testene kan gi et sikkerhetsnett, men det tar typisk lang tid å kjøre dem og de gir ofte ikke en eksakt indikasjon av hva som er feil når noe ikke virker. Derfor bør teamet skrive raske tester som verifiser at klassene i systemet fungerer, gjerne før man skriver koden.
• Integrer endringer kontinuerlig og automatisk: Automatiske tester er kun verdifulle dersom de kjøres! Sett derfor opp en Continuous Integration server som sjekker ut og tester alle endringer hver gang en utvikler har sjekket inn en endring til kildekodekontroll. Om mulig bør dette systemet også automatisk installere den siste versjonen av programvaren til et egnet testmiljø, slik at produkteier alltid kan se hva som er siste versjon av systemet.

Bedre forretningsfokus

• Inkluder alle oppgaver i en prioritert produktkø: Mange team lurer på hvilke oppgaver som skal puttes på produktkøen. Dersom noe gir forretningsverdi og tar betydelig tid å utføre, bør produkteier inkludere oppgaven på produktkøen. Ikke-funksjonelle krav må som regel testes. Det tar tid å sette opp testene og rette opp eventuelle mangler. Ikke-funksjonelle krav skal på produktkøen. Brukerdokumentasjon må skrives og kvalitetsikres. Det tar tid å skrive god brukerdokumentasjon. Brukerdokumentasjon skal på produktkøen.
• Bli helt ferdig med funksjonalitet: Teamet får kun “poeng” for helt dønn ferdig utført arbeid. Etter en iterasjon bør alt som tilhører en oppgave være så ferdig at det er greit dersom man aldri mer bruker tid på koden. Koden, tester og dokumentasjon må være i en akseptabel tilstand. Det betyr ikke at koden er frosset. Dersom man for eksempel utfører en oppgave for å verifisere responstid, må teamet oppdatere eksisterende kode slik at den støtter tidsmålinger og at man korrigerer eventuelle ytelsesproblemer man oppdager. Dette arbeidet tilhører det å implementere responstidskravet – den originale funksjonen er ferdig.
• Ta med brukere på demo: Dersom du lager et system som interesserer dine (fremtidige) brukere, bør teamet ha noe spennende å vise dem på demo etter hver iterasjon. Bruk demo-møtet til å involvere brukerne. Sørg for at input fra brukerne blir tatt hensyn til, og at de får beskjed om innspill som har blitt implementert, slik at de fortsetter å interessere seg.

Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon. Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretningsverdi. Dét er hvordan du lykkes med smidige prosjekter.

Jeg planlegger å publisere en Steria 3-minuttersguide basert på denne artikkelen. Innspill til forbedringer mottas med stor takk!

Hvordan havner man i slike situasjoner? Kan de unngås?

Er det arkitekten sin skyld?

Det er lett å skylde på arkitekten og kalle ham (eller henne) for en idiot og et stabeist, men er dette rettferdig? Både ja og nei. Stabeist er kanskje korrekt, men idiot er vedkomne neppe. Intelligens er evnen til å finne gode generiske modeller som kan brukes til å finne løsninger i en kaotisk hverdag. Idioter pugger tallene i boka og ser ikke sammenhenger. Intelligente mennesker lærer seg reglene for å regne seg frem til alle mulige tall – ikke bare de i boka. En god og intelligent arkitekt er en som kan finne enkle overordnede strategier som gjør applikasjonen som helhet ryddig og pen. Fra et kaos av brukerhistorier og kundekrav skal han eller hun finne enkle og elegante strategier som kan brukes til å løse alt. Hvis alle programmerere kunne gjøre akkurat som de ville for hver brukerhistorie, hadde koden endt opp i kaos. Alle hadde funnet opp sine egne hjul, og noen av dem hadde nok vært ganske kantete og skjeve. I vedlikeholdbarhetens navn om ikke annet er det klart at arkitekten ønsker seg felles løsninger og forutsigbare implementasjoner. Men finnes det alltid én løsning som passer overalt? «Gjør alt så enkelt som mulig, men ikke enklere» sa Einstein. IQ-tester måler evnen til å finne enklere løsninger, men de måler ikke nødvendigvis evnen til å se når nok er nok.

Maks antall personer = 150

Når utviklernes hoved-utfordring er å få løsningen til å passe inn i arkitekturen er det klart at noe har gått galt. Min teori er at disse situasjonene er et tegn på at prosjektet har blitt for stort. Akkurat som at store firmaer gjerne er mye tregere enn mindre firmaer, blir store prosjekter tregere enn små. Tregere både når det gjelder utførelse av eksisterende oppgaver, og enda mer når det gjelder innføring av nye prosesser. Antropologen Robin Dunbar har oppdaget at 150 mennesker det meste folk klarer å holde styr på. Det militære og flere firmaer har tatt dette med i betraktning og passer på at organisasjons-enheter aldri inneholder mer enn 150 mennesker. Selv om man ikke kjenner alle, så vet man hvem de er og hvor de jobber. Hvis man trenger noe gjort, kan man bare gå bort til den man vet man bør snakke med, og få det gjort der og da. Når organisasjonen vokser over 150 mennesker vet man ikke lenger hvem det er man må kontakte for å løse problemene sine. Man må da henvende seg til sjefen sin, eller en helpdesk på andre siden av kloden eller noe slikt, og håpe på at de igjen klarer å finne frem til den som kan hjelpe. Jo større og bedre organisert bedriften er, jo mindre effektiv blir kommunikasjonen. Når IT-support sitter i Jakarta, lønningskontoret er i Stavanger og markedsføringen foregår i Dubai, så blir det dårligere kommunikasjon enn om alle var i samme bygg. Mange mener at slik må det bare være når firmaet vokser, for man kan da ikke ha lønnskontor, IT-support og markedsføring i hvert eneste kontor når man har hundrevis av kontorer verden over. Jeg er ikke enig. I smidige prosjekter utvikler man ikke database-koden, business-logikken og GUI-koden hver for seg. Man utvikler brukerhistorier hver for seg. GUI, business-logikk og database-greier samtidig. Jeg tror noen store firmaer kunne lære mye her. Istedenfor å samle alle IT-avdelinger under ett tak, tror jeg det lønner seg å heller samle alle som har med samme produkt under ett tak. Design, produksjon, markedsføring, IT-support og alt som hører med til et produkt. Hver business-enhet bør være istand til å tjene penger. Slik organisering koster kanskje mer, men den vil også produsere og tjene mer.

Maks antall klasser i et prosjekt = ?

Mye av det samme skjer i store software-prosjekter. Når prosjektet vokser og vokser ender man fort med å gruppere koden etter «software tier» og ikke etter bruksområde. Man lager regler som at «slik snakker vi med databasen» og «slik skriver vi rapporter». Og reglene gjelder for alle uansett. Jeg tror man med fordel heller burde dele prosjektet inn i separate produkter. Produktene vil bestå av en samling av brukerhistoriene som passer sammen på et vis. Disse produktene trenger ikke ha samme regler for bruk av database eller noe som helst. Arkitekten og utviklerne står fritt til å finne løsninger som passer best for akkurat dette produktet. Jeg tror ikke denne typen tankegang kommer naturlig for folk med høy IQ. IQ driver folk til å se mønster og finne fellestrekk og dermed gruppere alt som likner. Her var det oppkobling mot database, der var det oppkobling mot database – da slår vi dem sammen! Her var det et lønnskontor, der var det et lønnskontor – da slår vi dem sammen! Det føles godt og opp til et visst nivå er det selvsagt det rette å gjøre. Men et sted går grensen. Hvor da? Når bør man begynne å tenke på splitting? I business-verden er 150 et tall å huske på. Har vi tilsvarende tall for software-utvikling? Hvor mange klasser kan et prosjekt ha? Er det antall klasser vi burde telle? Siden det er så fristende å finne fellestrekk og lage felles løsninger, tror jeg det hadde vært greit å ha noen konkrete tall og grenser å forholde seg til. Når man disse grensene kan man begynne å tenke seg om: Har prosjektet blitt for stort? Kan jeg dele det inn i mindre enheter? Kanskje svarene er nei, men det er viktig å stille seg spørsmålene like vel.

Et eksempel: Å få deltagerne til å følge resonnementet ditt

Dette er et spørsmål jeg stilte til deltagerne på et scrum-kurs som jeg holdt flere ganger. Jeg lærte etter hvert hva som fikk forsamlingen til å svare:

1. “Skal teammedlemmene avgi status til Scrum master på morgenmøtet?” (svaret er “nei”, men sjansene for at noen føler seg dumme fordi de svarte feil er nesten 50%)
2. “Hvem skal teammedlemmene avgi status til under morgenmøtet?” (svaret er “hverandre”, men sjansene for at noen føler seg dumme fordi de svarer feil er godt over 50%)
3. “Hvorfor skal teammedlemmene ikke fortelle status bare til Scrum master på morgenmøtet?” (for åpent, folk vet ikke hvordan de skal angripe spørsmålet)
4. “Hvordan skal teammedlemmene fortelle status på morgenmøtet?” (fortsatt for åpent)
5. “Hva er feil dersom teammedlemmene gir status til Scrum masteren på morgenmøtet?” (nå starter det å nærme seg, men fortsatt for åpent)
6. “Hvilke negative effekter kan man oppleve dersom teammedlemmene kun gir status til Scrum masteren på morgenmøtet?” (her inviterer man deltagernes kreativitet inn i diskusjonen)

Et eksempel: Å få deltagerne til å tenke gjennom hva de har hørt

Her er noen spørsmål jeg har prøvd å stille til deltagerne etter at jeg har holdt et kurs.

• “Hvordan vil du bruke det du har lært?”: Hvordan-spørsmål blir fort så åpne at deltagerne ikke vet hvor de skal starte
• “Hvilke av teknikkene i Scrum vil være vanskelige å få til i deres organisasjon?”: Hvilke-spørsmål kan være åpne og medføre overfladisk gjennomgang.
• “Hvilken av teknikkene i Scrum vil være vanskeligst å få til i deres organisasjon?”: Hvilken-spørsmål inviterer til å gjøre en mental gjennomgang (som hjelper folk å huske) og begrenser hvor mye hver enkelt føler seg pliktig til å besvare. Egner seg godt for refleksjon på slutten av en workshop.
• “Hva vil du gjøre annerledes etter det du har lært?”: Et tung og forpliktende spørsmål. Effektivt, men må brukes med måte.

Hvilke spørsmålstillinger synes du stimulerer til god diskusjon?

Noen av oss kjører strikt, metodisk testdrevet utvikling. Andre bruker bare automatiserte tester nå og da som sikkerhetsnett for å unngå regress-feil. Hvor ofte fyrer du selv av testene dine? Kjører du testsuiten din en gang i ny og ne, eller strikt for hver metode du implementerer?

Jeg liker å kjøre testene mine ofte mens jeg arbeider. Det jeg liker enda bedre er å la utviklingsmiljøet mitt kjøre dem for meg, automatisk. Poenget med yrket vårt er jo nettopp å automatisere og effektivisere arbeidsprosesser – dette forsøker jeg å gjøre også med mine egne rutiner og verktøy. La oss se hvordan vi kan få til dette.

Mange av oss bruker allerede Continuous Integration for å oppdage feil i den felles kodebasen. Personlig autotesting er det neste, logiske steget: enhetstestene våre burde kjøre i bakgrunnen hver gang vi endrer noe, og gi oss umiddelbar tilbakemelding når vi knekker funksjonalitet. På denne måten oppdager vi våre egne feil før resten av teamet blir påvirket av dem.

Det finnes flere verktøy som gjør dette for deg:

• Infinitest (Java)
• Autotest / ZenTest (Ruby)
• Nosyd (Python)

Det er imidlertid ikke vanskelig å lage et enkelt autotest-verktøy på egen hånd. Jeg synes at det er en god ide å bruke litt tid her og der på å forbedre sitt eget utviklingsmiljø. Vi har jo muligheten til å lage våre egne verktøy (smeden er en av få håndverkere som kan si det samme). Som utvikler bør man iallfall klare å slipe sine egne kniver, for å si det sånn. Og dette er en god anledning!

Et naivt script for autotesting implementerer du på en ettermiddag. Alt du trenger er et lite program som reagerer på endringer i prosjektfilene dine, og kjører testene etter behov.

Algoritmen er enkel: La scriptet kjøre regelmessig, f.eks hvert sekund. Kontroller “forrige endring”-klokkeslettet for alle filene i prosjektet. Dersom klokkeslettet på en eller flere filer har endret seg siden forrige kontroll, så kjør enhetstestene til prosjektet. Analyser output fra testkjøringen, og se hvorvidt noen tester feilet eller kode knakk helt (exceptions). Gi så klar tilbakemelding om testene er ok eller feilet.

Tilbakemeldingen kan være litt grafikk og lyd på desktopen (for eksempel med Growl eller Snarl), en lavalampe på pulten, blinkende LED-lamper på laptopen… vær kreativ! Bare sørg for er at du får en tydelig tilbakemelding på hvorvidt testene feiler eller ikke.

Filmklippet under viser hvordan mitt eget autotest-miljø fungerer. Koden er i dette tilfellet skrevet i et språk som heter Clojure og ser derfor kanskje litt pussig ut, men ikke heng deg opp i det: det som demonstreres er at jeg knekker og fikser tester, og får automatisk godt synlig feedback på dette underveis.

Ikke spesielt komplisert.

“Dette ser jo genialt ut! Hvorfor bruker ikke alle autotest-verktøy allerede?”

Vel, det finnes dessverre noen utfordringer.

Dersom autotesting skal fungere hensiktsmessig må testsuiten som kjøres kun bestå av raske enhetstester, ikke tunge integrasjonstester. Og enhetstestene må gå kjapt! En test-run må ta sekunder, ikke minutter, ellers mister du gevinsten ved den umiddelbare feedbacken.

Problemet med trege tester er betydelig. Det finnes workarounds: man kan analysere avhengigheter mellom tester og kode, kun kjøre de berørte testene, kjøre raske tester først, feilende tester først, nylig feilende tester først… Men mange av oss har dessverre erfart at det er vanskelig å få til et godt fungerende opplegg for dette i et vanlig moderat stort utviklingsprosjekt.

Så er ikke autotesting nyttig likevel, da? Jo! Autotesting fungerer knallbra i små prosjekter (som ikke har samlet på seg så mye kode ennå) og egenopplæring (når du lærer nye verktøy og språk og ønsker å ta små steg med kjapp feedback). Det kan kanskje også fungere i større prosjekter dersom du har muligheten til å segmentere koden og testene dine i mindre moduler på en hensiktsmessig måte.

I bunnen av denne artikkelen har jeg vedlagt et eksempel på hvordan et enkelt autotest-script kan se ut, implementert i Ruby. Scriptet er skrevet for OS X-miljø, men koden bør være relativt lesbar og enkel å porte til ditt eget favorittspråk og utviklingsmiljø.

Happy testing!

Eksempel:

# Command line command which launches all unit tests
RUN_TESTS_CMD = "mvn clean test"

# Pick up any changes in files matching this filepath
FILES_TO_MONITOR = "**/*.java"

# Determine test outcome by scraping test output for #telltale signs of failure or exceptions

def test_failed?(test_output)
  return (test_output["FAIL in"] != nil) # Any 'FAIL in' strings in test result indicates failure
end

def exception_occurred?(test_output)
  return (test_output["EXCEPTION in"] != nil)
end

# Indicate test state by turning the background color of the test terminal
# a different color - yellow red og green. Currently uses Mac AppleScripts, but could be
# an audible signal, lava lamp, or anything else instead.

def indicate_tests_running
  `osascript bin/autotest/make-term-yellow`
  puts "\n\n\n----------------------------------"
  puts "TESTRUN STARTED #{Time.now}"
  puts "----------------------------------\n\n\n"
end  

def indicate_test_success(description)
  `osascript bin/autotest/make-term-green`
  puts description
end  

def indicate_test_errors(description)
  `osascript bin/autotest/make-term-red`
  puts description
end  

$monitored_files = {} # Stores the last changed time of each file    

def files_changed? # Check if any files have been touched/saved since last check
  file_changed = false;  

  Dir[FILES_TO_MONITOR].each do |filepath|
    if(!File.new(filepath).ctime.eql?($monitored_files[filepath]))
      file_changed = true;
      $monitored_files[filepath] = File.new(filepath).ctime
    end
  end  

  return file_changed
end  

def run_test
  indicate_tests_running
  result = `#{RUN_TESTS_CMD}`  #Run the tests, pipe resulting console output back
  display_results(result)
end    

def display_results(testOutput)
  if test_failed?(testOutput)
    indicate_test_errors("SOME TEST(S) FAILED\n"+testOutput)
  elsif exception_occurred?(testOutput)
    indicate_test_errors("EXCEPTIONS OCCURRED\n"+testOutput)
  else
    indicate_test_success("ALL TESTS SUCCEED\n"+testOutput)
  end
end  

def test_loop
  while true
    if files_changed?
      run_test
    end
    sleep(1) #seconds between each poll for file changes
  end
end  

test_loop # Start testing!

Fredag 28. mai var temaet for kvelden miljø og bærekraftig fremtid. Vi viste følgende foredrag:

• Anders Lindgren: Sustainability
• Bill Gates: Innovating to Zero
  Bill Gates snakker om løsninger på klima- og energikrisen og hvor langt de er unna.
• Shai Agassi: En dristig plan for elektriske biler
  Agassi har allerede konvertert et helt land til å kjøre uten olje. Her presenterer han en ny modell for elektriske biler som også ser på infrastrukturen rundt bilene.
• Dan Barber: How I fell in love with a fish
  En kjærlighetshistorie som belyser hvordan matvareproduksjon foregår i dag, og som viser at det er mulig å produsere bærekraftig dersom vi tenker annerledes.
• Stewart Brand: Slumbyer er en bra ting
  På 3 minutter viser Brand oss hvorfor slumbyer er bra, både for de som bor der og for befolkningstallet på kloden.

Bonusforedrag: Bill Gates nevner i sitt foredrag “geoengineering” — Hvordan vi kan endre været på kloden for å bremse effekten av oppvarmingen.
David Keith: En overraskende ide for å løse klimaendringer

Hva synes du om disse foredragene? Har du tips til andre gode foredrag vi bør vise? Si ifra i kommentarfeltet!

Lean kommer fra en asiatisk kultur, der det kollektive og prosessen i seg selv er det sentrale. Lean er laget for å strømlinjeforme en spesiell måte å løse en kjent oppgave på. Agile på sin side kommer fra USA, der individet fremheves over alt annet (“Individuals and interactions over processes and tools”). Agile er først og fremst en effektiv måte å jobbe på når vi ikke kjenner veldig godt til omfanget og innholdet i oppgaven, og er nødt til å finne veien samtidig som vi går den.

I et foredrag på Scandinavian Agile Conference 2009 presenterte Jim Coplien disse 9 punktene der Lean og Agile er motstykker:

En gjennomgang av disse punktene kan være tema for et senere innlegg. Det jeg vil presentere denne gangen, er to praktiske øvelser som illustrerer noen av forskjellene og styrkene ved Lean og Agile. Øvelsene tar ca 5 minutter hver.

Øvelse 1: Agile

Finn en gruppe på ca 10-15 personer, og la de stå i et åpent område som de kan bevege seg rundt i. Hver person skal tenke på to andre personer i gruppa. Når alle har valgt ut sine to personer (uten å avsløre til noen hvem de har valgt), så er oppgaven som følger: Hver og en person skal nå plassere seg slik i rommet at han eller hun har nøyaktig like stor avstand til de to personene vedkommende tenkte på.

Før de får begynne å løse oppgaven, så er dette et morsomt spørsmål å stille til eventuelle prosjektledere i rommet: Hvis man skulle benytte klassisk prosjektledelse til å lede gruppa i denne øvelsen, hvordan skulle man gå frem da? Hvilke planer og retningslinjer kunne man lage som ville hjelpe dem fram til et raskt og godt resultat? De fleste vil snart komme fram til den konklusjonen at det er en ganske vanskelig (kompleks) oppgave.

Om vi benytter Scrum som eksempel på en smidig måte å løse dette på, hva ville en god Scrum master eller coach da si? Bare gjør det! Vi lar gruppa være selvorganiserende, og lar hvert enkelt individ ta ansvar for å på en selvstendig måte løse sin del av oppgaven, men i tett samarbeid med de andre i gruppa. Resultatet vil bli at etter en kort tid med tilsynelatende kaotiske og uorganiserte bevegelser, vil alle ha funnet likevektspunktene sine som til sammen løser oppgaven. Et resultat som ville være svært mye mer krevende å oppnå med en sentralt styrt prosess.

Øvelse 2: Lean

Hva så med Lean, hvordan kan det illustreres ved hjelp av en øvelse? Her trenger vi litt færre personer, ca 10 er fint. Gi en tilfeldig person i gruppa en gjenstand han kan holde i handa (ei tom flaske er et godt alternativ), og presenter dem for følgende utfordring: Gjenstanden skal nå sendes fra person til person i alfabetisk rekkefølge basert på fornavn. Det skal skje så raskt som mulig, og de vil bli tatt tiden på!

Ved første forsøk vil gruppa bruke litt tid på dette. De må fortelle navnene sine for å finne riktig rekkefølge. De vil typisk bruke et halvt til to minutter på å bestemme rekkefølgen og sende gjenstanden rundt. Fortell dem resultatet, og spør så om de kan gjøre det igjen, raskere. Det vil de naturlig nok klare, etter som de nå bedre kjenner navnene til hverandre.

Etter å ha fortalt dem tiden for forsøk nummer to, la dem forsøke en gang til, og be dem tenke på måten de står plassert på. De vil oppdage at det å stå på rekke eller i en sirkel, i alfabetisk rekkefølge, vil gjøre det enklest mulig å sende gjenstanden fra person til person. Vi eliminerer waste!

Hvor raskt er det mulig å klare det? Om de står i en tett sirkel, og hver enkelt så vidt berører gjenstanden før nestemann gjør det, kan de klare øvelsen på under et sekund. Det vil være en ganske dramatisk forbedring fra det første forsøket! Det viser hvor effektiv Lean kan være på denne typen oppgaver.

Oppsummering

Lean og Agile er laget for å løse forskjellige typer oppgaver. De kommer fra forskjellig bakgrunn, og selv om de virker like, så skiller de seg vidt fra hverandre på noen sentrale områder. Øvelsene over demonstrerer noen av de spesielle styrkene til de to prosessene. Disse styrkene er det viktig å huske på når man skal velge tilnærming til et prosjekt eller andre arbeidsoppgaver som krever en god prosess.

Hvilke erfaringer har du som leser gjort deg med Lean og Agile? Har du opplevd oppgaver eller prosjekter der de har passet spesielt godt eller spesielt dårlig?

I Crossing the Chasm foreslår Geoffrey Moore en mal for å lage visjon som jeg selv har hatt mye hell med:

• For <en målgruppe>
• Som har <et behov eller en mulighet>
• Så er <produktnavnet> et <type produkt>
• Som <har en god grunn til å like>.
• I motsetning til <viktigste alternativ>
• Har vårt produkt <viktigste differensiator>

Formen er ment brukt til å beskrive produkter, som for eksempel “For skogbruksansvarlige på fylkesmannens kontor som skal forvalte skogsprosjekter så er skogsforvaltningsløsningen et regnskapsystem som gir kontroll og oversikt over regnskapet. I motsetning til den gamle versjonen av systemet gir vår løsning støtte for fullstendig elektronisk saksbehandling.”

Jeg har også brukt den til workshops og andre aktiviteter. Når jeg avholdt en Scrum-workshop startet gruppen med å utarbeide følgende visjon: “For nye og litt erfarne Scrum Mastere som ønsker å bli bedre Scrum Mastere så er Iterasjon-0-workshoppen en gruppeaktivitet som gir konkrete tiltak til aktiviteter. I motsetning til å lese en bok gir denne aktiviteten mulighet til å utveksle erfaring med andre som har samme rolle.”

Slik går jeg fram for å hjelpe en gruppe med å komme fram til en visjon:

1. Først bruker jeg fem minutter på å forklare formatet og hvorfor vi gjør oppgaven
2. Jeg deler gruppen opp i arbeidsgrupper på 3-4 personer. En arbeidsgruppe mister noe når det blir mer enn 4 personer
3. Hver gruppe får ti minutter på å fylle ut formatet over. Dersom det er mye gode diskusjoner i gruppene lar jeg dem gå fem minutter over tida.
4. Jeg går gjennom malen og ber alle gruppene lese opp for forsamlingen hva de svarte på hvert punkt. For hvert punkt spør jeg åpent “hvilket svar var best?” Det nominerte beste svaret skriver jeg på tavle eller flipover. Dette tar cirka ti minutter.
5. Vi avslutter workshopen med en liten oppsummering av hva folk fikk ut av øvelsen.

Totalt får man en brukbar, felles visjon for en gruppe på under en halv time. Som en bonus blir gruppa som helhet litt bedre kjent med hverandre.

1. Vær god til å søke etter og tilegne deg informasjon raskt. Hvem har ikke sittet i møter der navn eller tre bokstavs forkortelser blir kastet i mot deg med største selvfølgelighet. Har du ikke hørt om det? Er du helt utdatert eller? Det er flere enn en gang man henter seg inn med et godt søk på internett mens bombardementet pågår. Konsulenttriks kaller noen det, jeg kaller det overlevelsestaktikk. Det er helt umulig å ha full oversikt over alt alltid. Mengden informasjon er simpelthen for stor.
2. Aksepter at verden endrer seg raskt, og vær åpen for nye og andre innfallsvinkler enn din egen, vær pragmatisk. Et eksempel: Noen insisterer fortsatt på at bunnposting er tingen i e-post, og argumenterer gjerne heftig for det. Dette til tross for at de aller fleste topp-poster, de fleste klienter viser tråden for emnet og mobiltelefonklienter bare viser toppen av mailen. Vedkommende som har skrevet har lagt sitt svar under noe du for lengst har lest. Det fremstår som unødvendig nerdete.
3. Basiskunnskap består. Lesing og matte er kanskje de viktigste av alle basiskunnskaper. Dette danner selve fundamentet for punktene over, så her gjelder det å være god. Læreplanen i den norske grunnskolen i dag er faktisk veldig lik den som ble laget i mellomkrigstiden på 1930-tallet. Sirkelen er fortsatt rund, linjen er fortsatt rett. Bokstavene ordnes ofte i alfabetisk rekkefølge (alfabetet begynner ikke med QWERTY…) og er de samme som før. Det er her kløften i samfunnet skapes, de som er flinke til å lese og liker å lese, og de som ikke liker å lese eller er dårlig til å lese og faller av skolen. Fatt mot, det er mulig å øve på hurtiglesing.
4. Vær kildekritisk og gjør deg opp din mening. Mange journalister er så hardt presset at de ikke har tid til å undersøke det de skriver. Dersom artikkelen bærer preg av å være markedsføring så er den gjerne det. Ofte kan også økonomiske, politiske eller personlige meninger ligge bak. Kanskje sympatiserer også journalisten med budskapet og det blir enda mer farget. Forsøk å finne en journalistisk artikkel som er negativ til Apple, første treff på Google er wikipedia.
5. Niche thyself. Oversatt betyr dette noe sånt som «finn din nisje». Ordene tilhører Guy Kawasaki og kommer fra boken ”the art of the start”. Han sa det om oppstartsbedrifter. Jeg mener det er minst like sant om fagpersoner. Kan du veldig mye om et smalt felt som er relevant og etterspurt, er du sikret jobb – i hvert fall en stund, til det du kan ikke lenger er etterspurt. Og så må du finne deg en ny nisje. Uttrykket burde kanskje modifiseres litt – Niche thyself, and again, and again.

 En bør altså være god til både å lære og å huske. Læring har imidlertid blitt mye viktigere enn husking i kunnskapssamfunnet enn hva det var i industrisamfunnet. Det er rett og slett komplett umulig å huske og kunne alt som er tilgjengelig. Er man lykkelig med det man vet og forberedt på å lære noe nytt går det som regel bra. Hvis ikke, google fungerer på iPhone under bordet også.

Det var mine topp fem overlevelsespunkter i kunnskapssamfunnet. Har du andre forslag til punkter?

• Påpek noe positivt: Etter kurset fikk vi en mail fra en av deltagerne som sa “takk for kurset, det var veldig bra”. Det gjorde meg bevisst på hvor sjeldent vi gir og mottar skryt uten at det er et “men…” hengende rundt hjørnet og hvor motiverende det er når man faktisk får det.
• Vær konkret: Dersom du sier “foredraget var litt uklart”, gjør du mottakeren av kritikken en bjørnetjeneste. Uten at du påpeker noe konkret er det vanskelig for mottakeren å gjøre noe med det. Dersom du i stedet kan si: “Eksemplene gikk litt fort”, så er det lettere å gjøre noe med det.
• Foreslå en forbedring: I stedet for å peke på hva som var dårlig, kan du finne rom for å gjøre det bedre?
• Motiver forbedringen: I stedet for å bare gi et forslag til forbedring, kan du forklare hvordan endringen vil forbedre foredraget. Det tydeliggjør at du ønsker å hjelpe, samtidig som du anerkjenner at det er den som mottar forbedringen som tar den endelig avgjørelsen.

Som et eksempel på prinsippet, sa jeg under kurset til min med-instruktør: “Du Ram, ‘å bli en bedre presentatør’ høres litt klønete ut. Dersom du i stedet sier ‘å bli flinkere til å presentere’, så tror jeg setningen vil flyte bedre.”

Er du bevisst på å gi gode tilbakemeldinger? Hvilken tilbakemelding kan du gi meg når det gjelder denne artikkelen?

Fredag 5. februar viste vi følgende foredrag:

• Alexis Ohanian: How to make a splash in social media (Mr Splashy Pants)
  Et av de korteste foredragene vi har sett, men også ett av de mest effektive. Ohanian forteller deg hemmeligheten til å lykkes i sosiale medier gjennom en sann historie.
• Rory Sutherland: Life Lessons From an Ad Man
  Underholdende og tankevekkende foredrag som vil få deg til å se markedsføring i nytt lys.
• VS Ramachandran: The neurons that shaped civilization
  Utsagnet om at alle mennesker er koblet sammen viser seg å være langt sannere enn vi først trodde. Det er faktisk bare huden som skiller oss. Hør om de fascinerende nevronene som kobler oss sammen.
• Robert Full: How engineers learn from evolution
  Du skulle ikke tro at et foredrag om føtter kan være fascinerende, men jo det kan det være! Se hvordan neste generasjon med roboter har dramatisk bedre fremkommelighet fordi forskerne har studert naturen og etteraper naturens konstruksjoner.
• Pranav Mistry: The thrilling potential of SixthSense technology
  Dette er den beste teknologidemoen du vil se i 2010. En ny vri på såkalt “augmented reality” — og teknologien er til og med rimelig!
• Ariely performs experiments on pain and immorality
  Fascinerende på flere plan. Ariely tar for seg både smerte og umoral. Svært interessant om hvordan og hvorfor folk jukser og hvordan tradisjonell økonomisk teori kommer til kort for å beskrive den irrasjonelle oppførselen rundt juksing.

Hva synes du om disse foredragene? Og har du tips til andre gode foredrag vi bør vise?