Månedlige arkiver: juni 2021

Hva er en digital transformasjon?

Postet den av
3

Et stort spørsmål med flere svar, som er avhengig av perspektivet til den du spør. Mitt utgangspunkt er dette: Digitalisering er transformasjonen fra at IT er et støtteverktøy i virksomheten til at det blir en del av dens DNA. Det betyr at forretningsmodell og -praksis samt organisasjon og prosesser er designet for å utnytte dagens og morgendagens teknologi. Denne definisjonen er utdypet i posten IT-lederens nye rolle.

Illustrasjonsfoto av Javier Allegue Barros på Unsplash

Tverrfaglige team

Det er lurt å bruke flere perspektiver, for da kan vi belyse problemstillingen fra ulike sider. Spesielt når omgivelsene er omskiftelige og behovet for smidighet og korte beslutningsveier er stort. En faktabasert diskusjon mellom kompetente personer med ulike perspektiver er verdifullt, og hovedbegrunnelsen for å sette sammen tverrfaglige team. De benevnes også som kryssfunksjonelle team – fordi teamene løser komplekse oppgaver med sammensatt kompetanse. Det er som regel slik vi finner de beste løsningene – sammen.

Kanskje er bruk av kryssfunksjonelle team det viktigste enkeltgrepet som kan gjøres for å fremme innovasjon og håndtere kompleksitet i egen virksomhet.

Bruk av kryssfunksjonelle team åpner også for å ta inn konsulenter som kan tilføre ekstern kompetanse. Slik kommer jeg inn som rådgiver og sparringspartner for ledere hos kundene våre.

Jeg tror ikke det fins noen «silver bullet» for hvordan en transformasjon bør utføres, for det kommer helt an på virksomheten og konteksten den befinner seg i. Derfor er mitt råd å styre unna alle dem som tilbyr lettvinte løsninger og «quick fix» på komplekse problemstillinger. Jeg tror mer på analytisk problemløsning, sunn fornuft og prinsippene for smidig utvikling – som du kan lese mer om i posten smidig tilnærming til utfordrende prosjekter.

Lederskap

Transformasjon er en omfattende endring som medfører stor usikkerhet, for både eiere, ledere og medarbeidere. Derfor trengs det godt lederskap og styring. Lederskap er personorientert og styring er systemorientert.

Lederskap bidrar til å angi retning, skape endring og sette mål. For meg betyr ledelse å gå først, og handler om å ivareta medarbeidere, det sosiale og mellommenneskelige forhold.

Styring er påvirkning som utøves indirekte blant annet gjennom formelle strukturer, formaliserte prosedyrer, rutiner og kontrollfunksjoner.

Begge deler er nødvendig for å få ønsket effekt. Det er ofte her jeg kommer inn som rådgiver, når en leder trenger en sparringspartner.

I Forsvaret lærte jeg at ledelse handler om to grunnleggende ting; å løse oppdraget og ta vare på folkene sine. I en digital transformasjon er oppdraget som regel gitt av eierne, representert ved styret, til daglig leder: Gjennomfør forretningsstrategien og digitaliser det som er mulig for en bedre måloppnåelse. Ofte er det mål for produksjon, vekst, lønnsomhet, bærekraft, kundetilfredshet, medarbeidertilfredshet, omdømme, og/eller samfunnsoppdrag. Les gjerne mer om daglig leders rolle i en transformasjon fra en tidligere post.

Strategi

Digitalisering er ikke et mål, men et middel for å styrke kjernevirksomheten og bygge evne til å skape verdi i framtiden. Det krever en forståelse av hvordan verdier skapes i dag og hvordan teknologi kan utnyttes for å skape verdi på en bedre, raskere, billigere eller sikrere måte. For å få det til, må vi utfordre måten vi tenker på. Det kan du lese mer om i posten strategiprosess til besvær.

Det jeg ser, er at de fleste virksomhetene har startet digitalisering, men mangler en god tilnærming og plan for hvordan digitaliseringen skal forbedre måloppnåelsen av kjernevirksomheten. Det kan du lese mer om i posten hva er en digital strategi?

Jeg har lært at strategiutvikling og -gjennomføring er like viktig som selve strategien. Fordi omgivelsene og forutsetningene endres stadig raskere, må de som gjennomfører strategien forstå intensjonen, og ha nødvendig handlefrihet til å løse oppdraget. Gjennom frihet til å nå målene, vil medarbeiderne søke etter nye og bedre måter å løse oppdrag på. Derfor er delegering av myndighet viktig.

Men frihet betyr ikke uten styring og at alle kan gjøre hva de vil. Det må være en struktur som sikrer felles forståelse av målet, hva som skal oppnås og hvorfor.

I en transformasjon kalles denne strukturen virksomhetsarkitektur, og gir daglig leder mulighet til å manøvrere endringer i organisasjon, prosesser og IT-løsninger på en helhetlig måte som understøtter strategien. Målet er å skape en integrert og samordnet virksomhetsarkitektur som muliggjør innovasjon. Det betyr at forretningsmodell og -praksis samt organisasjon og prosesser er designet for å utnytte dagens og morgendagens teknologi.

Arkitektur

Problemet oppstår når strategien skal omsettes til praktisk handling, og kompleksiteten i prosesser, teknologi og organisasjon trer fram. Virksomhetsarkitektur er en strukturert metodikk for å identifisere hvilke endringer som må gjennomføres for å nå forretningsmålene. Det handler om å forstå hvordan virksomheten er satt sammen, og deretter dele oppgaven med å endre den i håndterbare deler. Nesten som legoklosser.

Enkelhet er et viktig prinsipp: Å ikke dokumentere mer arkitektur enn nødvendig – men nok til å ta informerte beslutninger – er essensielt. Til det kreves evne til å prioritere hva som skal dokumenteres og holde dokumentasjonen oppdatert. Det er utfordrende for mange.

Arkitekturen kan deles inn i flere lag (forretning, informasjon, applikasjon, og teknologi). Sikkerhetsarkitektur og arkitekturstyring er gjennomgående for alle lagene, og sørger for at de henger sammen.

Sammenheng mellom strategi, virksomhetsarkitektur og løsningsarkitektur

Virksomhetsarkitektur beskriver hvordan en virksomhet er organisert, hvordan arbeidsprosesser er satt sammen og hvordan IT-løsninger utnyttes for å produsere verdi. Virksomhetsarkitektur er tett koblet til strategi gjennom mål og målbilder.

Løsningsarkitektur beskriver hvordan applikasjoner sikrer effektiv informasjonsdeling mellom mennesker og maskiner. IT-løsningene er som regel laget av forskjellige leverandører. Som konsekvens oppstår to utfordringer: Teknisk gjeld og deling av data mellom applikasjoner.

Teknisk gjeld

Teknisk gjeld er en metafor som fungerer godt til å forklare strategiske konsekvenser av ulike valg i anskaffelse og utvikling av IT-løsninger. Over tid vil manglende forståelse av slike konsekvenser resultere i operasjonelle utfordringer som hindrer effektiv måloppnåelse av strategiske mål.

Problemet med teknisk gjeld er at det påløper renter – som må betales før eller siden. Problemet vokser med tiden som effekt av renters rente. Teknisk gjeld kan defineres som alt det uferdige, unødvendig kompliserte og utdaterte i IT-løsningen som hindrer oss i å drifte, forvalte og videreutvikle så effektivt som vi ellers kunne gjort.

Derfor kan det lønne seg å se nærmere på hva teknisk gjeld er, og forstå hvordan den kan håndteres. Det er utdypet i posten hva er teknisk gjeld?

Deling av data

I dag har vi egne IT-løsninger for HR, lønn, regnskap, fakturering, kundeoppfølging (CRM) og produksjon (ERP). Som ikke snakker med hverandre. Derfor registreres samme data, flere ganger, i forskjellige systemer. Enten gjennom manuell inntasting, eller overføring av filer på diskett eller minnepinne. Så nytteverdien av å koble sammen applikasjoner som brukes internt i en virksomhet synes åpenbar.

Men det virkelig store potensialet ligger i å gå ett skritt videre; å koble data fra applikasjoner som befinner seg utenfor egen virksomhet. Dette gjøres gjennom standardiserte grensesnitt; Application Programming Interface (API).

Forutsetningen er god informasjonssikkerhet og tilgangskontroll. For når du åpner en inngangsport (API Gateway) til dine data, trenger du å ha stålkontroll på hvem som får tilgang til hva, og hvilke rettigheter de skal ha for å opprette, lese, oppdatere eller slette data. Dette er utdypet og forklart i posten hva er et API?

Oppsummering

Mitt perspektiv, og svar på spørsmålet i overskriften, kan oppsummeres slik:

Digital transformasjon – er en aktiv respons og endringsprosess – for å gripe muligheter og unngå trusler – som oppstår som konsekvens av endringer i rammebetingelser – som følge av at digitalisering forskyver/forstyrrer/ødelegger maktballansen i markedet og samfunnet.

For meg er en digital transformasjon:

  • Teknologidrevet – ved at IT går fra støttehjul til drivhjul for virksomheten
  • Datadrevet – gjennom kontinuerlig læring og forbedring basert på målbare data
  • Strukturering – ved å samordne og integrere prosesser, systemer og infrastruktur som muliggjør innovasjon
  • Nytenkning – ved å kontinuerlig søke etter nye måter å skape verdi på for kundene, seg selv og samfunnet
  • Endringsevne – ved å tilrettelegge for kompetente, kryssfunksjonelle team som kan snu seg raskt i en smidig organisasjon
  • Lederskap – gjennom å gå først, vise vei og bemyndige medarbeidere slik at de kan bidra til å opprettholde en stadig økende endringstakt

Neste post vil komme etter sommerferien, en gang i august.

Ha en riktig god sommer!

Innovasjon i praksis

Postet den av
2

Begrep som «Design Thinking», «Lean Start-up» og «Agile» benyttes ofte i forbindelse med innovasjonsprosesser. Det er lett å bli forvirret av begrepsbruken, og spørsmålet mange stiller er: Hva betyr det i praksis, og hvordan henger de sammen? For å svare på det, utførte jeg et eksperiment – for å gjøre det praktisk og enkelt å forklare.

Utfordringen som søkes løst, er å kunne hvile samtidig som man fører en seilbåt. Problemet er at benken bak rattet er for lav i forhold til overbygget lengre frem, som medfører at sikten forsvinner når man setter seg ned.

Innovasjonsprosessen

Hensikten med en innovasjonsprosess er å komme raskt i gang med datadrevet produktutvikling for å bygge løsninger som kan testes og gi verdi etter kort tid. Jeg benytter Sopra Sterias innovasjonsprosess, som er basert på tankegodset fra Design Thinking, Lean Start-up og Agile (Smidig på norsk), i den rekkefølgen. Det kommer jeg tilbake til.

Sopra Sterias innovasjonsprosess Lean Next – Del 1

Definer mål

Vi starter med å definere mål, som i henhold til Design Thinking skal være:

  • Attraktivt (Desirable) (D)
  • Gjennomførbart (Feasable) (F)
  • Levedyktig (Viable) (V)

Det er skjæringspunktet mellom disse egenskapene vi er på jakt etter. Å kjøpe ny båt er ikke levedyktig (for dyrt), så vi går for å utvikle et sete som ikke sklir når vi seiler. Målet blir derfor at setet skal se bra ut, være enkelt å feste til rekken, og lar seg bygge av materialer som tåler fuktighet. Kostnadene skal holdes lave.

Generell utfordring

Innsikt/empati fasen handler om at vi «bredder ut» vår forståelse av problemet som søkes løst. Det symboliseres med (<) i modellen. Vi søker alle gode innspill som kan belyse den generelle problemstillingen. Dette er «ja-fasen» hvor alle ideer ønskes velkommen. Vi lager en brutto-liste over mulige problemstillinger som kan være relevant innen rammene av de definerte målene. Er beskyttelse mot regnvær kanskje en mer aktuell problemstilling? Hva med sikkerhet, navigasjon, og god stemning om bord? Vi oppdaterer om nødvendig målene dersom vi kommer på noe nytt.

I defineringsfasen «snevrer vi inn» brutto-listen over problemstillinger, som er symbolisert med (>) i figuren. Til sammen blir symbolene <>, en diamant. Det vi egentlig søker svar på er dette sentrale spørsmålet: «Er problemet stort/viktig nok til at det er verdt å løse?» For eksempel kan bruk av autopilot medføre at båtføreren kan sette seg et annet sted med sikt forover. Men autopilot krever strøm og kan ikke brukes over lange strekk, for da blir batteriet tomt. I tillegg er det mange båter som ikke har autopilot.

Vi oppsummerer med å utvikle hypotese 1: Dette er et problem som er verdt å løse.

Så vi går videre i prosessen.

Spesifikk utfordring

«Hvordan kan båtfører holde i rattet og samtidig sitte avslappet med god sikt forover?»

Igjen «bredder vi ut» gjennom en idéstorming, symbolisert med (<). Vi er på jakt etter å løse dette spesifikke problemet. Dette er «ja-fasen» hvor alle ideer er velkomne. Er det en stol? Hva er den laget av? Hvor stor skal den være? Hvor skal den plasseres? Hvordan skal den festes? Kan den flyttes?

Vi oppsummerer med å utvikle hypotese 2: En båtførerstol er den beste løsningen på vår problemstilling.

Prototypen lages for å skaffe oss data som gir svar på de nevnte spørsmålene. For å komme hit, har vi brukt en «dobbel diamant», fordi prosessen med å åpne og lukke har form som en diamant. Dobbel siden vi har gjort det to ganger- <> <> – Den første diamanten handler om problemet er viktig nok, og den andre diamanten om hvilket løsningskonsept (av flere mulige) som anses å være best egnet.

På bildet ser dere prototypen jeg laget til vårt formål i forgrunnen. Legg merke til festeanordning for å kunne hekte stolen fast på rekka. (I bakgrunnen kan dere også se to andre prototyper til blomsterkasse på hjul, som jeg også sysler med. Det er ellers helt vanlig å jobbe med flere prototyper samtidig)

Prototype til båtførerstol

Løsningskonsept

Nå bruker vi «Bygge – Måle – Lære» metodikken fra Lean Start-up. Vi skal teste prototypen i det miljøet den skal være i, på en ekte båt, som i dette tilfellet er vår egen.

Vi regner med å gjøre tilpasninger, så vi trenger å ta med oss nødvendig verktøy til båten.

Prototypen tilpasses miljøet den skal brukes i

Det første jeg ser når stolen kommer ombord, er at den er rett og slett for stor. Selv om den får plass, hindrer stolen bevegelse til og fra førerplassen. Jeg hadde tatt mål av tilgjengelig plass, men tenkte ikke på at vi skal bevege oss rundt i båten uten hindring av stolen. Derfor må sagen frem, og lengden kuttes med et helt bord. Siden jeg har bygget prototypen selv, vet jeg at det enkleste er å løsne skruene i bakkant på setet og kapper bærebjelkene i ønsket lengde. Så skrus setet fast i ryggen igjen.

Lengden er redusert for bedre fremkommelighet

Det neste jeg observerer er at stolen er for høy i forhold til rekken på båten. Dermed må beina kuttes. Fram med meterstokk, ta mål, tegne rett line og sage etter den.

Høyden må justeres

Så observerer jeg at stolen kan skli sideveis langs rekken. For hindre at stolen sklir under seiling, velger jeg å flytte et tverrgående bord under setet, og sage en åpning som passer til den vertikale delen av rekka. Bordet jeg bruker må også kappes i bredden, siden stolryggen blir smalere, jo lengre opp en kommer.

Flytter et bord slik at det hindrer glidning under seiling

Nå er det på tide med en brukertest, som jeg utfører selv. Testresultatene er lovende. Stolen sitter fast og er ikke til hinder for bevegelse rundt om i båten. Sikten forover er god, og rattet nås fint med den ene hånden.

Akseptansetest av løsning. Resultat: Godkjent.

Vi har nå en fungerende prototype av en båtførerstol som kan videreutvikles og eventuelt produseres i et større antall. Dermed er vi klare for neste fase, som handler om å stabilisere løsningen og skalere opp ved behov. Til dette benytter vi «Agile» eller Smidig på norsk.

Sopra Sterias innovasjonsprosess Lean Next – Del 2

En viktig del av smidig produktutvikling er produktkøen, som er en totalliste over behov for ny funksjonalitet, skalering og stabilisering. (Symbolisert med en stabel av behov, til venstre i figuren). Produktet utvikles i sprinter med varighet 1-4 uker. En sprint planlegges av et produkt-team som prioriterer hvilke oppgaver som skal utvikles. Hver sprint avsluttes med en demonstrasjon av hva som er laget, og det gjennomføres en læringssløyfe kalt retrospektiv ved jevne mellomrom. Vi benytter «Bygge – Måle – Lære» i kombinasjon med «Idé – Produkt – Data» for videreutvikling i gjentagende øvelser.

Poenget er å ta vare på all læring for å kontinuerlig forbedre og videreutvikle produktet. Det er her DevOps kommer inn, et ord som er sammensatt av «Development» (utvikling) og «Operations» (drift). Konseptet går ut på å ta vare på opparbeidet innsikt i en kontinuerlig læringssløyfe mellom utvikling og drift. I motsetning til prosjekter som overleveres fra utvikling til drift hvor innsikten går tapt i overleveringen.

Vårt produkt er ikke en digital løsning, men det kan likevel videreutvikles på flere måter. For eksempel pusset jeg over med sandpapir for å jevne harde kanter. Så bør den males i en farge som passer båten den skal stå på. Videre bør det vurderes om materialbruken kan reduseres for å spare kostnader. For eksempel ved å bruke mindre dimensjon på reisverket. Dette er elementer som går inn i produktkøen. Produktstyringen utføres av produkteier eller produktansvarlig, som avgjør hva som skal produseres i neste sprint.

Innovasjonsprosessen er kundeorientert og datadrevet for å gjøre oss i stand til å skape verdi raskt. For det er markedet som avgjør etterspørselen, og gjennom den behovet for å skalere opp og stabilisere produksjonen. Ikke ledelsen. Deres ansvar er å legge til rette for smidig produktutvikling, med alt det innebærer av transformasjon i egen organisasjon.

Les gjerne min tidligere post Smidig tilnærming til utfordrende prosjekter om du vil vite mer om hvor tankegodset til smidig kommer fra.

Smidig tilnærming til utfordrende prosjekter

Postet den av
4

Feil antagelser, tapt innsikt i overleveringer og lang utviklingstid resulterer i mislykkede digitaliseringsprosjekter. Mens forventede gevinster uteblir, løper kostnadene fort – med tapte muligheter og bortkastet arbeid som resultat.

Men hva om vi lærer av feilene, og endrer tilnærming?

Det er nettopp det «Agile» eller smidig på norsk, har gjort. Smidig-bevegelsen, i mangel på et bedre navn, tilbyr en bedre og ja, mer smidig tilnærming; fra prosjekter med flere overleveringer til kontinuerlig produktutvikling og forvaltning, utført av samme team. Opparbeidet læring forsvinner ikke, og utviklingstiden reduseres radikalt fra år til uker.

Illustrasjonsfoto av jana müller på Unsplash

Antagelser

Vi trenger å korte ned tiden fra idé til funksjonelt produkt, for å bekrefte eller avkrefte de antagelsene som er lagt til grunn for behovet ute hos brukerne eller kundene. Antagelsen om problemet/behovet er viktig nok til at kundene vil bruke tid og ressurser på tjenesten/produktet er helt sentralt, siden hele business-caset for prosjektet bygges på denne hypotesen og antagelsen – alene.

Videre er det lurt å teste vår andre antagelse; om at løsningen vi har valgt er riktig. Hele gevinstkorthuset bygger på at denne helt sentrale antagelsen holder. Dessverre ser vi litt for ofte at det ikke er tilfelle.

Hvis vi tidlig i utviklingsprosessen tester de grunnleggende hypotesene våre i liten skala, kan vi lære hvordan en enkel prototype av en tjeneste eller produkt blir mottatt av kundene. Det er kanskje den beste muligheten vi har for å unngå å kaste bort penger på produkter og tjenester som aldri burde vært laget.

En slik tilnærming er helt i tråd med innovasjonsprosessen Bygge – Måle – Lære, som er kjernen i hvordan kundeorienterte og datadrevne virksomheter opererer. Dette har jeg blant annet skrevet om i et tidligere innlegg strategiprosess til besvær.

Overleveringer

Et prosjekt er per definisjon tidsavgrenset, som betyr at den læringen som har skjedd underveis i utviklingsprosessen, forsvinner i det resultatet/leveransen overleveres fra utvikling til drift. Utvikling er typisk organisert i prosjekter, mens drift og forvaltning som regel utføres av linje-organisasjonen.

For å komme i mål til rett tid, har det kanskje i utviklingsprosjektet blitt gjort noen grep som har resultert i teknisk gjeld. Som regel blir ikke teknisk gjeld oppdaget før etter en tid, av den enkle årsaken at linjeorganisasjonen ikke har nødvendig forutsetninger eller tilgang på erfaringen som er opparbeidet i utviklingsprosjektet. Erfaring som går tapt når prosjektet er ferdigstilt og utviklingsteamet oppløses.

En smidig tilnærming har ingen slik overlevering fra utvikling til drift. Blant annet begrunnet med at det er lurt å betale ned teknisk gjeld fortløpende, før effekten av renters rente gjør løsningen ustabil med de konsekvensene det kan medføre for tapt produksjon.

Om du vil vite mer om teknisk gjeld, kan du lese et tidligere innlegg: hva er teknisk gjeld?

Tid

Den siste store utfordringen med klassisk prosjektgjennomføring i digitalisering er tiden det tar fra behovet oppstår til en løsning er utviklet, testet og satt i produksjon. Hvis problemstillingen er kompleks, og prosjektet stort, kan det ta opptil flere år. I løpet av så lang tid kan behovene være endret, med konsekvens at løsningen ikke lenger er relevant. Nettopp dette var kjernen i kritikken som ble reist mot Akson, et gigantprosjekt til 11 milliarder for å utvikle elektroniske pasientjournaler til kommunene, som skulle løse for mange behov – samtidig.

Siden endringstakten i samfunnet øker, blir det nærliggende å møte denne utviklingen med å jobbe i kortere sykluser og sørge for at gevinstrealiserings­tidspunktet – når produktet vårt møter sluttbrukeren – kommer så tett opp til startpunktet som mulig. Helst ikke mer enn uker, og maks noen måneder.

For å få det til må sammensatte behov deles opp i mindre deler, og at vi må lære oss hvordan vi kan teste hypoteser for å redusere usikkerhet om hvordan produktet/tjenesten vil bli mottatt hos kundene. Dette er eksperimentering og læring satt i system, slik at vi kan ta gode beslutninger, understøttet av gode og oppdaterte data fra ekte kunder/brukere.

Det er her smidig kommer inn med en radikalt ny tilnærming til utvikling av programvare. Fra prosjektorganisering til produktorganisering med tverrfaglige, selvstyrte team som både utvikler og drifter tjenestene. Fordelen er åpenbar, siden smidig utviklingsmetodikk skaper verdi raskt i små steg ved å korte ned veien fra behov til fungerende kode i en digital løsning.

Smidig manifestet

Det sentrale tankegodset rundt «smidig» har rukket å bli 20 år i 2021, og kommer opprinnelig fra en gruppe utviklere som skrev Manifestet for smidig programvareutvikling. Manifestet går i korte trekk ut på å verdsette:

  • Personer og samspill fremfor prosesser og verktøy
  • Programvare som virker fremfor omfattende dokumentasjon
  • Samarbeid med kunden fremfor kontraktsforhandlinger
  • Å reagere på endringer fremfor å følge en plan.

Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere.

Smidig prinsippene

Manifestet følges av noen sentrale prinsipper:

  • Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi.
  • Ønsk endringer i krav velkommen, selv sent i utviklingen. Smidige prosesser bruker endringer til å skape konkurransefortrinn for kunden.
  • Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre.
  • Forretningssiden og utviklerne må arbeide sammen daglig gjennom hele prosjektet.
  • Bygg prosjektet rundt motiverte personer. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort.
  • Den mest effektive måten å formidle informasjon inn til og innad i et utviklingsteam, er å snakke ansikt til ansikt.
  • Fungerende programvare er det primære målet på fremdrift.
  • Smidige metoder fremmer bærekraftig programvareutvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et jevnt tempo hele tiden.
  • Kontinuerlig fokus på fremragende teknisk kvalitet og godt design fremmer smidighet.
  • Enkelhet – kunsten å maksimere mengden arbeid som ikke blir gjort – er essensielt.
  • De beste arkitekturer, krav og design vokser frem fra selvstyrte team.
  • Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt og så justerer det adferden sin deretter.

Hva dette betyr

Jeg opplever at tankegodset fra smidig manifestet sprer om seg i norske virksomheter i dag. Blant annet har jeg sett at det blir stadig vanligere å kjøre korte «stand-up» møter på 15 – 30 minutter for å koordinere oppgaver i teamet – ansikt til ansikt.

Så registrerer jeg med glede at enkelte kunder allerede har organisert seg i produkt-team etter modell fra smidig. Teamene er satt sammen tverrfaglig, slik at teamet har nødvendig forretningsmessig, juridisk og teknisk kompetanse til å utvikle ny funksjonalitet og gjøre løsningen mer robust.

Jeg er så heldig at jeg får lov til å være rådgiver for produktstyring og -strategi hos en stor norsk virksomhet som leverer samfunnskritiske tjenester. Figuren under viser hvordan produktstyring og smidig organisering skaper økt nytteverdi for kundene/brukerne.

Smidig utviklingsmetodikk

At teamene er selvstyrte, innebærer at de gjør egne prioriteringer innen rammene av en overordnet produkt-kø. Den inneholder en liste over krav og behov, som er sentral i den strategiske produktstyringen. Oppgavene organiseres i en sprint-kø, som produktteamet står fritt til å fordele og løse i løpet av sprint-perioden. Normal varighet på en sprint er 1-4 uker.

Fra produktkøen velges det ut oppgaver etter en helhetlig prioritering av hva som vil gi størst mulig nytteverdi i forhold til kostnader/innsats. Det er produktteamet som gjør dette. De planlegger sprinten slik at oppgavene er spesifisert og klare til at leveranseteamet kan utvikle kode for endringer som skaper nytteverdi. Endringene blir gjort tilgjengelig umiddelbart etter sprinten er ferdig demonstrert, testet og godkjent.

For å få til dette, kreves blant annet en god løsningsarkitektur som er modulisert, standardisert og automatisert for testing. Det er typisk her jeg kommer inn som rådgiver innen smidig utviklingsmetodikk og -prinsipper. Selv lærte jeg om smidig for 10 år siden, da jeg tok en sertifisering som produkt-eier (Certified Scrum Product Owner), en innsikt jeg har hatt stor glede og nytte av siden.