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  :)