Fra smidig systemutvikling til storskala digital produktutvikling

«Software is eating the world» — Marc Andreessen.

Den kontinuerlige digitaliseringen av samfunnet fører til økende utbredelse av programvare i stor skala. Systemutviklere møter stadig krav om å levere raskere, nye og endrede forretningskrav, og nye forventninger fra brukerne. De må håndtere usikkerhet, økende kompleksitet, innovasjon og økt endringstakt innen teknologi. Smidige metoder har vist seg godt egnet til å håndtere dette, og er nå den foretrukne tilnærmingen. Hvordan får vi det til i stor skala?

Smidig

Smidig ble introdusert utenfor IT-bransjen på 1930-tallet da W. Shewhart på Bell Labs benyttet PDSA-syklusen for produkt- og prosessforbedring. Han lærte metoden videre til W.E. Demming som introduserte den i Japan og la dermed grunnlaget for Toyota Production System, kjent som Lean. Rugby-metaforen ble tatt i bruk innen produktutvikling og beskrevet av Takeuchi og Nonaka i 1986:

«Stop running the relay race and take up rugby».

Et team leverer som en enhet ved å spille ballen mellom seg, i motsetning til den gamle måten med en stafett der en gruppe spesialister leverer resultatet videre til den neste gruppen. Tilnærmingen kjennetegnes med selvorganiserte og autonome team, organisasjonell læring og mindre planstyring. Flere av disse ideene var grunnlaget for Extreme Programming og Scrum, og i 2001 ble et disruptivt tankesett presentert i form av det smidige manifestet. I den senere tid har metoder som f.eks. DevOps, Lean Startup og Design Sprint kommet til. Smidig har også blitt tatt opp i ledelse og organisering, og omtales da ofte som agilt lederskap og agile organisasjoner.

Storskala smidig

«Agile Is Eating The World» — Steve Denning.

Skalering av metodene og praksisene ble lenge problematisert siden det smidige manifestet og metodene ikke spesifikt omtaler mekanismer for inter-team koordinering eller skalering. De benytter også koordineringsmekanismer som er veldig forskjellig fra dem i tradisjonelle plandrevne metoder. Skalering medfører større behov for koordinering, prioriteringer, håndtering av avhengigheter, synkronisering og koordinering mellom teamene og med andre organisasjonsenheter. Smidig skalerer ikke — var mantraet. Denne holdningen endret seg i 2018 når smidig skalerte opp og ut over systemutvikling — mye takket være disse to:

Metodene blir nå fremmet som innovasjonsmetoder for virksomheter, og er benyttet i nye, store virksomheter som er grunnlagt i den digitale økonomien f.eks. Facebook, Amazon og Spotify. De kjennetegnes ved at de leverer ny funksjonalitet som produksjonssettes flere hundre ganger om dagen. Store virksomheter som f.eks. Barclay, Ericsson og ING har gjennomført vellykkede smidige transformasjoner i stor skala. Metodene har etterhvert blitt tatt i bruk i stor skala også i norske virksomheter som f.eks. Finn, NAV og Skatteetaten. De er nå ansett som vesentlige for å gjennomføre vellykkede digitale transformasjoner.

Storskala smidig er så 2018!

Utfordringene ved skalering er ikke noe nytt. F. Brooks sier i sin kjente artikkel fra 1987 — «No Silver Bullet»:

«… programvaresystemer er noe av det mest komplekse mennesker bygger … en skalering av en programvareenhet er ikke bare en gjentagelse av de samme elementene i større størrelser, det er nødvendigvis en økning i antall forskjellige elementer. I de fleste tilfeller interagerer elementene med hverandre på en ikke lineær måte, og kompleksiteten i helheten øker mye mer enn lineært.».

Når man skalerer oppstår det nye problemstillinger rundt f.eks. ledelse, styring, kultur, finansiering, organisering, koordinering og kompetanseoverføring. Vi skal se litt på en av de viktigste — koordinering.

Koordinering

En av de sentrale utfordringene ved skalering er koordinering av arbeidet, og den er ikke unik for smidig:

«… en viktig årsak er problemet med å koordinere aktiviteter … Vi argumenterer for at koordinering blir mye vanskeligere når prosjektstørrelsen og kompleksiteten øker» — Kraut og Streeter.

Organisasjonsteoretikere har studert koordinering i organisasjoner, gjensidige avhengigheter i organisasjoner, mellom team, og mellom ulike aktører i og utenfor virksomheter. De beskriver ofte koordinering som noe overordnet som håndteres med strukturer, roller og gjensidig tilpasning. Van de Ven et al. (1976) har utarbeidet en mer detaljert teori.

Ved en økning av oppgavens usikkerhet (arbeidets vanskelighetsgrad og variasjon) i en enhet, øker koordinering i horisontale kommunikasjonskanaler (direkte mellom teammedlemmene) og gruppemodus (faste og uplanlagte møter) betydelig. Disse mekanismene erstatter vertikal hierarkisk koordinering (via leder) og upersonlig koordinering (planer, prognoser, regler og prosedyrer), og upersonlig koordinering avtar betydelig.

Når arbeidsflytens avhengigheter (fra uavhengig, via sekvensiell, innbyrdes avhengigheter, til team) mellom oppgavene øker, øker koordinering i gruppemodus betydelig og spesielt planlagte møter. Upersonlige og personlige koordineringsmekanismer (ved roller eller direkte) forblir konstant i forhold, og det er mer samlet bruk av alle koordineringsmekanismer.

Når arbeidsenhetens størrelse øker, øker bruken av upersonlige koordinerings og vertikal koordinering. Bruken av horisontale kanaler og gruppemodus forblir konstant. Deres undersøkelse viste den upersonlige økningen ved enheter med over 10 medlemmer. Koordineringskostnaden er knyttet til mengden upersonlig kommunikasjon mellom gruppedeltakere er lavere når upersonlig koordinering benyttes, og høyere når horisontale kanaler og gruppemodus benyttes.

Storskala smidig koordinering

Erfaringer og studier bekrefter at Van de Ven et al. sin teori også gjelder for storskala smidig og de mest benyttede koordineringsmekanismene er gruppemodus ved flere ulike typer faste og ikke planlagte møter. Men også horisontal koordinering ved bruk av meldingssystem, uformell koordinering mellom teamlederne, og samlokalisering er viktig for å fasilitere ad-hoc horisontal koordinering. Studier av f.eks. SPK, NAV og SVV bekrefter teorien om at ved økning i oppgavens usikkerhet og avhengigheter så øker koordineringsaktiviteten og spesielt gruppemodus i form av faste møter også i storskala smidig systemutvikling. Noen studier viser også at kordineringsmekanismene endres over tid når store initiativer tilpasser metodene og erfarer hva som virker for dem.

Smidige metoder og praksiser må utvides og tilpasses med mekanismer for å håndtere inter-team skalering ved skalering. En metode er å benytte Scrum of Scrum som koordineringsmekanisme mellom team, men det har vist seg å ikke være tilstrekkelig. Erfaringer og flere av studiene har rapportert om vellykkede bruk av smidig systemutvikling i stor skala som kjennetegnes med bruk av en rekke ulike koordineringsmekanismer samtidig som f.eks. demoer, meldingssystem, wiki, samlokalisering i åpent kontorlandskap, fellesmøter, statusmøter, ulike fora, spesialiserte møter, Scrum og Scrum, uformelle samtaler og smidige praksiser (stand-up, sprint, backlog etc.) godt støttet av gode verktøy som f.eks. Trello, Miro og Jira.

De upersonlige koordineringsmekanismene som benyttes er i all hovedsak smidige praksiser for nedbryting og beskrivelse av oppgaver. Slike praksiser fasiliterer inter-team koordinering og kommunikasjon, og kjennetegnes av å være skisser og overordene beskrivelser og ikke planer, prosedyrer eller rutiner som omtalt i klassisk organisasjonsteori og benyttet i tradisjonell prosjektstyring. Tilsvarende vil vertikal koordinering være mindre viktig i smidig systemutvikling pga. bortfallet av tradisjonelle planer, regler og rutiner. De blir erstattet av koordinering vha. smidige praksiser, og inter-team koordinering ved utstrakt møtevirksomhet.

Faggrupper (Communities of Practices/Guilds) er en praksis for å dele og utvikle kompetanse, men kan også fasilitere generell koordinering og koordinering av ekspertise. De benyttes ofte i storskala smidig systemutvikling. F.eks. benytter Ericsson og Spotify faggrupper og smidige coacher (gått mer bort fra bruk av coacher i den senere tid) for å koordinere arbeidet mellom flere hundre utviklere. Spotify har bygd opp en matriseorganisasjon med Squads, Tribes og Chapter der teamene er kryssfunksjonelle, autonome og samlokaliserte. Organisasjonen og arkitekturen er designet med færrest mulige avhengigheter mellom teamene, og arbeidet koordineres med hyppige møter. Denne modellen har blitt adoptert av flere virksomheter som f.eks. ING og i lokale finansvirksomheter.

Arkitektur

Det har etterhvert blitt større bevissthet rundt at arkitektur også er en koordineringsmekanisme. Arkitektur kan være en mekanisme for å dele opp arbeidet i områder, prosjekter, eller uavhengige delsystemer for å redusere avhengigheter. Spesielt mikrotjenestearkitektur kan benyttes for å effektivisere koordinering.

«Conway’s law» forteller at organisasjoner er tilbørlig til å utvikle design som er kopi av kommunikasjonsstrukturene i organisasjonen. For å motvirke denne loven og redusere behovet for koordinering kan arkitekturen bygges opp av løst koblede mikrotjenester med klare grensesnitt (API-First). Dette prinsippet kalles «reverse Conway’s law» for å redusere avhengigheter og muliggjøre økt team autonomi.

Mange benytter det som kallens «reverse Conway’s Law» — å utvikle arkitekturen rundt domenegrenser for å sikre at teamet kan få utført sitt arbeid — fra design til produksjonssetting — uten at det krever mye kommunikasjon mellom teamene. En slik arkitektur bidrar til å redusere behovet for inter-team koordinering som erfaring og studier viser kan bli en stor utfordring når teamene har høy grad av selvstyre og autonomitet. Dette er en av teknikkene for å etablere kontinuerlig systemutvikling. Den muliggjør kontinuerlig deployment til produksjon og letter håndtering av endringer i isolasjon. Ifølge DevOps Report er teknikken sammen med velfungerende team den viktigste forutsetningen for kontinuerlige leveranser, og kjennetegner de organisasjonene som er lengst fremme.

Organisering

Smidig systemutvikling gjennomføres med kryssfunksjonelle og selvorganiserende team der forretningssiden og utviklerne arbeider sammen. Ofte har dette vært begrenset til en produkteier, noe design og utviklere i et team på 5–7 medlemmer. Ekte kryssfunksjonelle produktteam, eller BizDev team, vil medføre at teamene øker noe i størrelse. En slik utviklingen vil kreve dyktigere teamledere, og vil øke behovet for de mindre kostnadskrevde koordineringsmekanismene hierarkisk og upersonlig. Større team vil redusere inter-team koordineringsbehovet og antall møter noe. Som noen studier viser kan man også etterhvert fjerne noen faste møter for å redusere koordineringskostnaden, og erstatte dem med ad-hoc møter. Organisasjoner bør også prioritere de smidige praksisene og teknikkene som håndterer flest avhengigheter samtidig for å redusere koordineringskostnaden.

Tradisjonelle organisasjoner er ofte organisert funksjonelt. Flere virksomheter som har bygget opp sine digitale organisasjoner, organiserer dem i ulike produktområder som igjen kan bestå av flere team. De designes med eierskap til ulike komponenter og domeneområder for å redusere avhengigheter mellom teamene. Teamene kan organiseres per domeneområde eller produktområde. Produktområdene og teamene styres ofte ved bruk av en produktvisjon, strategi, målbilder, OKR, prinsipper og verdier, og ikke tradisjonell målstyring, planer, prosedyrer eller regler.

På denne måten kan organisasjonsdesign og arkitektur bidra til å redusere avhengighetene og behovet for koordinering ved skalering. Teamene og arkitekturen er bevisst designet med løse koblinger for å redusere avhengigheter. Disse to teknikkene må benyttes samtidig og kontinuerlig tilpasses over tid. Skatteplanleggere har lenge snakket om Double Irish for å redusere skatten av overskudd i utlandet. Kanskje vi i IT burde snakke om Double Conway:

Organisasjonen og arkitekturen designes samtidig med løse koblinger for å redusere avhengigheter og behovet for koordinering.

Storskala smidig systemutvikling kan følge prinsippene for smidig systemutvikling og benytte metodene og praksisene, men siden metoder ikke omtaler skalering og inter-team koordinering må man i tillegg benytte andre praksiser. Bla. kjennetegnes storskala smidig av omfattende horisontal koordinering og koordinering i gruppemodus med statusmøter, andre fellesmøter, demo og spesialiserte møter.

Vi «agelistas» må ta inn over oss at vi har noe å lære fra andre fagfelt som produktutvikling, organisasjonsteori og arkitektur, og ta deres praksiser i bruk for å skalere og utvikle oss.

What’s next

Organisasjonen bør designes både for å utforske nye muligheter til utvikling av nye tjenester og nye aktører, samtidig som den skal utvikle og videreutvikle eksisterende tjenester — ambidekstri. For å få til innovasjon må kunnskap deles og overføres mellom team og produktområder, kan man benytte grensekryssing mellom team og kunnskapsmegling ut mot andre enheter, men mer om dette neste gang.

I tillegg til å skalere smidig i stor skala må man også integrere med eksisterende prosesser og problemstillinger på tvers av virksomheten. Tradisjonell hierarkisk ledelse, interne siloer og organisasjonsgrenser er vanskelig å krysse. Man har behov for å ta i bruk andre praksiser og mekanismer i tillegg til de som smidige metoder tilbyr, men grunnlaget er kryssfunksjonelle produktteam eller BizDev-team.

Endringsmotstanden kommer ofte fra ledelsen siden det smidige tankesettet og teknikkene er fremmed for dem, og at lederens tradisjonelle rolle endres til en mer tjenerorientert leder. For å lykkes med en digital transformasjon må man utvikle en mer smidig ledelse. Den smidige tankegangen og kulturen må nå ut til ledelsen, og den største utfordringen er å endre tankesettet fra tradisjonell ledelse. Teamarbeide og storskala smidig er ikke lett, og det er derfor viktig å tilby opplæring og coaching til teamene og ledelsen. Smidig faggrupper kan benyttes for å øke kompetansen om smidig utover produktutviklingen og ut i hele virksomheten. På den måten kan vi bidra til den digitale transformasjonen. Det å ta i bruk et rammeverk for storskala smidig eller å benytte andres modell løser neppe utfordringene.

Den digitale produktutviklingen bør ta en holistisk Lean-basert tilnærming med fokus på ende-til-ende flyt og kontinuerlige forbedring. Da kan man ta steget fra prosjekttilnærmingen for utvikling til en kontinuerlig storskala smidig systemutvikling.

Prosjekttankegangen er ikke bærekraftig — verken i storskala smidig systemutvikling eller i digitale transformasjoner — digitaliseringen går ikke over.

Ved å bygge på våre gode erfaringer med smidige metoder, kan man innføre en kontinuerlig produktutvikling i autonome team i stor skala som et grunnlag for en plattformtilnærming. En slik digital produktorganisasjon vil kunne være grunnlaget for fremtidige digitale tjenester i et plattformbasert økosystem der også eksterne aktører kan delta — åpen innovasjon. Det er ikke et spørsmål om ambidekstri med en smidig eller tradisjonell tilnærming til systemutvikling, eller en storskala smidig systemutvikling, men en plattformtilnærming med smidige innovasjonsprosesser for å skape nettverkseffekter.

Referanser:

Brooks, F. (1987) — No Silver Bullet. Essence and Accidents of Software Engineering.

Dingsøyr, T. et al. (2018) — Exploring software development at the very large scale.

Dingsøyr, T. et al. (2018) — Coordinating Knowledge Work in Multi-Team Programs.

Ebert, C. & Paasivaara, M. (2017) — Scaling Agile.

Fitzgerald, B. & Stol, K.-J. (2015) — Continuous software engineering.

Gundelsby J.H (2018) — How architecture enables team autonomy.

Kraut, R. E. & Streeter, L. A. (1995) — Coordination in software development.

Løvold A. (2017) — Fra Smidig til DevOps til Kontinuerlig Produktutvikling i Autonome Team?

Mintzberg, H. (1980) — Structure in 5’s: A Synthesis of the Research on Organization Design.

Paasivaara, M. & Lassenius, C. (2014) — Communities of practice in a large distributed agile software development organization.

Paasivaara, M. et al. (2012) — Inter-team coordination in large-scale globally distributed scrum: Do scrum-of-scrums really work?

Raisch, S. et al. (2009) — Organizational ambidexterity: Balancing exploitation and exploration for sustained performance.

Rolland, K. et al. (2016) — Problematizing Agile in the Large: Alternative Assumptions for Large-Scale Agile Development

Takeuchi, H. & Nonaka, I. (1986) — The New Product Development Game.

Van De Ven, A. H. et al. (1976) — Determinants of coordination modes within organizations.