Smidig

Hvordan bør man kjøre utviklingsprosesser? Hvordan ivaretar man alle interessenter? Hvordan sikrer man at man utvikler det virksomheten faktisk trenger med riktig kvalitet? Og ikke minst: Hvordan skaper man entusiasme og energi i teamet? Dette skriver vi om i denne bloggen.

SONY DSC

Når kunnskap og karisma erstattes av kustus

Hvorfor er brukskvalitet i Scrum så vanskelig?

Foto: Enrique Fernández. Fra Flickr. Brukt i henhold til CC BY 2.0

Onsdag 19. januar 2011 presenterte Klara Vatn og Ram Yoga sine tanker rundt temaet “Hvordan jobbe som interaksjonsdesigner i smidige prosjekter?” på IxDA i Oslo. Klara og Ram var evangelistene som snakket varmt om smidige prosjekter uten å glemme utfordringene. Problemet var at de ikke ga noe svar på spørsmålet. Ikke noe fasitsvar, i hvert fall. Som ellers i fagområdet er svaret: “It depends”. Eller i dette tilfellet, det smidige svaret: “We learn, and adapt.”

Rigide strukturer er et resultat av dårlig ledelse. Denne uttalelsen er ikke et sitat fra foredragsholderne. Den står for egen regning. Og det er en spissformulering. Men det illustrerer et problem med Scrum. Du kan nemlig gjennomføre alle seremoniene i Scrum uten å jobbe smidig. Det er til og med kjempeenkelt. Du erstatter, bevisst eller ubevisst, begrepet “iterasjon” med “inkrement”, og så gjennomfører du et fossefallsprosjekt med micromanagement.

Ideelt sett har du en gjeng prosjektdeltakere med yrkesstolthet som ønsker å jobbe sammen for å få et godt sluttprodukt. Som prosjektleder eller prosjekteier trenger du kunnskap om og respekt for brukernes behov, forretningens behov og prosjektdeltakernes individuelle ferdigheter, for å samle teamet og motivere alle til å levere kvalitet. Den jobben er enklere hvis du er lett å like, derav karisma.

Det er et problem hvis du prøver å styre prosjektet uten denne kunnskapen, og uten å være klar over hvilket tankesett som ligger bak Scrum. Det første punktet i manifestet for smidig programvareutvikling er “Personer og samspill fremfor prosesser og verktøy”. Da er det dumt å fokusere mer på at teammedlemmene reiser seg opp klokka ni om morgenen for å fortelle hva de gjorde i går enn at de snakker sammen i løpet av dagen.

Det er også et problem, som Morten Krogh-Moe påpekte fra salen, at det skal rapporteres videre til en ledelse over deg igjen. Hvor interessen for å være smidig ikke nødvendigvis gjennomsyrer den enkeltes personlighet. Når du betaler for noe, vil du gjerne vite hva du får og når du får det. Da blir det viktig med fremdrift, og det vil prosjektdeltakerne merke når fokuset rettes mot hvor fort man kan flytte lapper på tavla.

Kultur, den fjerde k-en. Hva hvis du ikke har prosjektdeltakere som er flinke? Som ikke leverer kvalitet? Hva hvis du har folk som ikke forstår hverandre? Som heller sitter alene uten å snakke sammen? Da mangler du den nødvendige kulturen i gruppa, og kunnskapen og karismaen din faller død til jorden. Eller på stengrunn. Uansett – du griper sannsynligvis den eneste muligheten som synes åpenbar, og legger ned et regime av prosesser.

Interaksjonsdesignere, grafiske designere og informasjonsarkitekter er fremdeles fremmedkulturelle i mange utviklingsmiljøer. De er i tillegg en knapp ressurs, og sitter ikke nødvendigvis sammen med utviklerne hver dag, hele dagen. Når du legger til at Scrum er skreddersydd for utviklere har du et smörgåsbord av problemer å fråtse i.

Svaret på spørsmålet. Vi har ikke det endelige svaret på spørsmålet om hvordan interaksjonsdesigneren bør jobbe i smidige prosjekter. Vi har ikke svaret på hvordan man jobber med behovsavklaring, skissering, spesifisering, testing og evaluering i hver eneste iterasjon. Men vi jobber med det. Sammen med de andre i teamet.

7 kommentarer om “Når kunnskap og karisma erstattes av kustus

  1. Takk for fin post, Harald! Gøy å lese inntrykket ditt. Jeg likte spesielt denne delen:

    Klara og Ram var evangelistene som snakket varmt om smidige prosjekter uten å glemme utfordringene.

    Jeg har aldri tenkt på meg selv som smidig evangelist før jeg leste den setningen. Om noe har jeg følt meg som en smidig skeptiker, siden jeg i så mange år måtte finne ut hvordan jeg skulle fungere i smidige prosjekter. Men du har nok rett, for spesielt etter å ha jobbet to år i et tradisjonelt fossefallsprosjekt, føler jeg virkelig at jeg savner smidigheten i de gode smidige prosjektene.

    Men hvis jeg først skal fremstå som evangelist er det godt å høre at jeg ikke fremstår som helt blind for utfordringene. For utfordringer er det mange av!

  2. Min erfaring som interaksjonsdesigner er at det gjelder å ligge et hestehode foran utviklerne i prosjektgjennomføringen. Planlegge grundig hvordan sluttproduktet av det som utvikles skal virke for brukerne, før utviklerne skal skrumme det. Mindre diskusjon, mer effektivt. Men det er mulig vi blir stående litt utenor smidigheten på denne måten?
    PS! Jeg var ikke på foredraget 19. jan. Det skulle jeg gjerne vært :)

  3. God artikkel om et stadig tilbakevendende problem. Jeg ser svært ofte at ux er noe mange sliter med i smidige prosjekter, og som det ikke er så mange gode generelle løsninger på.
    Jeg er enig i at du kan gjennomføre alle seremoniene uten å være smidig, men du kan ikke kjøre scrum uten å være nødt til å tenke annerledes. Man blir litt tvunget til å forlate gamle fossefall-tankegang når man må levere noe deployerbart etter hver sprint.
    Jeg tror ikke det er et stort problem at Scrum er så rigid, fordi Scrum er rigid på så lite. Scrum har alltid vært et sett med regler som skal hjelpe oss til å komme inn i den smidige tankegangen og holdningen. Be Agile, do Scrum.
    Personlig liker jeg veldig godt Ron Jeffries lettere humoristiske omskriving av Alistair Cockburns Crystal Clear definisjon av Agile:

    “Come together in peace love and understanding, ship software frequently, and think about it.“

    @Synnøve: Ja, jeg tror vi blir mindre smidige på den måten fordi vi øker tilbakemeldingssløyfen (demo diskusjonens tilbakeføring til implementeringen). Jeg er større tilhenger av at interaksjonsdesigner er med i teamet og utformer der som skal demonstreres på neste demo, og har fokus på sitt eget fagområde under diskusjonen og under implementasjonen med teamet. Ellers har vi fort et lite min-waterfall igjen.

  4. Jeg deler Synnøves oppfatning om at interaksjonsdesignere bør få ligge et hestehode foran utviklerne. Hvorfor? Enkelt og greit fordi at utviklere ikke er tankelesere. Jeg har enda til gode å møte en utvikler som vil være i stand til å kode et design som ikke er skissert, brukertestet og justert etter tilbakemeldinger fra brukerne. Alle som har jobbet med brukerdrevet design, vet at dette er en prosess som tar tid, på lik linje med programmering. At design, testing og utvikling skal skje innenfor én sprint på 2 uker, er i mine øyne optimistisk og på grensen til naivt.

    Ikke glem at scrum skreddersydd for utviklere. Samtidig vet vi at brukere i 2001 forventer løsninger som gir gode brukeropplevelser. Jeg vet at brukerdrevet design og programmering i scrum-team kan forenes, da jeg selv er en del av et team hvor vi begynner å få dette til. Men det krever at en er villige til å tilpasse seg.

  5. Jeg er egentlig fristet til å si “ja takk, begge deler”. Interaksjonsdesignerern bør være med i teamet og fokusere på sitt fagområde i utformingen av det som skal demonstreres ved sprintens slutt, men uten et grundig IA/ID-forarbeide, som et ledd av en total konseptutvikling, ender vi opp med et teknologistyrt produkt, ikke et brukerstyrt.

  6. Klara har lagt ut foredraget som ble holdt på Meetup-en her: http://www.slideshare.net/klaravatn/hvordan-jobbe-smidig-som-interaksjondesigner

    Nå må jeg innrømme at vi jobber med å formalisere brukskvalitetsaktivitetene inn i den overordnede Scrum-prosessen. For å følge opp Sten Johnsens: “Scrum har alltid vært et sett med regler som skal hjelpe oss til å komme inn i den smidige tankegangen og holdningen”: Vi legger til noen regler for å sikre involvering mellom ulike roller i de prosjektene der vi har kulturkollisjoner.

    Uten å presentere alle detaljer kan jeg si at det innbefatter et produktplanleggingsmøte mellom brukskvalitet, produkteier og teknisk ansvarlig hvor neste sprints ønskede product backlog items skisseres ut, og hvor spesielt brukskvalitet har noen oppgaver før og etter det møtet.

    Vi må bare finne en troverdig måte å samle alle disse oppgavene i så korte perioder … Og med “så korte” mener jeg ikke to uker. Det tror jeg er urealistisk for de fleste prosjekter.

    Når det gjelder det å ligge foran, som både Synnøve og Ole nevner i kommentarene sine, ser jeg helt klart viktigheten av dette. Og produktplanleggingen er et ledd i å nå det målet. Men vi er avhengig av at også kjørbar kode brukertestes og justeres etter tilbakemeldinger fra brukerne. Ikke bare skisser og prototyper.

    Erfaringen tilsier at det er vondt å kaste allerede utviklede løsninger. Det koster mer enn å kaste en papirprototype, i hvert fall. Spørsmålet er om det er en pris vi er villige til å betale for å jobbe smidig sammen – i reelle iterasjoner? Respekterer vi en brukertest like mye som en integrasjonstest? (I tilfellet intranett eller fagapplikasjon har jeg en følelse av at mange heller sender brukerne sine på kurs enn å rette problemene.)

    Når vi diskuterer dette internt kommer vi raskt inn på viktigheten av å ha et godt forprosjekt. Uten at noen nevner “Scrum” en eneste gang. Og uten at vi er noe mindre smidige av den grunn. Vi er bare mer opptatt av helheten.

  7. Dette var et innlegg som inviterte til debatt, Harald.

    Vinklingen med med de 4 K’ene er ny for meg og kaster et nytt perspektiv over metoden. Jeg er helt enig. Kunnskap, karisma og kultur er ord som passer inn i scrum, men kustus hører ikke hjemme i den metoden. Hvorfor oppstår kustus? Jeg tror ikke det bare skyldes mangel på karisma.

    Men jeg er egentlig akkurat nå mest opptatt av å svare på spørsmålet ditt. Hvorfor er brukskvalitet så vanskelig i scrum?

    Aller først:
    • Jeg har klokketro på at scrum i utviklingsprosjekter vil føre til et resultat som vil matche kundens forretningsmål bedre enn ved en annen metode.
    • Jeg har tro på at det beste er at alle deltagere i teamet jobber på de samme user storiene mest mulig samtidig.
    • Jeg har tro på at kunden får mer verdi for pengene ved å la de som jobber med brukervennlighet få være med i hele prosjektet. Denne typen ressurser er ikke bare do’ere som tegner skisser og kjører brukertester, de er også rådgivere ifht hvilke valg kunden skal ta for å nå sine forretningsmål. Interaksjonsdesignere og back-end utviklere vil få muligheten til lære mer av hverandre og dermed slutte å snakke forbi hverandre når de snakker om de samme tingene.
    • Jeg har tro på at det er en merverdi i å legge ned gjerdene rundt våre faste roller og se muligheten i å tråkke litt på hverandres plener. En fullstendig overlapp er nok hverken ønskelig eller mulig, men interaksjonsdesignere, grafiske designere og front-end utviklere vil etterhvert kunne bistå og hjelpe hverandre med deres oppgaver. Front-end utviklere og back-end utviklere vil også ha nytte av å tråkke litt i hverandres bedd. Tenk bare på den gevinsten det får når et teammedlem er borte fra jobben.

    Mitt svar er så langt at jeg har laget et eget blogginnlegg “Iterativt utvikling er en utfordring i scrum”.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

Du kan bruke disse HTML-kodene og -egenskapene: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

retro_threecol_redcross

Retrospectives without post-its?

Two Bouvet consultants, Morten Granum and myself are currently working with a team to introduce some elements from Kanban and..

Bilde fra kontorlandskap

Min dag i et konsulentselskap

Hvordan foregår det egentlig når nettsider og digitale løsninger skal utvikles? Dette prøvde jeg å finne ut da jeg besøkte..

Hva er Kanban?

Det finnes mange ulike beskrivelser av Kanban.  Er du interessert i å vite litt mer om hva det egentlig er?

Jenkins

Android App With Jenkins

I just got involved with a mobile project, and had to let my inner devop out for a moment… So, here’s..

Finne rett audience i SharePoint

Samhandlingsplattformen SharePoint har mulighet for å personalisere komponenter gjennom bruk av audiences. Hvis du jobber med konfigurering av SharePoint, så har du kanskje hatt problemer med å vite hvilke brukere et audience i SharePoint inneholder. Eller problemer med å finne et audience som faktisk av er interesse for deg innenfor den gitte SharePoint applikasjonen du benytter?

Autotest

Thoughts on Unit Testing in Asp.NET MVC

I have been working with TDD and Mvc in different flavors for 10 years now. The last 2 years I have been working with Asp.Net Mvc. I have written down some thoughts on unit testing in an Mvc app with principles that I have come to value. These principles help me write good maintainable tests. Much of it also applies to unit testing in general.

En praktfull eske fra pappverket

Den triste IT-historien om Pappverket

Alle trenger pappesker. Grunnet eskemangelen i mellomkrigstiden bestemte myndighetene seg for å rasjonalisere og sentralisere produksjonen og tildelingen. Slik oppsto..

Smidig

Hvordan bør man kjøre utviklingsprosesser? Hvordan ivaretar man alle interessenter? Hvordan sikrer man at man utvikler det virksomheten faktisk trenger med riktig kvalitet? Og ikke minst: Hvordan skaper man entusiasme og energi i teamet? Dette skriver vi om i denne bloggen.