Hva koster en solid avhengighet i disse dager?
Rart spørsmål kanskje, men jeg er sikker på at de som er opptatt av fart og flyt i organisasjoner vil forstå bakgrunnen. Med avhengighet forstår vi ting som vi ikke har kontroll på, som befinner seg bak en et hinder, men som vi er avhengig av for å få fullført en jobb. Blokkeringer.
Det er enkelt å starte på en ny oppgave, men det kan være betydelig vanskeligere å få den avsluttet. Saker som er i arbeid har ingen verdi.
Et velfungerende, tverrfaglig produktteam bør da kunne fullføre det de har startet på? Nei, så lett er det ikke alltid. Selv rutinerte team støter på blokkeringer som gjør at de ikke evner å komme i mål. De må stadig legge saker på vent og i stedet starte på noe annet. Alle som er opptatt av å optimalisere for fart og flyt kan forsøke å minske kostnaden ved disse blokkeringene, og aller helst å fjerne dem helt. Permanent.
Saker som er i arbeid har ingen verdi.
Gevinsten ved å raskt kunne fullføre det vi er i gang med er betydelig. Eller sagt på en annen måte – den kognitive energien som kreves for gjenoppta en oppgave som har ligget på vent i dager/uker er ofte stor. Særlig i store, komplekse organisasjoner vil det ofte være mange innsatsfaktorer utenfor teamets kontroll som må involveres for å kunne fullføre. Omfanget av dette bør kartlegges slik at vi får et reelt bilde av arbeidsflyten til et team.
Vi har vel alle kjent på gleden ved å oppleve flyt i arbeidet, der man glemmer tid og sted, har det som trengs av ressurser og kunnskap, og får avsluttet på en god måte. Slikt fører til arbeidsglede, eierskap og motivasjon. Og ikke minst – det går raskt.
Så, hva er typiske blokkeringer som hindrer arbeidsflyt i team? Her er noen kategorier:
- Mangler kompetanse
- Mangler fullmakt
- Mangler tilgang
- Mangler oversikt
- Omprioriteringer/avbrytelser
Men uansett kategori, hva koster en avhengighet? Jeg tenker det må være en funksjon av
- Varighet – hvor lenge må vi vente?
- Avstand – hvor langt unna befinner løsningen seg?
- Vanskelighetsgrad – hvor kognitivt krevende er den aktuelle oppgaven?
Avhengighetskost = Varighet X Avstand X Vanskelighetsgrad
Varighet
Kostnaden vil være sterkt knyttet til hvor tungt/vanskelig det blir å re-starte oppgaven igjen etter at avhengigheten er fjernet. Dette vil åpenbart ha noe å gjøre med hvor lang tid det tar fra den ble lagt til side, til vi kan starte den på nytt. Jo lengre tid det tar, desto lenger ute av kontekst vil vi være mentalt og desto mer utvisket blir hukommelsen. Enkelte ganger er det like greit å bare glemme den delen av jobben som er fullført og bare starte fra scratch igjen.
Avstand
Kostnaden vil også preges av hvor langt unna løsningen ligger. Hvis vi er nødt til å bevege oss rundt og lete etter løsningen, er det ikke bare å “legge den til side” og vente. Vi må faktisk selv legge ned en del arbeid for å finne ut hvor løsningen befinner seg (hvem vi må snakke med) og noen ganger selv finne løsning. Dette vil være langt mer kostbart enn om vi faktisk vet hvem eller hva vi må vente på, og at vi kan stole på at nødvendige tiltak faktisk blir gjort.
Vanskelighetsgrad
Enkelte oppgaver kan være enkle å ta opp igjen etter å ha ligget på vent en stund (type fullføre reiseregning), mens andre oppgaver vil være betydelig tyngre å komme i gang med (type intrikat programmeringsproblem). Så det er lett å se at vanskelighetsgraden også vil bety mye for hvor vondt det gjør å bli blokkert. I denne drøftingen kan det imidlertid være fornuftig å se på vanskelighetsgrad som iboende, og altså ikke som en variabel. Oppgaven er det den er, og det er de andre parameterne vi kan forsøke å redusere.
Tanken er jo å bruke dette til å angripe de avhengighetene som har høyest kostnad. Det blir fort veldig mange slike, så vi må sette inn støtet der hvor det gir mest verdi. På toppen av dette, så vil vi bruke noe energi på alle «ventesakene» som hoper seg opp ved siden av den vanlige «innkurven». Så formelen mangler egentlig en parameter, nemlig Hyppighet.
Total Avhengighetskost = Varighet X Avstand X Vanskelighetsgrad X Hyppighet
Produktteam som ønsker å redusere avhengighetskostnadene kan loggføre blokkeringene for å få kunnskap om hvilke det vil lønne seg å angripe først. Scrum team vil bruke Sprint-perioden (typisk 2 uker) til dette. Det tar ikke mange uker før man har solid statistikk som gir en viss klarhet i hvilke avhengigheter det vil lønne seg å redusere, eller aller helst fjerne helt.
Fjerne avhengigheter
Når vi jobber iterativt i stabile team vil vi raskt kunne kvantifisere de avhengighetene som gjør mest vondt og så forsøke å fjerne dem permanent. Det bør ikke være nødvendig å godta gjentatte, dyre blokkeringer. Enkelte vil selvsagt være enklere å fjerne enn andre. Det vil være en stor fordel om man har roller som har som oppgave å fjerne hindringer, og gjennom det jobbe med systematisk forbedring. Dette kan være teamleder eller en coach. I Scrum vil det være Scrum Master.
Ifølge Theory of Constraints (ToC) – beskrevet av Goldratt The Goal er det liten vits i å angripe andre flaskehalser enn den som er mest avgjørende; Det er alltid én begrensning som er verdt å redusere, så ut fra den tankegangen blir det viktig å forsøke å kvantifisere blokkeringene og angripe dem i prioritert rekkefølge.
Team med hvert sitt mål, med hver sin (smale) produktdefinisjon. Tykkelsen på streken angir avhengighetskostnaden for det grå teamet.
Eksempler på avhengigheter
Opp gjennom årene som smidigcoach har jeg opplevd mange typer blokkeringer. Her kommer noen “arketyper”.
Ekspertavhengighet. En veldig vanlig situasjon er at det finnes flere nøkkelpersoner rundt om i organisasjonen som er enerådende på et bestemt område. Gjerne flinke folk som har et sterkt eierskap til “sin modul”. Disse enkeltmenneskene blir fort overbelastede og dermed flaskehalser. De som har lest den eminente boka The Phoenix Project vil gjenkjenne karakteren Brent. Hvis et team stadig blir blokkert av å måtte vente på Brent, har vi et systemisk problem (særlig hvis det er flere team som også blokkeres av Brent). Dette må åpenbart eskaleres for å finne en permanent løsning – på en eller annen måte må Brent bruke noe av sin dyrebare kapasitet på å dele kunnskap og ansvar med andre. Det kan selvsagt være verdt å prøve å få personen tettere på (redusere Avstand).
Infrastruktur. Produktteam bør kunne fokusere på å tilfredsstille brukerne på best mulig måte, og da blir det fort ødeleggende for arbeidsflyten om de står på en umoden/uryddig plattform. Det skal være enkelt å lage enhetlig design, få tilgang til data, løse sikkerhetsproblematikk og deploye produktinkrementer etc.. Mao alt som ikke vedkommer selve verdiskapningen. Mange løser dette gjennom at egne platform team eller enabling team som har som oppgave å legge best mulig til rette for at produktteamene ikke blir hindret av infrastrukturproblemer.
Teamavhengighet. Når ett team ikke kommer videre fordi de trenger hjelp av folk i et annet team, vil jo prisen avhenge av hvor rask respons man får. Dette vil i sin tur avhenge av hvor opptatte de aktuelle nøkkelpersonene er, og hvilken prioritet de er villige til å gi. Hvilket i sin tur avhenger av graden av overlappende mål. Hvis det aktuelle teamet er 100% belagt med noe helt annet, må man være forberedt på å måtte vente og kanskje purre flere ganger. Løsningen på dette ligger i enten å bringe teamene nærmere hverandre gjennom mer overlappende mål (redusere Avstand), eller sørge for at teamene har ledig kapasitet (redusere Varighet).
Ledelsesavhengighet. Ofte mangler et team de nødvendige fullmakter for å kunne fullføre sine egne saker. Det kan være (topp)ledelsen eller spesifikke lederroller som utgjør avhengigheten. Ofte folk med en rolle som slutter på -ansvarlig. Arkitektur-ansvarlig, design-ansvarlig, produkt-ansvarlig, release-ansvarlig etc etc.
Organisasjonsdeign for å redusere total avhengighetskost
Vel og bra å fjerne blokkeringer en etter en. Men kanskje det er mulig å fjerne mange i en jafs, gjennom å redesigne organisasjonen? Kanskje organisasjonen rett og slett ikke er designet for flyt?
Hvis vi tenker at de enkelte teamene er passe store, velfungerende og tverrfaglige, blir det åpenbart at det som blokkerer flyten ligger på nivået over det enkelte team. Vi snakker om organisasjonsdesign. Hvor godt samsvarer de problemene som skal løses med måten vi har strukturert teamene, enkeltpersonene og utstyret?
Kanskje organisasjonen rett og slett ikke er designet for flyt?
Hva med å sørge for at de som representerer avhengighetene er tettere på og lettere tilgjengelige? Hva med å forsøke å unngå at det verserer mange ulike målsetninger, produkter og backlogger og heller samle team og folk på det samme produktet og ende opp med bare noen få mål og backlogger?
Team of teams. Tre team som deler en bred produktdefinisjon og kjører mot det samme målet.
Det er fullt mulig å samle flere team som sammen jobber mot det samme målet. Det er fremdeles ulike team med ulike profiler og kapabiliteter, men de blir nå veldig bevisste på at de ikke lykkes alene. De er gjensidig avhengige av hverandre og er bevisste på at når “naboteamet” trenger noe så får de respons raskt. Her kan vi samtidig sørge for at viktige knapphetsressurser som alle teamene trenger er lettere tilgjengelig, enten dette er “smale” eksperter, utstyr eller data.
Forutsetningene for å få dette til å fungere med god flyt er at de tre teamene må ha en del overlapp. Vi må investere i kompetanseflyt mellom teamene, slik at de ikke er altfor spesialiserte.
Er dette interessant, anbefaler jeg å studere LeSS (Large Scale Scrum) som nettopp er laget med tanke på tett samarbeid mellom team med felles mål og backlog. Som en slags bonus – en slik organisasjonsform vil ikke bare optimalisere på flyt, men også på tilpasningsdyktighet. Når organisasjonen må gjøre vesentlige strategiske omprioriteringer, vil en slik omlegging kunne gå enklere. Både den enkelte medarbeider og teamene vil ha en større kompetansemessig bredde og dermed være mer robuste enn team og individer med et smalt fokus.