Samspill foran prosesser

Agile manifesto revisited – fikk du med deg alt?

Har du fundert litt på hva som er tenkt når et prosjekt struktureres og hva slags grunnlag lederen har for å velge den ene eller andre måten å gjøre det på? Dette innlegget presenterer et grunnlag for å velge en god gjennomføringsmodell.

Det kommer i blant bud om nye måter å tenke på og revolusjonerende innsikter som skal løse våre problemer og hjelpe oss til å oppnå suksess. Vi får presentert nye måter å slanke oss på, vi får tips om hvordan vi klatrer på karrierestigen og vi får vite hva som virkelig gjelder når man skal pynte juletreet.

I IT-bransjen kommer det noen nye rammeverk som skal hjelpe oss med å ordne opp i alt uforutsett hodebry det forrige rammeverket var årsak til. Og ikke minst finnes det nyvunnen visdom som forteller oss hvordan vi skal bli en god leder. Noe av dette er ny forståelse som faktisk kan føre til en forbedring, og noe er enten gamle tanker i ny innpakning eller ganske grunnløst tankespinn som ikke fører til noen konkrete forbedringer.

Innen faget prosjektledelse har vi mange konkurrerende metoder å gjennomføre prosjekter. Det finnes en god del standardmetoder som foreskriver klare og spesifikke roller og like klare prosesser og overganger mellom faser. Som en markant motreaksjon til dette ble det innen programvareindustrien for en del år siden lansert en annen tilnærming som på engelsk fikk benevnelsen agile. Dette kunne ha blitt oversatt til rask og responsiv, men det norske begrepet har blitt smidig. Den grunnleggende tanken var å nærme seg problemstillingen fra en annen kant og vektlegge enkelhet, kommunikasjon og individets evner i stedet for prosessbeskrivelser og tung dokumentasjon. (Det vi i dag kjenner best til er metoden Scrum, som er en svært enkel gjennomføringsmodell sammenlignet med alt som finnes innen den andre tradisjonen.) En del tungvektere innen faget i USA kom i 2001 sammen og fant noen setninger de var enige om skulle romme kjernen i den smidige måten å tenke på.

Manifestet for smidig programvareutvikling

Vi finner bedre måter å utvikle programvare på
ved å gjøre det selv, og ved å hjelpe andre med det.

Gjennom dette arbeidet har vi lært oss å verdsette følgende:

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.

I hvilken kategori havner dette? Er det slagord som bare er en del av de alltid tilstedeværende buzzwords eller finnes det et innhold her som kan brukes? Scrum og smidig er i dag kjente begreper, og mange innen bransjen kjenner disse tankene. Som ventet har det blitt en del litt forskjellige oppfatninger av nytten og den faktiske anvendelsen. Manifestet kan minne mistenkelig om en enkel oppskrift på hvordan man lykkes hvis man følger noen hellige regler. De absolutte smidig-tilhengerne holder gjerne sin tenkning som et totalt brudd med tidligere tradisjoner og har strenge krav til at man helst bør etterleve alle bud og regler i sin filosofi. I tillegg innbyr ordet manifest til noen assosiasjoner forbundet med tung ideologi og absolutte oppfatninger, dermed har kanskje dette manifestet kommet litt i vanry, og momentet kan være i ferd med å dø ut.

Dette innlegget vil slå et slag for Manifestet for smidig programvareutvikling! Men i stedet for å peke strengt på anbefalingen i de fire setningene er det i første omgang interessant å se hvordan det hele er skrevet og hva som står med liten skrift.

I stedet for å leve opp til det tabloide formatet for å nå ut til massene har de valgt å skrive en ganske myk innledning med «… har vi lært oss å verdsette følgende:» Dessuten er det skrevet: «Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere.» Her står det altså at prosesser, verktøy, omfattende dokumentasjon, kontraktsforhandlinger og å følge en plan har verdi! Forfatterne har ikke havnet på en konklusjon som forkaster alt som strider mot kjernebudskapet som gammelt og uklokt. Ordet «fremfor» er også brukt i hver setning, som uttrykker i større grad en prioritering enn et budskap om at himmel står mot helvete og Liverpool mot Manchester United. Her skiller manifestet seg fra de fleste oppskrifter på suksess vi blir servert.

Hva kan vi trekke ut av disse betraktningene? Vi kan lære at ethvert sjakktrekk har noen svake sider. Og noen ganger må man ta mer hensyn til de svake sidene enn andre ganger. Det er alltid gunstig å forsøke å nå fram med samarbeid med kunden, men noen ganger kan det være lurt å være mer grundig med avtaleverket også. Det er alltid viktig å få individet til å føle eierskap til produktet og basere aktiviteten på individets motivasjon, men en må passe på at de prosessene som må være klare faktisk kontrolleres og følges.

Det finnes ikke noen absolutte løsninger, men det går an å ha en retning i arbeidet sitt ved alltid å prioritere idealene når det er mulig. Det går an å ha idealer i en gjennomførings-filosofi uten å bli religiøs. En god beslutning vil alltid gå på bekostning av noe som også har verdi. Hvis ikke trenger man ingen beslutning. En verdi eller en fordel har nesten alltid et positivt motstykke som må nedprioriteres. Det å beslutte at et team skal følge noen utvalgte verdier som er uttrykt i form av enkeltstående honnørord alle kan stille seg bak ikke gir så mye nytte. «Teamet skal være modig!» Hva er motstykket man kunne tenke seg å prioritere opp eller ned? At arbeidet skal baseres på feighet?

Så til prioriteringene som er valgt: Manifestet peker helt konkret på gode idealer og gir en god prioritering. Samarbeid er et gode, og ingen parter ønsker en situasjon hvor man stadig må gå tilbake til kontrakten for å avgjøre diskusjoner. Kontrakter innebærer også mye ekstraarbeid som ikke gir noe som helst produktiv verdi.

Programvare er komplisert å utvikle. Hvis det utvikles på en måte som krever mye dokumentasjon har man gått feil vei. Et system må være ganske selvdokumenterende og så ukomplisert som mulig. Og vi vet bare at vi har kommet framover når vi har fungerende programvare, aldri før.

Mennesker som er motivert for jobben og ser mening i sine egne oppgaver som en del av en helhet gjør en bedre jobb enn de som er inne for utelukkende å gjøre sin bit. Arbeidet i seg selv er krevende, og det skal tas så mange beslutninger at hver enkelt må føle sitt ansvar og prøve å jobbe best mulig sammen med andre. Kontrollerende rutiner forteller hver enkelt at de ikke blir vist tillit til å ta beslutninger, dermed må prosesser og rutiner nedskaleres, i alle fall hvis det medfører mye overvåkning og kontroll.

Til sist står prinsippet som for de fleste kjennetegner smidig, at man skal sørge for å kunne reagere raskt i stedet for å anta at prosessen kan kontrolleres gjennom en nøye gjennomtenkt plan. Er oppgaven å utføre noe som er gjort mange ganger før, og det er vist at det er mulig å repetere disse oppgavene uten spesielle hindringer, så legg en plan fra a til å. Er oppgaven å utvikle nye systemer gjelder ikke disse forutsetningene for mye av det som skal gjøres. Da er det bedre å legge en plan for hvordan man skal reagere og hvordan man skal sørge for at man kan være raskt til å omstille seg gjennom god arbeidskultur og proaktiv(!) systemutvikling.

Setningene kan godt ses på som en gjeninnføring av sunt vett i et arbeidslag som drukner i metoder og store teoretiske konstruksjoner. Så blir det en modningsprosess å gjennomføre så nær idealene det er mulig å komme. Det kan hende det tar litt tid, siden det krever utvikling av tillit og en liten porsjon mot.

Jeg har lært meg å verdsette Manifestet for smidig programvareutvikling som en god rettesnor for hvordan prosjektgjennomføring skal foregå. Det byr på klokskap i innhold, og ikke minst i form, som er en god basis for å bedømme og tilpasse et rammeverk, eller aller helst for å tenke gjennom selv hvordan det er best å jobbe.

Sivilingeniør med 15 års erfaring innen prosess- og prosjektledelse, utvikling, løsningsarkitektur og rådgivning. Han har både personalansvar og prosjektansvar.
Kontakt Anders G.: