Empirisk prosesskontroll

Når man skal løse et problem, kan man først forsøke å skaffe seg noe erfaring eller empiri før man låser seg til den ene eller den andre løsningen. På den måten vil man kunne få en større trygghet for at løsningen er god.

Empirisk planlegging av helleganger

Når landskapsarkitektene skulle planlegge hellegangene på Universitetet i California, Irvine tenkte de først å gjøre dette på den vanlige måten, nemlig å forsøke å gjette hvor studentene kom til å krysse de store gressplenene, og å anlegge heller der. Men dette hadde de tidligere bare måtelig suksess med. Alltid dukket det opp stygge stier over gresset der studentene fant det for godt å gå. Så, i stedet valgte de denne gangen å bare plante gress. Så ventet de et år, for da visste de jo at det ville danne seg stier på gressplenen – nøyaktig der studentene gikk. Da var det ganske enkelt å legge heller nøyaktig der det var behov for det, for nå hadde de svært god empiri å basere seg på.

Vitenskapelig metode

Om man skal i gang med å løse komplekse problemer som kanskje ingen har løst før – og som man selv bare har vage ideer om løsningen på – blir man jo tvunget til å gjøre noen spede forsøk, som man er forberedt på at kan være et bomskudd. Det gjelder da å finne ut om man er på en farbar vei, så raskt og så billig som mulig, slik at man bruker den nye kunnskapen til å justere kursen. Dette er jo akkurat det vi kaller en vitenskapelig metode. Vi har et problem og vi har en mer eller mindre velbegrunnet hypotese om en løsning. Vi gjennomfører en test, et eksperiment man man vil, og evaluerer så snart man har et resultat. Styrket dette hypotesen, eller ikke? Uansett om den gjorde det eller ikke, bruker vi nyervervet kunnskap til å utføre et nytt eksperiment, kanskje med en noe justert hypotese. Og slik kan man holde på og gjennom gjentagende eksperimenter komme nærmere og nærmere en løsning. (Om hypotesen ikke styrker seg gjennom eksperimentene, gjelder det selvsagt å avbryte – selv om det føles som et nederlag).

Lean Start-up er et konsept som fokuserer sterkt på dette med systematisk læring. Spørsmålet er jo “Hvordan kan vi så raskt og billig som mulig få validert lærdom ut av et eksperiment?” Og ikke minst “Hvordan så raskt og billig som mulig finne ut om en ide ikke er en farbar vei og bør skrinlegges?”

Empirisk versus definert prosesskontroll

Scrum baserer seg på “Empirical Process Control Theory“. Dette er et alternativ til “Defined Process Control“. Det er verd å merke seg at disse to teoriene er eksluderende – det er vanskelig å kombinere de to.

Definert Prosesskontroll

Her er ideen “stepwise refinement” slik at vi jobber strukturert i en kjede av definerte aktiviteter som gradvis løser problemet. Det som er resultatet av en aktivitet mates inn i den neste. Hver av aktivitetene har gjerne en tilordnet rolle eller ansvarlig person. Den aller siste aktiviteten i kjeden produserer sluttresulattet.

Dreier dette seg om programvareutvikling kjenner vi lett igjen vannfallsmodellen, der noen analyserer, andre designer, andre igjen utvikler, så tester vi, integrerer, og leverer. Vi får her begrenset mulighet til å teste ut hypoteser, vi vil være helt avhengige av analysene og planleggingen som finner sted helt i starten holder vann. Dette kan fungere helt fint – om problemet er repeterbart, dvs noe vi har gjort før. Eller sagt på en annen måte: om vi er i “Simple” hjørnet i Cynefin-modellen. Om vi oppdager at analysene og planene våre ikke holder vann  forsøker vi å løse dette gjennom endringsbehandlig – hvilket er en svært dyr og belastende aktivitet som fører til store forsinkelser i fremdriften. Det som ofte forårsaker dette er at vi undervurderer kompleksiteten og det vi i utgangspunktet trodde var enkelt viste seg å være komplekst.

Empirisk prosesskontroll

Her er tanken at vi må eksperimentere og skaffe oss empiri så raskt som mulig slik at vi gradvis bygger opp kunnskap og kommer nærmere og nærmere en løsning på problemet. Dette fordrer arbeid i tverrfaglige team slik at vi sikrer at de som gjør arbeidet totalt sett har nok kunnskap. Vi bryr oss ikke om hvordan de jobber. Akkurat som i vitenskapelig metode vil den initielle hypotesen være ganske avgjørende for effektiviteten, så vi må gjøre en del forarbeid for å skaffe gode nok (men ikke bedre) utgangshypoteser.

Om dette dreier seg om programvareutvikling vil vi ha en hypotese om hvilken teknologi vi bør velge, hvilke arkitekturprinsipper som bør gjelde og selvsagt hvilken funksjonalitet vi skal tilby tidlig.

Etter dette gjelder det å komme fram til resultater som lar seg observere og lære av. Disse resultatene kan i noen tilfeller være så gode at de faktisk kan leveres, men verdien i et slik resultat kan godt være ren kunnskap. Enkelte ganger vil vi ha forhåpninger om at brukerne virkelig ønsker seg dette, men så viser det seg allikevel (huff, disse brukerne er så uforutsigbare!) at vi får tommelen ned. Resultatet vil allikevel ha en verdi for vi vil garantert ha lært en del!

Igjen, er dette programvareutvikling, forsøker vi så tidlig som mulig å sette teknologi- og arkitektur-beslutningene på prøve, og selvsagt å få tilbakemelding på om den tidlige funksjonaliteten vi lager verdsettes av brukerne. 

Scrum lar seg vanskelig kombinere med definert prosesskontroll. Men det var heller aldri meningen – Scrum er laget for innovasjon, å løse komplekse problemer (i “Complex” hjørnet i Cynefin-modellen) og er basert på hypotetisk-deduktiv metode. Vi optimaliserer transparens og gjør “inspect and adapt” gjentatte ganger slik at vi gradvis kommer nærmere og nærmere målet.

Bruker man Lean Start-up-tankegang i kombinasjon med Scrum vil man typisk optimalisere lærdommen man får ut av hvert eksperiment. Og så er det selvsagt slik at jo hyppigere man leverer ting til markedet og jo raskere man får feedback etter å ha utviklet noe, desto bedre læringseffekt får man. De som leverer på Web og er i stand til å gjøre continuos deployment vi kunne eksperimentere med brukerne som en integrert del av prosessen. Dette er på mange måter den ultimate utviklingsprosessen.

 

Posted on October 29, 2012 at 2:24 pm by gamsjo · Permalink
In: kompleksitet, prosjektledelse, Uncategorized · Tagged with: , , ,

4 Responses

Subscribe to comments via RSS

  1. […] er basert på empirisk prosesskontroll og designet for å forhindre sub-optimalisering. Derfor er selve definisjonen av rollene i Scrum […]

  2. […] Det blir verre. Alle fasene har et smidig-kapittel så jeg klikker meg inn på “Smidig i konseptfasen” og leser: “Denne fasen – som alle andre faser i PRINCE2®-modellen – kan organiseres i sprinter for leveranser i henhold til smidige metoder.” OK. Skjønner. Det blir liksom smidig av å kjøre alle fasene i iterasjoner. Huff! Fullstendig misforstått, det vi trenger er Empirisk Prosesskontroll. […]

  3. […] å absorbere den! Dette gjør vi ved “prøving og feiling” eller kanskje et bedre uttrykk: Empirisk Prosesskontroll. Vi må skaffe oss empiri så raskt og billig som mulig slik at vi kan validere antagelsene vi har […]

  4. […] dette: Definert prosesskontroll, tradisjonell prosjektstyring, grundig analyse og planlegging, separate […]

Subscribe to comments via RSS

Leave a Reply