(Noen har nettopp brukket bygget til Kent)

Lærdommen fra vår uke sammen med Kent begynner dessuten å synke inn. Vi har et lite forsprang på gutta boyz og the girl power på kontoret nå, men det varer ikke lenge. Vi er ivrige på å bringe kunnskapen videre, og våre kolleger plukker kjapt opp poengene.

Iterate har et større prosjekt på trappene og selv klør jeg i fingrene etter å komme igang og anvende ny kunnskap. Dette er med en kunde som ikke driver med IT-utvikling selv, men som på andre områder har fokus på arbeidsprosesser, verdiskapning og riktig bruk av mennesker. Vi har hatt et oppdrag for dem tidligere og opplevde svært raskt at et felles tankesett er en stor fordel for begge parter: “Hvorfor jobber ikke alle på denne måten?” var deres første kommentar da vi foreslo en smidig metodikk for gjennomføringen av prosjektet.

“Våre folk er svært kompetente, og derfor tror vi det er lurere å la dem finne den beste måten å jobbe på selv, fremfor utførlige prosessbeskrivelser”. Vi la diplomatisk frem vårt budskap, og det ble mottatt litt på samme måte som om man gir noen en paraply i kraftig regnvær. Det er herlig med slike kunder. Ikke minst fordi vi vet så inderlig godt at det er dette som gir dem mest verdi for pengene.

Dette med felles tankesett – og det motsatte – var også noe som opptok Kent. Jeg var innom temaet i innlegget om fremtidens IT-prosjekter. Her spør Kent hvorfor det er så vanskelig for fagfolk fra den tradisjonelle skolen å forholde seg til smidige fagfolk. Og vice versa. Han tror svaret ligger i verktøy, teknologier, metoder og andre aspekter ved vår arbeidsmåte. De verktøyene man trenger i et tradisjonelt prosjekt er kanskje unødvendige i et smidig prosjekt, og omvendt. Og så videre.

I denne øvelsen har Kent kategorisert metodikkene etter lengden på leveransesyklene. Et tradisjonelt prosjekt har én syklus. Et intenst, XP-drevet prosjekt leverer flere ganger om dagen. Mellom disse ytterpunktene finner vi mer kjente metoder som Scrum, RUP og andre iterative tilnærminger. For å komme nærmere spørsmålet om hva som skaper den ofte følte avgrunnen mellom tradisjonell tankegang og smidig, stilte jeg Kent spørsmålet om det var noe de to ytterpunktene hadde til felles. Han hadde ikke noe svar. Før idag.

Kent er en ivrig tilhenger av det som kalles Appreciative Inquiry. “Når vi ingeniører skal løse en vanskelig situasjon, skal vi alltid begynne med å ramse opp og kategorisere alle problemene vi har sett”. Det var tydelig at han hadde gått frem på denne måten mange ganger. “Så skal vi prioritere alle problemene og deretter gå for å løse de vi anser som viktigst. Det vi i praksis gjør i en slik situasjon er å be alle i rommet tenke hardt på hvordan vi har gjort idiotiske ting, tenkt dumt og feilet – Hvor gode løsninger tror dere vi finner i en slik sammenheng?” Appreciative Inquiry dreier seg om å jobbe seg frem til gode løsninger gjennom å fokusere på det som har vært positivt. Ved første tanke høres det kanskje unnvikende og feigt ut. Men som Kent påpeker kan AI være vel så tøft som klassisk problemløsning. Poenget er i all hovedsak å finne løsninger, fremfor å grave frem problemer man kanskje hadde lagt bak seg.

Det var altså AI som satte meg på sporet av spørsmålet Kent ikke kunne svare på. I et forsøk på å gå ut av skyttergraven og tenke positivt om tradisjonell prosjektmetodikk (du er herved utfordret!), prøvde å jeg finne områder vi har til felles. Kanskje dette kan være veien til stadig bedre måter å jobbe med programvareutvikling på?

Snart starter vi forøvrig opp ukentlig coaching med Kent. Dagboken fortsetter fra det vi behandler i disse sesjonene.