Geir Amsjø

Vel, en moderne plattform er vel tynnest mulig, med så lite funksjonalitet som mulig. Og det er fremdeles soft- og ikke hardware. Også en plattform lages for brukergrupper (håper jeg virkelig!). Mener alt Christin her skriver fremdeles er gyldig.

Godt skrevet! Og du har selvsagt rett i at det går an å levere veldig solide og bra saker i prosjekter. Det sentrale mener jeg er et sterkt eierskap i teamene, og da er det en forutsetning at de som gjør jobben har et langsiktig perspektiv og at de virkelig bryr seg om både produktets kvalitet og brukerne. Og at de har frihet til å gjøre selvstendige valg - dvs at ingen styrer dem for sterkt. Dette eierskapet svekkes hvis de vet at de skal levere produktet over til noen andre (forvaltning) når prosjektet er ferdig.

Interessant. En slags smidig tilnærming har muligens blir vurdert på et tidspunkt, men

blitt forkastet

Enig med TrondPedersen i alt han skriver her. Dette var et oppklarende svar og ting tyder på at avstanden rundt "plattform"-tanken kanskje ikke er så veldig stor. Men det er mye i dette svaret som skurrer.

For å ta det siste først: "Det er staket ut en kurs. Vi må begynne reisen, lære underveis og finne svar sammen med leverandørmarkedet og aktørene i helse- og omsorgssektoren." Det er da mye mer enn "staket ut en kurs"! Det er definert et vanvittig stort omfang over en periode på 5 år! Gildet er estimert til 11,4 Milliarder - hvordan er et slikt "presist" estimat mulig å komme til basert på en "kurs"? Er dette et forsøk på å legge leppestift på grisen, for å gjøre den "penere"? For det er vel fremdeles en opsjon å implementere denne plattformen med Epic? Er ikke estimatene basert på at en stor del vil være lisenskostnader?

Alt dette voldsomme, tidkrevende forarbeidet gjør at prosjektet ikke er rigget for å lære underveis. Dessverre.

Kritikken mot Akson går i stor grad ut på de voldsomme dimensjonene og den vanvittige bruken av kalendertid og penger. Hvis man går for en "lettvekts-plattform" og legger mye inn på egen kompetanse og økosystem ville det vært mulig å starte opp mye raskere og å nettopp lære underveis. Lærdommen kommer da direkte fra brukerne.

Risotto, Jeg forstår ikke hensikten med KS-regimet om man ikke skal ta med "risiko relatert til implementering". Det er jo her mange store prosjekter feiler - man undervurderer risikoen i selve prosjektet og valgt fremgangsmåte. Og ikke minst premisset om at man låser omfanget alt for sterkt, alt for tidlig. Hvis man hadde sett på hele risikobildet og tatt med smidig tilnærming som alternativ ville man fått et helt annet beslutningsgrunnlag.

Jeg har fulgt med på og kommentert Akson-debatten, men kjenner ikke igjen det bildet som forfatteren her tegner. En del ganske tendensiøse tolkninger av hva andre ytrer, synes jeg. Men jeg reagerer Først og fremst på to ting:

1. Ikke noe problem med virkelig store ambisjoner og satsninger - men det betyr ikke at man behøver å låse så store pengebeløp og så omfattende spesifikasjoner. Det finnes ingen som er i stand til å spå på denne måten om framtiden. Det som skjer når man analyserer et stort problem over lang tid er at det vokser og blir større og mer komplekst. De eneste som tjener på dette er konsulenthusene som skal planlegge, styre og gjøre jobben.

2. Smidig brukes ikke slik det er definert i innlegget. Nå er ikke smidig noe beskyttet ord, men jeg antar at man mener smidig som beskrevet i agilemanifesto.org slik mesteparten av bransjen bruker det. Til info: For at det skal kunne være smidig kreves det kortere/mindre forarbeid og at man planlegger med å lære og bygge opp kunnskap underveis. Og selvfølgelig skape gevinster underveis. Dette gjelder faktisk også "grunnmuren" eller "plattformen". Denne må være enklest mulig og kan også utvikles mens man leverer funksjonalitet. Visjonen stammer fra 2012. Men et smidig tankesett kunne dette prosjektet vært påbegynt for mange år siden og allerede skapt store gevinster for samfunnet.

Ikke feil å bruke tid og analysere omfattende, store og komplekse satsninger. Men når man bruker årevis, vil forutsetningene for analysen være utdatert når man endelig er klare til å starte. KS1 og KS2 vil ikke hjelpe i det hele tatt. Sett i gang å løse ett problem av gangen med klare, overordnede rammer og visjoner. Man vil da garantert lære underveis og oppdage veldig interssante muligheter mens man gjør jobben. Jobben kunne vært startet for mange år siden med denne tilnærmingen. 

Råder dere i ehelse til å sette dere skikkelig inn i hvilke metoder og verktøy som fungerer med smidig tilnærming. Det kreves naturlig nok ferdigheter og erfaring med smidig utvikling for å få det til. Kunsten å splitte den store elefanten opp i spiselige biter er ikke trivielt. Sikker på at dere er velkomne til å besøke Vipps og andre som gjør dette! Og så lenge dere støtter dere på konsulenter og rådgivere som opererer med tradisjonelle prosjekter som utgangspunkt, er det naturlig at dere ikke ser mulighetene spesielt godt. 

Verden er full av store, komplekse systemer som er utviklet smidig - som faktisk nettopp er laget for problemer der kompleksiteten er stor.

-----

LeSS er det mye samme ulla som SAFe? Vi holder på med innføring av SAFe hos oss. Personlig tenkte jeg først at det var overengineered, men det kan sikkert gjøres riktig. Det handler om kontekst...

----------

Hei Anders, dette er selvsagt en het diskusjon for tiden. SAFe beholder hierarki og dedikerte roller og inneholder i langt større grad konkrete oppskrifter på hvordan man skal gjøre f.eks governance. De blir veldig kritisert for å ikke kunne være smidig, siden det er så beskrivende. Minner litt om RUP. Svaret fra SAFe er at man trenger ikke ta hele rammeverket, bare bruke det man trenger.

LeSS har valgt en helt annen tilnærming. Akkurat som i Scrum har de sagt at LeSS er minimalistisk og inneholder veldig få krav og regler. Til gjengjelde finner man en hel rekke prinsipper, råd og tips. Larman og Vodde er svært erfarne og bra folk som ser at organisasjoner kan være svært forskjellige og trenger ulike metoder og regler.

Vi kan godt diskutere dette videre et annet sted - jeg har [email protected]

 

Jeg tror dere tenker litt for vanskelig om hva som er suksessfaktor for en levende IT tjeneste. Det er egentlig veldig enkelt. "you build it, you run it" Werner Vogels, Amazon.

 

Jeg forstår hva du mener, men det er ikke _nok_ å delegere til utviklerne. Man må endre noen av de rammene som fins omkring. Herunder prosjektoppsett, finansiering mv.

Brønnøysundregistrene er ikke et system som er enkelt og overskuelig nok til at ett (to-pizza) team kan håndtere en oppgradering.

Nei, vi må ikke overforenkle dette. Men det finnes gode modeller for storskala, smidig utvikling. LeSS (http://less.works/) er brukt på virkelig store systemer/virksomheter med mange titalls feature-teams. Her finner man gode verktøy, prinsipper og veiledningsmateriale som er gjennomprøvd. Rikelig med case studer også. En god kombinasjon av LeSS og Beyond Budgeting kan gjøre susen i enhver moderne stor virksomhet.

Ja, ting er utvilsomt veldig sammensatt og årsakssammenhengene kan være mange. Problemet er bare at det er svært vanskelig, mange vil hevde umulig, å gjennomføre en objektiv og god analyse av noe så komplekst som et IT-prosjekt. Jeg har deltatt i sikkert 30 prosjektevalueringer og har svært ofte tatt feil. Alt for ofte konkludert med at vi skulle gjort enda grundigere forarbeid - fordi jeg på den tiden ikke så alternativet, nemlig å lære underveis. Problemet ligger i at et menneske alltid "biased". Du oppdager det du forventer å oppdage og vil overse uventede ting. (Dave Snowden får fram dette godt her i denne ferske Keynoten:

I stedet kan vi betrakte de store linjene og se etter mønstre. Og vi kan se på samfunnet rundt oss og forsøke å forstå hva det vil kreve av oss. Et helt klart utviklingstrekk er raskt forarbeid, med læring og tilpasning underveis. Vi ser det overalt. Og vi kan støtte oss på teori. Som Dave Snowdens kompleksitetsteori og Cynefin modellen. Vi kan bruke systemtenkning og CLD. Og hvorfor ikke helhjertet prøve ut smidige metoder? Gjøres dette vil det være HELT umulig å feile fatalt - slik IT-prosjekter ofte gjør. Du vil fremdeles feile, men altså ikke så fatalt og det vil være godt rom for å skifte kurs (eller stoppe helt opp) når det trengs. Mener vi må angripe problemet på det nivået - og det kan gjøres uten å ta veldig stor risiko.

Arild, jeg er som du vet enig med Christin her. Er denne voldsomme kompleksiteten egentlig et IT-problem? Det er helt sikkert masse teknisk gjeld i kjernesystemer - og det kan ha mange årsaker. Men det som slår meg er at offentlig sektor også har en betydelig prosessgjeld. Siloorganisering fører lett til unødvendig innviklede verdikjeder. Vi kjøper altså ikke at vi bare skal akseptere voldsom kompleksitet og handle deretter. Hvorfor ikke benytte denne anledningen til å virkelig forenkle prosessene, gjennom å snu alt på hodet og starte med brukernes behov. Slik de gjorde i UK med GDS. Bort med siloene, start alltid med brukern.

Skulle ønske noen - for eksempel i Difi - kunne gå med på å diskutere om dette i det hele tatt kan la seg gjøre i Norge. Helt enig i det siste avsnittet, der du etterlyser en slik arena.

Det har aldri vært nødvendig å lage software-systemer på denne måten. Aldri særlig smart heller. Antagelig kommer det av ideen om at Prosjektstyring er et selvstendig fag, uavhengig av hva slags prosjekt som skal styres.

Men digre, langvarige prosjekter blir stadig mindre smart! Den aksellererende utviklingen vi står oppe i nå gjør det særdeles viktig å levere gradvis og å bare innse at 6-års planer ikke holder mål. Skrev om det her: https://www.linkedin.com/pulse/samfunnsutviklingen-og-digitalisering-geir-amsj%C3%B8?published=u

Sovjetunionen baserte seg på 5-årsplaner for mange titalls år siden. Det kan jo fungere i et diktatur, men er selvsagt fånyttes i den markedsdrevne virkeligheten vi har i da. BRREG lager 6-årsplaner. Just sayin´.

Vi ønsker da Brønnøysundregisterne alt godt og håper virkelig dere klarer å lage fremtidsrettede, gode løsninger for samfunnet. Og vi tviler ikke på nødvendigheten av å ta et krafttak og betale teknisk gjeld. Men svaret beroliget ikke. Med denne typen planlegging og budsjettering vil risikoen være stor for at dere låser dere alt for tidlig, basert på antagelser. De 6 delprosjektene kan potensielt utnyttes til å redusere risiko - hvis de kjøres i sekvens, leverer delleveranser, og bare det første er låst. På denne måten skapes verdier raskere og man er ydmyke for at læringen underveis kan utnyttes til å lage et best mulig system. Håper det er dette dere mener med de 6 reirene (fin metafor, forresten) som jo må bety at de er autonome.

Det er svært positivt at dere han en solid stab med flinke egne ansatte. Dette synes å være en ambisjon også hos andre i offentlig sektor (som NAV). Bra. Men da blir det egentlig enda vanskeligere å forstå at det kan være nødvendig å klumpe sammen et slikt gigantprosjekt på 1,2 Mrd. Her burde det vært mulig å både finansiere og "restaurere" eksisterende systemer gradvis og mye tryggere.

Det vi egentlig kritiserer her er anskaffelsesregimet som tydeligvis promoterer digre ustyrlige prosjekter, framfor å fremme solid nok investering i utvikling og vedlikehold for å unngå opphopning av teknisk gjeld. Softwareutvikling er og blir Business As Usual for de aller fleste virksomheter og burde behandles deretter, med kontinuitet og høy håndverksmessig standard.