Bedre kommunikasjon

• Inkluder produkteier på morgenmøtene: Daglig kommunikasjon mellom kunde og leverandør har en dokumentert enorm effekt på hvor vellykket et prosjekt blir. Teamets fokus blir mye bedre dersom det er noen på de daglige standup møtene som er interessert i å prøve ut det som har blitt laget i går, som er interessert i å komme med innspill på det som lages i dag og som har myndighet til svare på avklaringer angående dagens oppgaver.
• Programmér sammen: Utviklere på prosjekter innehar enorm kunnskap, både om de delene av systemet man lager og om programmering generelt. Når man programmerer i par og roterer hvem som jobber sammen hyppig, blir denne kunnskapen spredt til alle. Spe også gjerne på med seanser der hele teamet går gjennom deler av koden på storskjerm.
• Bruk en Scrum-tavle: For å hjelpe alle å huske på hva som er målet med sprinten, er det lurt om teamet holder standup møtene rundt en tavle med lapper for alle aktiviteter teamet har planlagt i iterasjonen. Lappene henger i kolonner “venter”, “under arbeid” og “ferdig”. Hver lapp bør ha et så lite omfang at teamet flytter flere lapper til “ferdig” hver dag.

Bedre kvalitet

• Verifiser krav med funksjonelle tester: Når teamet skal jobbe med en oppgave i en iterasjon, er det viktig at alle har konkret forståelse av oppgaven. Produkteier bør beskrive eksempler for å gjøre oppgavene konkrete. Om mulig, bør produkteier uttrykke eksemplene i et verktøy for automatisert funksjonell testing (for eksempel FitNesse eller Cucumber). Teamet kan da kjøre testene og automatisk sjekke at de oppfyller produkteiers forventning
• Skriv enhetstester før koden den tester: For å kunne utvikle funksjonalitet inkrementelt, må man kunne endre på kode som allerede har vært ferdigstilt, samtidig som man er (rimelig) sikker på at endringen ikke ødelegger noe som har virket før. De funksjonelle testene kan gi et sikkerhetsnett, men det tar typisk lang tid å kjøre dem og de gir ofte ikke en eksakt indikasjon av hva som er feil når noe ikke virker. Derfor bør teamet skrive raske tester som verifiser at klassene i systemet fungerer, gjerne før man skriver koden.
• Integrer endringer kontinuerlig og automatisk: Automatiske tester er kun verdifulle dersom de kjøres! Sett derfor opp en Continuous Integration server som sjekker ut og tester alle endringer hver gang en utvikler har sjekket inn en endring til kildekodekontroll. Om mulig bør dette systemet også automatisk installere den siste versjonen av programvaren til et egnet testmiljø, slik at produkteier alltid kan se hva som er siste versjon av systemet.

Bedre forretningsfokus

• Inkluder alle oppgaver i en prioritert produktkø: Mange team lurer på hvilke oppgaver som skal puttes på produktkøen. Dersom noe gir forretningsverdi og tar betydelig tid å utføre, bør produkteier inkludere oppgaven på produktkøen. Ikke-funksjonelle krav må som regel testes. Det tar tid å sette opp testene og rette opp eventuelle mangler. Ikke-funksjonelle krav skal på produktkøen. Brukerdokumentasjon må skrives og kvalitetsikres. Det tar tid å skrive god brukerdokumentasjon. Brukerdokumentasjon skal på produktkøen.
• Bli helt ferdig med funksjonalitet: Teamet får kun “poeng” for helt dønn ferdig utført arbeid. Etter en iterasjon bør alt som tilhører en oppgave være så ferdig at det er greit dersom man aldri mer bruker tid på koden. Koden, tester og dokumentasjon må være i en akseptabel tilstand. Det betyr ikke at koden er frosset. Dersom man for eksempel utfører en oppgave for å verifisere responstid, må teamet oppdatere eksisterende kode slik at den støtter tidsmålinger og at man korrigerer eventuelle ytelsesproblemer man oppdager. Dette arbeidet tilhører det å implementere responstidskravet – den originale funksjonen er ferdig.
• Ta med brukere på demo: Dersom du lager et system som interesserer dine (fremtidige) brukere, bør teamet ha noe spennende å vise dem på demo etter hver iterasjon. Bruk demo-møtet til å involvere brukerne. Sørg for at input fra brukerne blir tatt hensyn til, og at de får beskjed om innspill som har blitt implementert, slik at de fortsetter å interessere seg.

Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon. Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretningsverdi. Dét er hvordan du lykkes med smidige prosjekter.

Jeg planlegger å publisere en Steria 3-minuttersguide basert på denne artikkelen. Innspill til forbedringer mottas med stor takk!

Min erfaring er at det er ved produksjonssetting de virkelige utfordringene begynner, og da din prosjektgruppe trenger fokus. Nettopp da må styringsgruppen og involverte beslutnignstagere forstå at prosjektet trenger arbeidsro og gode rutiner, ikke nedleggelse, nye rapporteringsforpliktelser, bli gjenstand for budsjettkutt eller lignende. Utsagnet et system som ikke endres er et dødt system er virkelig sant i denne perioden. Husk det når du budsjetterer prosjektet og når du setter dine forventninger.

Det er alltid forbundet med risiko å ta en beslutning om konvertering og produksjonssetting, ofte resulterer det, i at man ikke klarer å skru av det gamle systemet likevel, eller at svært mange interessenter blir misfornøyde og skaper mye støy for prosjektet – den gamle løsningen fungerte jo bedre. Man kan teste så mye man orker før produksjonssetting, men Murphy’s lov slår til og ting går galt. Brukeren kan det ikke – da fungerer det ikke. Noe av det testteamet trodde var i orden viser seg kanskje også å skape en nedtur i begynnelsen. Opplevelsen trenger altså ikke bare være basert på reell mangel på funksjonalitet, men opplevd funksjonalitet. Fenomenet kan illustreres med en blodbadkurve, der man opplever at det nye systemet fungerer vesentlig dårligere enn det gamle systemet i en periode etter produksjonssetting.

Ved å gjøre de rette grepene kan imidlertid blodbad-perioden reduseres og gjøres minst mulig smertefull. Her er fire tips.

1. Styr forventningene i forkant – Blodbad-perioden er ofte den samme tidsperioden der styringsgruppen forventer at gevinstene skal realiseres, gjerne nokså umiddelbart. Dette er en umulighet hvis man ser på kurven over. Prosjektet er travelt opptatt med å prioritere feil, lære seg å drifte det nye systemet, lære brukerne å bruke det nye systemet og løse de mest kritiske tingene som mangler i systemet, ofte ved hjelp av tidkrevende workarounds inntil gode nok løsninger er på plass.

2. Gi prosjektet økonomisk handlingsrom – Det sikreste man kan gjøre for å sikre absolutt fiakso er å legge ned prosjektet i denne fasen. Likevel er ofte “pengene brukt opp”, man hadde jo ikke regnet med at man måtte jobbe når man hadde levert til produksjon og nedleggelse blir realiteten. Det å ikke ha penger til endringer og videreutvikling i denne perioden er den sikreste måten å redusere levetiden på det nye systemet dramatisk. Det kan også tenkes at de som har fått det nye systemet trenger litt tid på å lære det, så regn med noen vikarer.

3. Vær flink til å prioritere og operer med åpne prioriteringslister – Styringsgruppen ønsker rask realisering av visjonen og at prosjektet skal makte å følge den stiplede grønne utviklingsbanen. Svaret er ja, det skal dere få, men først må prosjektet få hodet over vannet i form av å løse de mest kritiske feilene. Deretter kan man prioritere forbedringer og nyutvikling. Et sikkert tegn på at man har med en umoden styringsgruppe å gjøre er dersom de i denne perioden forventer at prosjektet skal prioritere nye forretningskrav som plutselig har kommet opp når de ser det nye systemet. Prosjektgruppen bør prioritere utestående områder slik at det som er mest kritisk (eller lønnsomt) kommer først.

4. Avklar ansvar og organisasjonsmodell for vedlikehold tidlig – Etter produksjonssetting kan det være uklare ansvarsforhold knyttet til vedlikehold. Innse det med en gang – et system uten endring er et dødt system. Da må man vite hvordan endringene skal gjennomføres, testes og produksjonssettes også etter oppstart. Ofte “fryses” kanskje systemet for å unngå store endringer rett før oppstart, med den konsekvens at utviklerne som kunne løst feil raskt forsvinner over til andre oppgaver eller mister fokus. Realiteten er at det er i produksjonssettingsfasen at endringstakten, eller i hvert fall feilrettingstakten, bør være desidert størst. I hvert fall dersom man mener alvor med å snu blodbadet og realisere visjonen for prosjektet.

Legg merke til at jeg ikke foreslår å utsette produksjonssettingen. Dette er åpenbart eneste alternativ dersom man ser at selv de mest basale behov systemet er tenkt å løse ikke fungerer, men i så tilfelle har prosjektet et større problem og burde ha lært seg metoder som Scrum og EVO for lenge siden.

Legg også merke til at prosjektet endrer karakter den dagen man produksjonssetter. Det er ikke lenger et erstatningsprosjekt. Det er et smidig forbedringsprosjekt og må behandles som det!

Les mer på sterkbladning.no:

• Johannes om erstatningsprosjekter
• Ole-Vidar om driftsrammeverk (ITIL) vs utviklingsrammeverk (Scrum)

“If A System Is Working, Leave It Alone. Don’t Change Anything!”
- John Gall, Systemantics (1975)

Planen

Det gamle systemet hadde blitt uholdbart. Leverandøren ga ikke lenger support på maskinvare eller programvare, det var umulig å oppdrive kompetanse for å videreutvikle og det var ikke lenger vedlikeholdbart siden det var så kompleks.

Vi skulle derfor erstatte systemet med et nytt et. Bygget fra bunnen med moderne teknologi. Det burde bli enkelt, siden dagens system kan fungere som kravspesifikasjon. Vi hadde estimert arbeidet til 83 511 timeverk.

Vi ville naturligvis ikke investere store mengder arbeid i det gamle, døende systemet. Og dessuten var det umulig å integrere med. Så vi måtte bygge det nye systemet med all funksjonalitet, og så, en spennende helg om noen år, sette det i produksjon.

Slik høres introduksjonen til mange erstatningsprosjekter ut. I disse prosjektene har man et eksisterende system som typisk er kritisk for virksomheten. Av gode eller dårlige grunner har man valgt å gjennomføre et prosjekt som skal erstatte hele den gamle systemet med et nytt system som oppfyller samme målsetning.

Denne planen burde med en gang ringe noen varselbjeller. Hva er egentlig poenget med dette prosjektet? Prosjektet ønsker å videreføre dagens tjeneste med et nytt og moderne system. Og det er billigere måter å gjøre det på.

Uortodoks observasjon #1:

Et erstatningsprosjekt er en dyr måte å forlenge livet til vår nåværende forretningsmodell.

Det virker umulig å komme seg forbi hindrene i form av support, kompetanse og vedlikeholdbarhet. Men dersom vi doblet lønna til alle som ville programmere COBOL, så ville vi nok få nok kompetanse. Det er mulig å videreføre systemet. Det er bare veldig dyrt. Men det er også fantastisk dyrt å erstatte et system fra bunnen. Man kan bruke mange dyre teknikker for å holde systemet i gang før der lønner seg å erstatte.

På de fleste systemer er imidlertid support, kompetanse og vedlikeholdbarhet ikke de eneste, og kanskje ikke de egentlige motivene. Det finnes andre motiver, både dårlige (noen vil ha et stort prosjekt på CV eller jobbe med ny teknologi) og gode (vi ser muligheten til å levere verdi).

Først når erstatningsprosjektet tilfører forretningsverdi er det verdt å gjennomføre. Erstatningsprosjekter for å redusere kostnader eller forlenge levetiden på en utdatert forretningsmodell er en dårlig ide.

Virkeligheten

“A Complex System Designed From Scratch Never Works And Cannot Be Made To Work. You Have To Start Over, Beginning With A Working Simple System”
- John Gall, Systemantics

Den forrige arkitekten hadde holdt på med systemet i tre år. Og organisasjonen hadde ingenting å vise til. Det var ikke blitt ferdig, og han hadde insistert på at det var umulig å levere deler av systemet.

Styret er lei av denne unnskyldningen, og om administrerende direktør ikke finner en arkitekt som kan bevise at investeringene har verdi, er det han som må gå.

Et forsinket prosjekt mister politisk goodwill. Det er bare en måte for et prosjekt som har mistet troverdighet å redde seg på: Man må levere noe. Og da må man spise noen kameler.

Uortodoks observasjon #2:

Det nye og det gamle systemet kommer til å leve sammen.

Heldigvis er dette gode nyheter. Med en gang vi vet at det nye og det gamle systemet må leve sammen, åpner det døren for en rekke muligheter til å tenke bedre.

Gradvis erstatning

Først, her er fire patterns for å gradvis erstatte et system:

• Delt database: Dersom det gamle systemer benytter en relasjonsdatabase kan det nye systemet bruke denne direkte. Det gjør det mulig å levere deler av det nye systemet nesten umiddelbart, men det legger føringer for designer av det nye systemet som man kanskje kunne unngått.
• Import/eksport: Før eller siden må vi forholde oss til de dataene som finnes i det gamle systemet. Ta kostnaden tidlig og eksporter data til det nye systemet. Men vær forsiktig: Det er vanskelig å ha to mastere for data. Start med å la det gamle systemet være master.
• Datatjenestelag: Dersom du ønsker å erstatte det gamle systemets datalager, kan du innkapsle dette i en tjeneste. Legg imidlertid merke til at datatjenester har høyt endringsbehov og tjenester som deles i et stort prosjekt er kostbare å endre.
• Parallell produksjon: Dersom det nye systemet utvikler funksjonalitet som finnes i det gamle, se om det er mulig at begge versjonene kan være i produksjon samtidig. Da reduseres konsekvensen dersom den nye versjonen inneholder feil, siden å rulle tilbake en produksjonsetting er enklere. Dette gjør at det kan være mulig å produksjonsette med mindre testing. Det nye systemet kan også starte med et subset av brukerne. Dermed kan man utsette noe av ytelsesoptimaliseringen til man har bedre erfaring fra faktisk bruk.

Men det krever mer enn teknikker for å sette sammen systemene for å lykkes. Man må makte å finne oppgaver som man kan jobbe på og realisere verdi for organisasjonen i løpet av erstatningsprosjektet. Her er fire patterns for å finne områder å erstatte:

• Risiko: Enkelte endringer er så viktige at uten dem, vil prosjektet regnes som mislykkes. For prosjekter relatert til pensjonsreformen vil det være katastrofalt om man ikke kan implementere det nye regelverket. Andre systemer har lenge hatt kjente svakheter som man har forpliktet seg til å utbedre. Fiks dette først!
• Kostnad: Organisasjoner som benytter systemer har ofte noe arbeidsoppgaver som er ekstra arbeidskrevende. Kanskje det er å punsje data, eller å overføre data fra et system til et annet. Eller kanskje det er kundene som ringer og spør om hvordan saken deres ligger an. Ved å velge et slikt område kan prosjektet levere gevinst tidlig.
• Isolerte brukere: Mange systemer har brukergrupper som bare benytter en liten del av systemet. Det kan være lurt å starte med en slik brukergruppe, ettersom man kan erstatte hele den delen av systemet de benytter på noen få leveranser.
• Nye brukere: Mange organisasjoner ønsker å lage selvbetjeningsløsninger for publikum. Disse er også gode og vanlige steder å starte et fornyingsprogram.

Arkitektur

“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”- Conway’s Law

En arkitekt på et stort prosjekt som lar prosjektlederen bestemme hvilke arbeidspakker hvert team skal jobbe med har begrenset mulighet til å påvirke prosjektets suksess.

Som arkitekt er det ofte fristende å jobbe med en målarkitektur. Men for et stort prosjekt blir målarkitekturens største føringer organisasjonen som skal utvikle systemet. Å oppfylle prosjektets behov for at folk kan jobbe uten å konstant ramle i beina på hverandre må prioriteres over andre arkitekturmål.

Jo flere kokker, desto mer søl. Det er din jobb å sørge for at ikke alle må være på samme kjøkken. Eller enda verre: Løpe mellom alle kjøkkenene.

Uortodoks observasjon #3:

I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg.

Min erfaring er at det finnes noe fundamentale grenser for hvor mange personer som kan samarbeide:

• 4-6 personer kan jobbe med en person som dekker arkitektur, analytiker og teamleder-rollene. Dersom gruppen blir større enn dette, må man typisk ha tre personer for å dekke disse rollene.
• 10-12 personer kan jobbe på den samme koden og med den samme produktkøen uten å komme i beina på hverandre. I alle fall så lenge de kommuniserer daglig
• 30-35 personer kan jobbe med en kodebase som er kontinuerlig integrert. Dersom det er flere, vil tiden man bruker på å rette integrasjonsfeil bli en betydelig kostnad.

Og når prosjektet blir for stort for kontinuerlig integrasjon, må gjenbrukt kode versjonshåndteres. Dette betyr at det vil være dyrt å gjøre endringer. Kode som ikke kan endres blir ofte dårlig kode. Så gjenbruk ut over 30-35 personer er overraskende dyrt.

Til slutt bør team ha som målsetning å produksjonsette hver tredje måned. Dette er veldig vanskelig å gjøre dersom en leveranse inneholder mange deler som ikke er kontinuerlig integrert. Deler som ikke er kontinuerlig integrert bør fortrinnsvis produksjonssettes helt separat fra hverandre.

Konklusjon

Et prosjekt som skal erstatte dagens system uten å endre forretningsprosessene har feil fokus. Modernisering er bra, men ha fokus på verdien til andre enn de som vedlikeholder systemet.

Vi har en rekke antagelser om hvordan erstatningsprosjekter vil fungere. Etter min erfaring er mange av disse antagelsene feil. Du kan godt ha annen erfaring, men her er min:

• Et erstatningsprosjekt er en dyr måte å forlenge livet til en eksisterende forretningsmodell
• Det nye og det gamle systemet vil leve sammen
• I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg

Vi får til erstatningsprosjekter ved å levere gradvis.

“Galls Law: A Complex System That Works Is Invariably Found To Have Evolved From A Simple System That Worked.”
- John Gall, Systemantics, 1975