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 | |
This is the tram close to where I live. It leaves every 7th minute. It started departing with this frequency last year (down from 15 minutes), and it resulted in several changes:
