Mer smidig? del 2: Samarbeid i kryssfunksjonelle team

Vil du bli mer smidig? da er det mange steder man kan starte. Helt sentralt står det å jobbe i kryssfunksjonelle team. Dette innlegget tar for seg dette viktige aspektet

For å lage programvare er det mange ulike faggrupper involvert. Jeg tror alle både bedrifter og team, uansett ståsted i forhold til systemutviklingsmetodikk, kan ha mye å hente på å jobbe mer kryssfunksjonelt. Det gir:

• bedre optimalisering for hele prosessen "from concept to cash"
• mindre work-in-progress
• mindre hand-over
• en bedre forståelse for hva som skal leveres

Dette innlegge handler om hvorfor og hvordan :)


1: Bedre optimalisering av hele prosessen "from concept to cash"
dvs optimalisering for helheten -ikke per fagfelt

Hvis hver faggruppe sitter for seg selv, og leverer for seg selv, blir resultatet at hver faggruppe optimaliserer for sitt fagfelt. Det vi ønsker oss derimot er å optimalisere for at helheten skal løses på en god måte: hele produktet slik som kunden opplever det, og ikke bare en isolert bit. Da sier det seg nesten selv at en optimalisering per fagfelt er en optimalisering på et for lavt nivå. 

Bildet er lånt av Maree Reveley (aka Somerslea)

Løsningen er at folk fra ulike fagdisipliner sitter i kryssfunksjonelle team.Konkret betyr dette at designere, testere, utviklere, database-eksperter og ikke minst forretningssiden/produkteksperter/PM (product management) eller product owner jobber sammen.

Det er en del fagpersoner som synes det er mer effektivt å jobbe sammen med de andre fra sitt eget fagfelt heller enn i kryssfunksjonelle team, og det er ganske naturlig når de tar på seg brillene "mitt perspektiv". Det er viktig å ta på seg "vårt perspektiv" i stedet, hvor "vår" er bedriften, kunden, produktet.

Effektivitet er også et ineressant ord. På engelsk kan det oversettes med to ord som betyr forskjellige ting: 

effective; is sometimes used in a quantitative way, "being very effective or not very effective". However, neither effectiveness, nor effectively, inform about the direction (positive or negative) and the comparison to a standard of the given effect

efficient; on the other hand; is the extent to which a desired effect is achieved; the ability to produce a desired amount of the desired effect, or the success in achieving a given goal

Olve Maudal har brukt analogien med vaskemaskin: effective er å trykke vaskemaskinen helt full, man presser inn den siste sokken og klemmer igjen døra; resultatet blir ikke særlig rene klær, men man får vasket utrolig mye! Efficient blir da heller å sortere ut en passe liten mengde tøy, slik at tøy, vann og såpe kan sørge for et rent og bra resultat.

Jeg tror at ledere må være en kommunikasjons-spydspiss når det gjelder viktigheten av å optimalisere på et høyere nivå enn det mange intuitivt føler som mindre effektivt.Utgangspunktet må være at dette er kunnskap som alle i teamet har. Når denne plattformen er på plass, må lederen være obs på at det kan være ferskvare, og at dette temaet er noe som må taes frem igjen.


2: Mindre work-in-progress (wip)
"Work in progress hides defects, gets obsolete, causes task switching, and delays realization of value." 

-Mary Poppendieck

Dette er en utrolig god oppsummering av hvorfor vi ikke ønsker mye work in progress.

Bildet er lånt av: nrksuper.no

Hvordan redusere mengde work in progress?

• Først og fremst ha alle de fagpersonene som skal til for å utvikle noe i teamet
• Sørge for redundans i teamet (dvs ikke bare èn person fra hvert fagfelt)
• Hindre unødvendige forstyrrelser
• Ha fokus på å redusere wip (ledelse)

Et kryssfunksjonelt team består av de fagpersonene som skal til for å utvikle noe. Dette gjør at teamet kan bli ferdige uten å være avhengig av andre eller vente på andre. Da kan kan ballene landes en etter en :)

Når vi har de fagpersonene som skal til, er det viktig å sikre redundans i teamet. Det vil si at det ikke er bare èn person fra hver faggruppe med. Dette kan være en motsetning til avsnittet over, for teamene kan ikke bli for store heller (ideell størrelse er 7+-2). Det opplagte er at hver person kan gjøre mer enn bare en type oppgave. Men her kommer det an på hvor spesialisert oppgavene er: det er forskjell på en doktor i signalbehandling og en mer generell utvikler.

Uansett hvordan temet blir satt sammen til slutt, er det viktig å hindre unødvendige forstyrrelser. Korte sprinter (på 2 uker) er et bra hjelpemiddel her. Når det kommer en entusiastisk person inn fra sidelinjen og vil at vi bare skal se litt på denne ene tingen her, så er det lett å spørre; vil det ha noen betydning om dette venter til neste sprint? Svaret er stort sett at det er ok, så husk dette viktige spørsmålet!

Det er lettere å si ja enn nei. Men å si nei til noe, er å si ja!! til noe annet. Jeg fokuserer på at det er lurt å si nei til unødvendige forstyrrelser.

Jeg tror også dette med at det er lett å si ja, er en av årsakene til at man ender opp med mye wip. Og det går ikke over av seg selv :)  bevissthet, fokus og teknikker må til for å redusere wip. Her må det en champion, en leder, en smidig-entusiast til, en som kan gå i bresjen og utøve smidig ledelse :) En effektiv teknikk er å sette en grense på antall oppgaver på work in progress (som i Kanban, og kan også gjerne brukes i Scrum).

bildet er lånt av www.modalisa-technology.com

3: Mindre handover; mer kommunikasjon
Pri èn er å få de man trenger til å lage systemet til å jobbe kryssfunksjonelt, men hva med alle de andre som man også trenger for at løsningen skal bli en suksess? De som jobber i andre deler av organisasjonen, som ikke jobber med prosjektet i det daglige, som er mer relevante i ulike faser av prosjektet?

Realiteten er oftest at vi ikke får alle de forskjellige menneskene vi trenger i teamet.(Hw og Sw sitter kanskje ikke i samme team, de som skal supportere, drifte og forvalte løsningen sitter kanskje i en annen del av organisasjonen, hva med marked og salg? hva med selve produksjonssettingen og de som jobber med det? hva med miljø og infrastruktur.... listen kan være lang...)

Bildet er lånt fra: www.goodwilltraining.co.uk

Så, hva kan vi gjøre med dette?

• Behandle alle som trengs for å få levert noe ut til kunden som en del av teamet. Bygg relasjoner! og forståelse for hva dere skal oppnå
• Gjør det du kan for at de du gjerne skulle hatt med på teamet føler seg som en del av teamet (ikke oss/dem, men vi)
• Ta de med på team-eventer, inviter til review, ta formelle og uformelle møter, del ut team-t-skjorter. 
• Ta de med i loopen før du tror du trenger det. 
• Spis lunsj sammen hele teamet, og inviter dem med.

4: En bedre forståelse for hva som skal leveres
"There is nothing so useless as doing efficiently that which should not be done at all."

– Peter Drucker

Godt sagt!!

Heldigvis er det stadig en bedre og bedre forståelse i bransjen for at den viktige forretningssiden må være en del av et systemutviklingsteam til daglig, og ikke bare levere en kravspesifikasjon up front! Dette er et viktig fremskritt!!

Likevel finnes det stadig rom for forbedring. Jeg tror de fleste kjenner seg igjen i at de skulle ønske at forretningssiden var mer til stede og mer involvert. En produkteier som jobber med teamet daglig kan være løsningen. Og hvem kan brukes i denne rollen? I overgangen fra mer tradisjonell vannfallsutvikling til mer smidig metodikk, kan den tradisjonelle prosjektlederen ofte være en god product owner.

Og hva gjør en produkteier? Teamet trenger en som kan forankre visjonen, det strategiske, hva vi skal oppnå/hvilke utfordringer er det som skal løses og for hvem (personas, kundegruppe, markedssegment).

Produkteieren blir en god hjelp for teamet i daglige gjennom:

gode kontakter internt: mot spesialkompetanse som trengs fra forretningssiden.Det kan være at en som er product owner til daglig henter inn for eksempel en aktuar som skal få enkelte beregninger korrekte.

nærhet til kunden: Produkteieren bør ta med seg noen fra teamet og besøke kunder og/eller potensielle kunder for å se med egne øyne hva som gjelder (ta med videokamera, det er lett å ikke få med seg alle detaljene, og det er effektivt å vise til andre)

metodikk: det trjedje viktige perspektivet som produkteiere representerer er en veldig god forståelse av hva som skal til for å utvikle systemer, prøve det ut og justere kursen. En bra bok for å få denne forståelsen er The Lean Startup. 

Nok av spennende utfordringer å ta tak i, ikke sant :)

Spørsmålet blir så: Hvor har du mest å hente?

bildet er lånt fra: lewiscollard.com

 

Mer smidig? del 1: Kort feedback loop

Vil du bli mer smidig? da er det mange steder man kan starte. Helt sentralt står det å ha en så kort feedback loop som mulig:

Kort feedback loop vil jeg påstå at faller seg veldig naturlig for ingeniører! Det er ikke vanskelig å få med seg de flinke fagpersonene som faktisk utvikler systemer på dette, her er det de som går foran og som har gjort det lenge. Selv jeg som ikke lærte test drevet utvikling på skolen, fikk fra første stund tilbakemeldinger fra kompilatoren. Og vi ønsker oss tilbakemeldinger fra testene våre så raskt som mulig. Enhetstester, integrasjonstester og automatiserte funksjonelle tester. Disse kjøres så ofte vi kan, og vi jobber for at vi nettopp kan gjøre dette så tidlig som overhodet mulig.

Tommel opp!

Font Awesome by Dave Gandy

En kort feedback loop, hva betyr egentlig det? Jo det betyr rett og slett at vi ser resultatet av det vi gjør raskt! Og forretningssiden er ofte utolmodige for å få ut sine ideer til sluttbrukerne, sånn sett er det heller ikke vanskelig å selge inn ideen til forretningssiden om at vi skal levere verdi til ekte kunder så raskt som overhode mulig. 

Flere tomler opp!!

Font Awesome by Dave Gandy

Men: Mange ingeniører og forretningsfolk krymper seg likevel når de tenker på å release noe tidlig (når de får tenkt litt på det). For, det er jo ikke ferdig. 

Jeg vil påstå at de aller fleste vil mye å tjene på å virkelig jobbe med å få en kortere feedback loop og muligheter for å release til ekte kunder tidlig.

Picture: Jeff Patton

 Det er nødvendig å jobbe med dette både med medarbeidere som representerer  forretning og teknologi. Og hva får du for å korte ned feedback loopen? Jo du får muligheten til å treffe blink! Og ikke bare det, du treffer også rett blink!! Du får tilbakemelding på hva som virkelig fungerer og ikke, og du får en nærhet til kunden og produktet som faktisk lages som er fantastisk og veldig motiverende. Du får et fokus på de rette tingene, og det gir en enorm motivasjon og fart.

Spørsmålet er hvordan få det til: og svaret på det vil være forskjellig fra bedrift til bedrift og fra team til team. Likevel tenker jeg at dette ofte vil gjelde:

  

·         1: Tester: Hva gjøres i dag? Hva kan gjøres med automatiserte tester? Er det unødvendig overlapp i de automatiserte testene? Kjøres de automatiserte testene ofte nok? Kan det gjøres noe for å kjøre testene med riktige intervaller og å redusere tiden de tar å kjøre? Følger teamet med på testene? Kan teamet stole på testresultatene? Er det riktig nivå av automatisert testdekning?

Jeg har flere ganger fått spørsmålet: tar det ikke uforholdsmessig lang tid å levere et prosjekt dersom man skal lage alle de automatiserte testene? 

Til dette vil jeg helt klart si "nei". (Aller helst "leverer viikke et prosjekt", men en serie av funksjonalitet ved hjelp av hyppige releaser og continous delivery, men dette blir en digresjon akkurat her). 

Automatiserte tester gjør heller det motsatte: vi får mer testing og oftere testing. Dette igjen gjør oss trygge! vi vet at vi ikke brekker noe eller introduserer nye bugs eller regresjoner (ukjente side-effekter ved introduksjon av ny funksjonalitet). 

Hver gang vi gjør endringer i kode som har dårlig test-dekning, da vet vi at dette er risikofylt og  tar ekstra tid. Å skrive selve programmerings-koden tar ikke ekstra tid, men tiden fra vi bestemmer oss for å implementere funksjonalitet til det er klart for produksjon, det er denne tiden som blir lenger, spesielt i kalendertid. Men ikke bare i kalendertid, også i tid for avbrytelser, forstyrrelser og feilsøking i flere uker fremmover etter at endringene er gjort.

·         2: Backlog/Minimum viable product (MVP): Hva er det absoultt minste som det er mulig å få released? Det vil si det tidligste tidspunktet det kan gi bare bittelitt verdi å levere til en ekte sluttkunde? –Dette høres kanskje lett ut, men når svaret kommer, hvordan kan du skrelle bort enda mer? Og enda mer? Og enda mer? Gå gjennom hver eneste feature, og spør deg selv: er dette en showstopper? Ja eller nei? Hvis du bare skulle velge en eneste feature, hva hadde du levert da? En endeløs backlog (eller enda værre: kravspek fra tre år tilbake på tusen sider), er waste.  

·         3: Releaser: Den hele verdikjeden blir først testet ut når vi releaser. 

Mitt store forbilde er Mary Poppendieck, hennes bøker er vel verdt å lese, og jeg har også vært så heldig at jeg har truffet henne flere ganger. Hun har et utrolig godt bilde på hva som skjer ved kort feedback loop: Hvis du ser for deg at prosjektet er et vann eller en elv, så vil det under overflaten være gjemt mye som man ikke ser. Når man releaser ofte senker man vannstanden, slik at problemene kommer til syne, akkurat som steiner under vannet. Jo mer vann man fjerner, jo mer kommer tilsyne av utfordringer, og man kan håndtere dem og skape bedre flyt. (En variant av "å feie noe under teppet")

Bildet er lånt av fotografen: http://kjiver.no/index.htm

Og hvis sluttkunden ikke er interessert i å få en release hver time, hvem er det som er interessert? Begynn med å release til dem! Få en krets av «early adoptors» først internt, deretter eksternt. Kjør alpha og beta programmer. Og hvis det finnes definisjoner internt med kriterier som må oppfylles for å kunne gjøre dette, så finn på noe lurt: kall det for pre-Alpha og pre-Beta. I slike termer kan du legge det du vil (og det skal føles litt ukomfortabelt for alle i prosjektet, dere venner dere til det :)

I realiteten krever dette en hel del. Hvorfor?

Når du senker vannstanden får du rett i fleisen alle de tingene som ikke fungerer. Og alle de tingene som fungerer dårlig. Og alle de tingene som ikke er på plass som burde vært det. Heldigvis får du også alle de tingene som du ikke visste om, som du får mulighet til å gjøre noe med på et veldig tidlig tidspunkt. Alle de andre vanskelige, kjedelige tingene som faktisk var kjent, men ikke løst, var uløste for en grunn og disse årsakene er ikke borte.

På toppen av det hele må prosjektet levere også, ikke bare lage verktøy og fikse tester eller gjøre andre løft for hygienefaktoren. Og det som må til for å kunne release ofte krever en god del å få på plass. Og forretningssiden og alle som har et eierskap til sluttproduktet er ikke så interessert i å forsinke prosjektet, kanskje ønsker dere å være tidlig ute med noe nytt og spennende, eller dere må ta igjen konkurrenter, dere må kapre nye kunder, eller levere det de eksisterende kundene krever. Og utviklerne, de har noen skjelett i skapet som de ikke gleder seg til å ta ut.... 

Så da er det bare å innse at «Rom ikke ble bygget på en dag»:

Bildet er lånt fra: commons.wikimedia.org

Ta de letteste tingene/viktigste først, lage noen milepæler som er realistiske å nå, og ta det videre derfra. Men vær klar over at ingenting skjer av seg selv. Det er som med all endringsledelse. Det krever minst en som driver prosessen, denne må ha en kritisk masse av supportere, teamet eller organisasjonen må kjøpe ideen. Man må være på hugget,  kassere inn de første seirene, og håntere alle setbacks. Og set-backsene vil komme, spesielt siden dette er laget for å synliggjøre alt som er vanskelig, utfordrende og til hinder for hyppige releaser.

Vaner må endres, og teamet (og kanskje bedriften også) må og pushe seg selv ut av komfort-sonen og det som føles som "trygt". Sannheten er at det aller tryggeste man kan gjøre er å release ofte, det gi en mulighet til å omfavne usikkerhet som allerede finnes, og som ikke lenger skyves under teppet. Det er mer komfortabelt å levere noe som er «ferdig». Men det kan man venne seg av med  :)

 

Motivasjon – en enorm kraft!

Jeg -som de fleste av oss, bruker det meste av min våkne tid på jobben. Det er så utrolig viktig å ha en jobb hvor jeg kan gi av meg selv og som gir energi.

Fotograf: Gabriel Pollard

Det er så deilig å gjøre en god jobb! Noe av det som interesserer meg mest her i verden er også hva som nettopp gjør oss motiverte, og da tenker jeg på alle rundt oss. Jeg får som mor se den ufiltrerte, rå og brutale sannheten om hva småtrollene har lyst til og ikke. På jobben er det mer tilslørt av sosiale normer.

Et topp motivert team har det ikke bare gøy, forutsetningene ligger også da mye bedre til rette for å levere fantastiske resultater! Dette tjener alle på, både økonomisk/bedriften og når det gjelder arbeidsmiljø/individet. -Så dette er noe som alle vil ha!! Heldigvis er det også noe alle kan få til! 

Fordi: Motivasjon er ikke noe mysterium:

Bildet er lånt av tlth.se

Det er flere gode stemmer innenfor dette feltet som både fungerer utmerket i praksis og som er forskningsbaserte. Jeg tenker på to som sier mye av det samme: Herzberg  og Daniel Pink.

Herzbergs berømte teori om hygienefaktorer og vekstfaktorer går i korthet ut på at det er en del hygienefaktorer som vil gjøre folk demotiverte dersom de ikke er tilstede eller ikke er tilstrekkelige. Eksempler på hygienefaktorer er lønn, forhold mellom medarbeider og leder, firmabil, status, fysisk arbeidsmiljø. Får du ikke en rettferdig lønn, er sjansen stor for at du blir misfornøyd. Samtidig er det viktigste poenget med hygienefaktorer at folk ikke blir mer motiverte dersom man legger til mer av dem. Mer lønn er derfor ikke det samme som mer motivasjon (hvis lønnen i utgangspunktet er fair). Så hvis det ikke gjelder å pøse på med mer av hygienefaktorene, hva skal vi gjøre da? Svaret ligger i det Hertzberg kaller vekstfaktorer.

Vekstfaktorene ligger på motsatt side av skalaen i forhold til hygienefaktorer. Dette er de virkelige driverne når det gjelder motivasjon, å kjenne entusiasme og energi rundt det man jobber med: utvikling, arbeidet i seg selv, å oppnå resultater, ansvar.

Daniel Pink har skrevet boka «Drive», og det er flere flotte videoer som oppsummerer boka. Se her  og her. Dan Pink snakker om tre faktorer for motivasjon:

Autonomy: å være med og bestemme
 
Autonomy går nettopp ut på å enable hele organisasjonen, og at ikke enkelte ledere tar alle beslutninger. Det er det motsatte av micro-management, og det er det eneste som skalerer. Med Autonomy menes at medarbeiderne både er med på å påvirke hva som skal gjøres, dvs små og store beslutninger som tas på det lavest mulige nivået i organisasjonen, i tillegg til være med å bestemme  måten vi jobber på. I Skandinavia har vi en lang og flott tradisjon for dette, som vi med rette kan være stolt av!

En metafor for å beskrive dette er et hullet og drillen: Som leder er det viktige å beskrive det vi ønsker å oppnå, et reelt behov en kunde har: for eksempel et hull, og ikke hvordan hullet skal lages: for eksempel ved hjelp av en drill.

Bildet er lånt av www.headfi.org

Bildet er lånt fra: http://commons.wikimedia.org
og fotografen er Luigi Zanasi

    Mastery: mulighet til å bli bedre innenfor noe som betyr noe for en selv

Dette passer veldig bra inn i dagens samfunn, som kjennetegnes av en rivende utvikling. Hvor er vi om 50 år? Hva er viktig om 5? Hele adapsjonskurven blir kortere og kortere, noe som betyr at kontinuerlig forbedring og forandring er en forutsetning for suksess. Å lære noe nytt er like viktig for bedriften som helhet som for enkeltmennesket. Å være sulten på ny kunnskap ligger grunnleggende i alle mennesker, og det er viktig å spørre seg selv: hva skal til for å blåse på disse glørne? Hva kan jeg gjøre selv som medarbeider, og hvordan kan jeg som leder legge forholdene til rette?  

Fotograf: Michele Campeotto

     Purpose: være en del av noe større enn seg selv

Sist men ikke minst: Purpose. Det mest motiverende jeg og andre medarbeidere kan jobbe med er nettopp å levere noe som er en del av en større helhet. Selvsagt er ikke alle oppgaver i seg selv like morsomme, men dersom alle i bedriften har et eierskap til visjonen og det sitter i ryggmargen hvor vi skal, så er det utrolig motiverende å være med å bidra til at vi går nettopp i denne retningen!

 

Bildet er lånt fra Wikimedia commons

Soria Moria-bildet gir meg assosiasjoner til å kjenne visjonen, og å finne veien dit. Dette bildet viser  jeg ofte når jeg jobber med teamet for å avgrense et prosjekt og få en skikkelig god felles forståelse av hva visjonen betyr for oss: hva er vår purpose. 

Denne prosessen er spennende, givende, og ikke minst en forutsetning for et high performing team. De små og store beslutningene alle i teamet gjør basert på denne forståelsen er utrolig kraftfull. Jeg ser på felles eierskap av visjonen som den viktigste forutsetningen for både et high performing team og arbeidsglede!