Presisering rundt sosialdemokratiet

Jeg var så heldig å få sjansen til å holde min lyntale på Oslo XP Meetup igår. Det var utrolig spennende fordi det var diskusjon umiddelbart etter lyntalen. I motsetning til på konferanser så måtte jeg her svare for mine tildels breibente påstander om det ene og det andre.

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.

Enkelhet, ikke så enkelt

Dette er en artikkel i kategorien refleksjon og det kommer som et resultat av det jeg har erfart i de siste årene hvor Smidig-bevegelsen virkelig har blitt allemannseie. Jeg har både vært team medlem, Scrum Master, arkitekt og delvis produkt eier i ulike sammenhenger. En ting har alltid ligget å ulmet i bakhodet mitt de siste årene og det har med begrepet enkelhet eller simplicity.

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.

Refleksjoner rundt Smidig 2009

Nok en gang samlet Smidig-menigheten seg til to dager i refleksjonen og læringens tegn på Smidig 2009 konferansen. Konferansen er den største grasrot konferansen i Skandinavia som handler om smidige metoder. De frivillige som bruker enormt med tid på å gjøre dette mulig fortjener all mulig heder og ære. Jeg har vært så heldig å få delta de to siste årene og det har vært ekstremt læreriktig og morsomt.

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

Tenke globalt, handle lokalt

Tittlen er et kjent slagord fra miljøbevegelsen når det gjelder hvordan man skal bekjempe klimaproblemene vi står ovenfor. Jeg føler det samme slagordet gjelder for smidige metoder og hvordan man best klarer å få smidige metoder til å fungere i sin organisasjon.

Smidig systemutvikling handler veldig mye om kommunikasjon og mellommenneskelige relasjoner. Likevel er dette et element som veldig skjelden blir adressert hverken i prosjekter eller i debatter om smdige metoder. Allistar Cockburn har skrevet en del om dette i sin utmerkede bok Agile Software Development, likevel føler jeg at det er et poeng han og mange andre glemmer å adressere: kulturelle forskjeller.

Kulturelle forskjeller utgjør den store forskjellen

Kommunikasjon mellom mennesker i jobbsammenheng i Norge og for eksempel i Tyskland er veldig forskjellig. Tyskland har en mer hierarkisk måte å forholde seg til hverandre enn hva man har i Norge. Tilsvarende er det forskjeller mellom Japan, USA, Polen, Svergie, Danmark også videre også videre. Disse kulturelle forskjellene mener jeg er noe man i større grad bør adressere når man diskuterer hvor smidige metoder skal gå videre nå.

Veldig mye av litteraturen om smidige metoder handler kommer fra USA og er veldig farget av hvordan arbeidsmiljøet er der borte. Måten man jobber på i USA er veldig forskjellig fra hvordan vi gjør det i Norge. Dette gir seg særlig utslag i en av de viktigste delene av en smidig metode, nemlig retrospectives. Et interaktivt forum hvor man skal åpent utviksle erfaringer og forbedringer vil kreve ulike teknikker i et amerikanske arbeidsmiljø enn i et norsk. Grunnen er at norsk arbeidskultur har et helt annet sett med grunnverdier enn det som er vanlig i blant annet USA.

Gjør lokale tilpassninger

Når du og din organisasjon har begynt å jobbe med smidige metoder er noe av det viktigste dere kan gjøre når dere har fått litt erfaring er å forsøke gjøre lokale tilpassninger. Still spørsmål rundt hvorfor dere gjør tingere dere gjør? Hvorfor gjør vi stand-up? Fungerer retrospectives slik vi gjør de? Passer stand-ups til de menneskene vi har i vår organiasjon? Har vi personligheter som gjør at vi får noe ut av retrospectives?

Dette er noen av spørsmålene som dere bør stille dere slik at dere kan gjøre lokale tilpassninger til smidige metoder som f.eks Scrum. Still spørsmål ved alt og se på hvordan det passer til din organisasjon. Deretter gjør dere endringer eller justeringer slik at dere får en metode som passer dere organiasjon.

Norsk smidighet

Jeg føler at det mest konstruktive man kan gjøre når man snakker om å videreutvikle smidige metoder her i Norge er å gjøre lokale tilpassninger som tar høyde for hvordan man nordmenn kommuniserer og arbeider i Norge. Særlig ville jeg lagt vekt på hvordan retrospektives gjøres, for her er ikke nordmenn særlig flinke. Vi er generelt altfor positive og tilgivende ovenfor dårlige rammebetingelser. Dette er noe som er et problem ettersom man da ikke får gode tilbakemeldinger på hvordan metoden fungerer.

Det er vitkigere å komme med tillegg til det smidige manifest enn å lage komersielle innpakninger for å selge konsulenttimer slik som man har gjort med Agile 2.0. Miljøet rundt smidige metoder i Norge er veldig levende og det er veldig mange flinke folk som bidrar i debatter. Jeg er sikker på at det norske smidige miljøet kan ta smidige til det neste steget ved å gjøre tilpassninger som reflekterer hvordan man samarbeider i norsk arbeidsliv.

Jeg vet hvorfor du ikke “får til smidig”

I andedammen her i Norge har skeptikerne til smidige metoder virkelig fått vann på mølla ettersom flere og flere “står frem” med sine historier om hvordan de ikke har vært på et eneste bra smidig prosjekt.

Smidige fundamentalister vil gi deg følgende svar: “Hvis det ikke virker, så gjør du det feil”. Hvilket egentlig ikke er noe svar siden det ikke gir den som sliter noen løsning. Særlig ettersom svaret på “hva er riktig måte?” ofte er: “Du må bare tilpasse og plukke det som passer fra Scrum”. Igjen er dette svaret like nyttig for en som ikke får til smidige metoder som det vil være å si til en nyfødt baby: “Hvordan skal vi ta på bleien idag?”. Uten god kunnskap og erfaring vil hverken du som nyfrelst Scrum bruker eller babyen klare å velge riktig fremgangsmåte.

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