Før vi forteller historien til Oskar, må vi forklare noen begreper og komme med visse antagelser:

Kanban er japansk og betyr “kort” eller “tegn/signal”. Begrepet ble først tatt i bruk av Toyota på 70-tallet for å minimere produksjonskostnader og å ha bedre styring på oppgaver og arbeidsmengde. Det er enkelt og greit et kø-system. I dag brukes det flittig i utvikling av IT-løsninger, og kalles som kjært barn med mange navn: kanban, board, tavle eller lignende.

For at denne artikkelen skal gi mening må vi også komme med antagelsene om at dere som vil få mest ut av den sitter i et tverrfaglig team, jobber etter kanban-prinsippet, har en tavle og har kort vei fra idé til produksjon.

Så, til historien om Oskar og hagen

I denne artikkelen skriver vi om vår fiktive venn og designkonsulent Oskar, som har vært i et tverrfaglig team i rett under et år. Teamet til Oskar er en produkt-trio med utviklere, designer og produkteier, slik Teresa Torres definerer det. Oskar har ikke jobbet med, eller lært om kanban-prinsippet før, og oppdraget han sitter på nå er hans første møte med såkalte “boards”, eller tavle.

Oskar har følt en god stund at han ikke hører helt hjemme i Kanban-boardet til teamet han jobber med. Det er vanskelig for ham å sette fingeren på nøyaktig hva det er, men han opplever at det funker mye bedre for utviklerne enn for ham selv. Dette er noe han ikke er alene om, det er mange designere som føler på det samme. Oskar forteller oss at han ikke vet om gresset er grønnere på noen andre tavler, men vi mener at gresset hans er dårlig vannet og kunne hatt godt et par runder med kalk.

Teamets gartner-system

Oskar sitter i et team som startet å lage en ny løsning fra bunnen av. Teamet hans arvet mye innsiktsarbeid, en enorm prototype i Figma og en uhorvelig mengde brukerhistorier og akseptensekrav i Jira (ett av mange kanban-verktøy). I praksis var det i grove trekk bestemt hva han skulle lage før han begynte å jobbe med produktet.

Kanban-tavla til teamet hans er delt i to: upstream og downstream.

I upstream-tavla er det UX, spesifisering og prioritering som dominerer beitene. Oskar trekker lapper fra produktkøen (andre kaller det backlog) inn i UX-kolonnen og gjør sin magi. Når han har laget noen skisser på hvordan ting kan løses legger han lappene inn i grooming-kolonnen. Her skrives akseptensekrav om for å passe slik skissene har blitt. Når lappene har oppdaterte akseptensekrav legges de til prioritering, og deretter over i ferdig spesifisert-kolonnen, som er utviklerne sin produktkø. Teamet har ukentlige prioriteringsmøter der de ser på utviklerne sin produktkø og legger de viktigste lappene øverst i køen.

Downstream-tavla er utviklernes rike. Oskar synes at dette ligner arbeidsprosessen slik han forventer en produkttavle vil se ut. Lapper legges i “in progress” fra den prioriterte produktkøen ”ferdig spesifisert”, trekkes over i QA (Quality Assurance) når det blir en PR (Pull Request, et begrep utviklerne bruker når de vil legge koden sin inn i den felles produktkoden). Etter det beveger det seg gjennom kolonne etter kolonne med ulike testmiljøer, før lappen endelig blir godkjent og trekkes over i “Done”.

Ugress i teamets hage

Oskar merket ganske tidlig at han følte seg isolert fra resten av teamet på grunn av kanbantavla. Han gjør design-oppgaver i ux-kolonnen på upstream-tavla, produkteier gjør spesifisering av lappene i de andre kolonnene på upstream-tavla, mens utviklerne tar lappene gjennom downstream-tavla. Oskar sitter altså i et team som ikke fungerer slik det skal siden ingen egentlig jobber “sammen”. Teammedlemmene samarbeider, men det er sjeldent at de jobber sammen med samme oppgave, samtidig.

Vi vil skjerme utviklerne for spesifiseringen av lappene.

Oskar mistenker at han kanskje er den eneste som tydelig merker at tavla stritter litt imot ham. Han er den eneste som jobber på tvers av begge tavlene. Utviklerne på teamet synes at det er deilig å ha downstream-tavla for seg selv, for da slipper de å ta stilling til hva som skal lages og hvorfor. Produkteier har også alt hen aktivt trenger å ta stilling til i upstream-tavla, før lappene legges i downstream-tavla. Ingen andre i produkt-trioen legger merke til at samarbeidet fungerer dårlig siden de andre gruppene har sitt eget arbeid så tilrettelagt for å gjøres uten input fra noen i de andre rollene.

De grønne fingrene jobber ikke smidig

Oskar har også merket at det er gnisninger mellom hvordan han og teamet naturlig ønsker å jobbe, og hvordan tavla legger opp til at de skal jobbe. Både Oskar og utviklerne har en drøm om å jobbe med frontend sammen, en slags par-design der de sammen kommer frem til den beste løsningen. Dessverre har dette bare skjedd to-tre ganger siden teamet begynte å jobbe sammen for snart ett år siden. De gangene Oskar og utviklerne har par-designet noe så har han alltid måtte lage skisser på hva de kom frem til etter at utviklerne implementerte det. Dette skjer fordi tavla deres krever at skisser fra Figma legges i en lapp innen den går til “in progress”-kolonnen. Oskar og utviklerne skulle gjerne ha jobbet smidigere sammen, men da gir tavla dem et etterslep av arbeid som ikke tilfører noen verdi.

På samme måte som å lage skisser på ting som allerede er implementert, bruker teamet unødvendig mye tid på å skrive ned akseptensekrav på hvordan produktet skal fungere. Når Oskar prater med utviklerne om hvordan de kan dekke et behov i produktet, baserer han skissene på det. Etter at Oskar har “levert” skissene sine, skriver produkteier og testleder ned masse detaljerte akseptensekrav om hvordan produktet skal fungere. Oskar har stilt spørsmålstegn ved verdien av dette tidligere, men har fått vite av produkteieren at hen vil ha det for dokumentasjonens skyld. Oskar har ikke all verdens erfaring med å jobbe smidig, men han tenker instinktivt at slik det gjøres nå medfører veldig mye dobbeltarbeid. Han tenker at funksjonaliteten bør komme frem i skissene og gjennom samarbeid i produkttrioen. Akkurat nå jobber teamet som om fasit på hvordan produktet skal se ut og fungere ligger i Jira, ikke i produksjon.

Hva skjer når problemene rotfester seg?

Oskar har merket at han ikke egentlig vet så godt hva utviklerne driver med når teamet har sine daglige stand-up’er. Når man har hver sin tavle så tenker man ikke så mye på hva som skjer på den andre tavla. Han har ikke så godt forhold til hva som implementeres og sendes ut i produksjon akkurat nå, mens utviklerne ikke vet så godt hvilke nye muligheter han utforsker. Dette har ført til at Oskar stadig vekk finner ting i produksjon som ser helt annerledes ut enn slik han lagde det i skissene. Da må han mase på utviklerne om at det er feil og at det må rettes opp i, noe han synes er slitsomt. Oskar har heller ikke lyst til å være en masete person, derfor godtar han noen ganger at ting har blitt litt annerledes enn hva han la opp til i skissene.

For Oskar er det et dyptstikkende problem at han ikke har kontroll på hvordan det endelige produktet ser ut og virker: det undergraver hans rolle som designer. Han synes ikke at han må ha kontroll fordi han vil bestemme, men fordi han har et annet perspektiv og en annen faglig kompetanse enn utviklerne som, i hans team, tar siste avgjørelse på hvordan det som settes i produksjon ser ut.

Når det gjelder stand-up’en selv så føler Oskar at det ikke fungerer slik det skal heller. På de daglige møtene går teamet gjennom kanban-tavla, men Oskar opplever det som at hvert teammedlem sier hva de skal gjøre den dagen. Oskar er veldig enig i det Linda Halvorsen skriver i sin artikkel: “boardet handler om produktet vi lager, ikke om teammedlemmenes arbeid”, noe resten av teamet også er enige i. Allikevel så føler han at de ikke helt får det til i praksis. Oskar tror at dette skyldes den dårlige kommunikasjonen som tavlen legger opp til. Siden ingen på teamet vet hva de andre driver med, blir de mer opptatt av hva de selv gjør. Teamet har forsøkt å bryte ut av denne vanen før, men til ingen nytte. Før de vet ordet av det så er de tilbake til å snakke om hva hver og en driver med, i stedet for å snakke om utviklingen til produktet. Teamet til Oskar opplevde at det tok for mye tid å skulle sette alle andre i teamet inn i hva lappen handler om før de snakker om hva statusen på den er.

Finn frem lukespaden

Hva kan Oskar gjøre for å forbedre prosessen til teamet sitt? Her kommer våre tips:

Samle alt på ett board

Det aller første Oskar burde foreslå som endring er å samle alle kolonnene på én tavle. Husk at forutsetningene for å jobbe godt i team, er å tilpasse verktøyet til hvordan teamet vil jobbe, ikke omvendt. Da vil alle i teamet få en bedre oversikt over hvilke deler av produktet som jobbes med og hva de endringene er. Dersom det blir for mange kolonner i tavlen kan teamet dele tavla opp, men da med hensikt om å være produktkø/backlog, som eksemplifisert under. I tavla under ser du også “temaer”, som er ment som en “foreldre/barn”-relasjon (initiativ, “epic”) som kan si noe om fokusområdet for teamet for en gitt periode.

Siden teamet skal jobbe sammen, bør tavla også vise nettopp det. Det betyr at teamet bør kvitte seg med å ha en egen “UX-kolonne” som kun Oskar bruker. Alt arbeid i tavla representerer arbeid med produktet som lages. Alle lappene og oppgavene som skal gjøres er derfor gruppa sitt felles ansvar å få gjort, uavhengig av fagdisiplin. Mange oppgaver er også tverrfaglige, og da må det ikke være et unaturlig skille i tavla på dette.

Alle bør forstå alt

Et tips for å få alle i teamet på samme side, er å beskrive oppgavene som brukerhistorier. Dette tvinger alle i teamet til å formulere en oppgave slik at alle forstår den, også Oskar som er designer. Designer skal ha like stor forståelse for hvorfor noe prioriteres over noe annet i produktet, og det gjør du ikke med mindre oppgavene er beskrevet på en forståelig måte. I tillegg kan en annen fagdisiplin ha svært nyttige bidrag til løsningen som man ellers ikke nødvendigvis ville fått. Alle tekniske oppgaver kan forklares ved bruk av normalt språk – det har bare ikke vært tradisjon for å gjøre det.

som …bruker/den med behovet…

ønsker jeg at ...[en konkret implementasjon som skal gjøres]…

slik at …behov blir oppfylt eller oppgaven til bruker kan gjennomføres…

Produksjon er verdien

Produksjon er ikke bare det vi har laget til nå; det er den verdien vi har skapt, eller forsøker å skape, for brukerne. Det er ikke sikkert det løser riktig behov, men det er det nærmeste forsøket dere har gjort til å realisere verdien. Hvis teamet samles om en felles forståelse for hva som tilfører verdi til brukerne og hva som ikke gjør det, vil det spare Oskar og teamet hans for unødvendig arbeid. Samtidig som det vil gjøre det enklere å jobbe sammen på en mulig løsning, fordi alle blir opptatt av hvilken verdi man oppnår, ikke antallet oppgaver eller størrelsen på løsningen.

Ingenting skal ut i produksjon før teamet er enige

Teamet bør sette klare rutiner for “review”, eller kvalitetssjekk om du vil. Oskar føler at han mister kontrollen på hva som havner i produksjon, mye på grunn av sin rolle som designer. Han har ikke mulighet til å hverken forstå eller påvirke kvaliteten på det som går ut i produksjon hvis han ikke blir involvert. Teamet bør etablere en praksis om at ingen oppgaver som påvirker brukeropplevelsen eller tjenesten utad skal ut i produksjon før Oskar har blitt involvert. Dette er ikke fordi Oskar er sjefen, men han er like mye ansvarlig for verdien som dyttes ut i produksjon. En fantastisk bieffekt er at det forsikrer teamet for store misforståelser og unødvendig opprydding, og den tverrfaglige kompetansen blir benyttet i alle ledd. Det bygger også et bedre team, for folk føler seg involvert. Oskar er jo tross alt der for å sørge for en god og helhetlig brukeropplevelse.

Standup finnes av en grunn.

Standup er en enkel øvelse som har en enkel hensikt: å synliggjøre produktets tilstand for hele teamet. Vi repeterer det Linda Halvorsen sier: “boardet handler om produktet vi lager, ikke om teammedlemmenes arbeid”. Det er ikke alltid teamet trenger eller kan jobbe tett sammen på en oppgave, så daglig standup sørger for å holde teamet samlet rundt ansvar, retning og produksjonsdrift. Teamet bør strebe etter å ha standup (på et eller annet format) hver dag, og så hopper man over oppgaver det ikke har skjedd noe med. Det viktigste er at teamet har oversikt over produktet og hvilken verdi det leverer.

Å jobbe i hagen

Det går ikke an å skrive en slik artikkel og å gi slike tips uten å nevne at det finnes ingen perfekt oppskrift på hvordan et team skal jobbe smidig sammen. Da hadde det ikke vært noe behov for å skrive dette. Dessverre er ingen team, prosesser eller oppskrifter perfekte. Den beste måten et team kan jobbe sammen på avhenger av teammedlemmene, domenet og rammene de jobber med, og produktet de lager sammen. Derfor er det viktigste rådet vi kan gi Oskar og alle dere som leser dette: jobb kontinuerlig med deres egen hage, og finn ugress som kan lukes vekk eller blomster som må vannes.