“Hvordan kan du levere et godt produkt om du ikke bryr deg om å forstå kundens opplevelse? Kunden selv har aldri bygget kjøkken før. Det har du.”

Siden EDB kom til verden hvor vi måtte lære oss å programmere “bits & bytes” og frem til i dag, har både  kravet og egenskapene til den moderne programmereren endret seg. Fra barneårene med prøving og feiling, gjennom tenårene i kjelleren, til en voksen person som er likestilt med andre voksne jobber. Dessverre har ikke alle den samme forståelsen av hva en programmerer kan og bør gjøre. Noen programmerere er fortsatt mentalt i kjelleren og bør komme seg opp og få litt lys og oversikt. Noen ledere ser fortsatt på programmereren som “hodet” som trenger å bli fortalt hva som skal gjøres.

Programmereren har aldri vært opptatt av penger og makt (det er alltid noen unntak selvfølgelig…). Indre drivkraft har vært å løse analytiske utfordringer og få datamaskinen til å gjøre ting – gjerne nyttige ting. Man har vært opptatt av å lage, leke og lære.

Med Internett ble det raskt et behov å forstå forretning og kommunikasjon også, i tillegg til selve teknologien. Flere fagområder ble tatt inn på teamet i utviklingen av IT-systemer. Programmereren ble etterhvert degradert og plassert stillesittende i et hjørne. Flere og flere lærte seg å programmere og gjorde kompetansen tilgjengelig blant mange – ihvertfall på papiret. Håndverket er programmering. Noen kaller dem hoder, kodere eller utviklere. Og da kommer raskt assosiasjonen til nerdene som sitter nede i en mørk kjeller. Code monkeys. Gi dem dem nok bananer og la dem være i fred.

Jeg mener at alle programmerere, og prosjektdeltagere forsåvidt, kan bidra i mye større grad om vi klarer aktivisere hele mennesket i oss og fremprovosere den kollektive kunnskapen. Da vil vi ta de klokeste beslutningene. Da kan vi etterhvert også få ned størrelsen på teamene og en mye mer effektiv kommunikasjon og beslutningeprosess i utviklingen av produktet. Det krever at vi forstår programmeringens moderne rolle.

Continue reading

Som jeg lovet i DEL I, så skulle jeg dele mine erfaringer om hvorfor det er viktig å gjøre kunden god i egen organisasjon. Jeg skal også røpe noen ukonvensjonelle triks som viser hvordan du gjør dette mest effektivt.

Det vil hjelpe om vi ser dette i kontekst av tradisjonelle IT-prosjekter. Eksempelvis betyr dette at kundens prosjektleder eller produkteier, som har fått et leveranseansvar internt, vet at det egentlig kun er TO ting som betyr noe; at det leveres “noe” til avtalt tid og budsjett. Resten er i praksis underordnet.

Jeg kunne godt skrevet et helt blogginnlegg om hvor UENIG jeg er i den tradisjonelle prosjektmodellen, hvor leverandør setter nytt system i produksjon og overleverer til linjen i mottagende organisasjon. Faktum er at en denne modellen virker mot sin hensikt som er å oppnå en definert forretningsmessig verdiøkning. Men, det får vi diskutere en annen gang. Tilbake til dagens tema…

DEL II

Som konsulent har du et ansvar for å gjøre kunden god i egen organisasjon

Husker du historien om da jeg skulle kjøpe meg nye ski fra del 1 av denne bloggserien? (hvis ikke kan det være greit å friske opp minnet før du leser videre). Hva nå om jeg skulle kjøpe ski til kona. Med bestilling fra kona.

Hva ville en dårlig selger gjort? For det første så ville han ikke brydd seg om å finne ut hva dine reelle behov er (og i de fleste tilfeller så vet vi jo knappt det selv). Deretter ville han spurt deg hvilke type ski og merke du har tenkt deg. Hvis du i beste fall er så ærlig at du innrømmer å ikke helt vite det selv, så har man fortsatt en liten sjanse for at vedkommende innser at han må tilkalle forsterkninger. I realiteten ender man som regel med at selgeren finner frem 2-3 vilkårlige alternativer som du presenteres. Dette hjelper ikke særlig.

Hva gjør en god selger? Han får tankene dine bort fra pris og fokuserer på at utstyret skal passe med ditt behov og ønskede kjøreopplevelse. Det er tross alt det du vil huske resten av sesongen (prisen husker du i verste fall frem til neste lønning eller skitur).

Denne historien handler ikke om hvorvidt selgeren er sleip og har et underliggende ønske om å prakke på deg mest mulig. Den handler om konsekvensene av å føye seg etter kunden for å fremstå “hyggelig” i stedet for å gjøre kunden en ordentlig tjeneste og lære han mer om sine egne behov og presentere noen relevante løsningsalternativer. Hvis noen kommer og spør om råd, så er det som oftest fordi man trenger rådgivning. Anta da ikke at vedkommende kjenner alle sine behov. POENGET her er om man klarer å finne en løsning som vil fungere – for kona – på sikt. Det er stor fallhøyde for meg som “kundens prosjektleder” om man ikke lykkes.

Dersom kjøreopplevelsen for kona ikke er god i det lange løp pga skivalget, så hjelper det ikke lenger om skiene hadde riktig farge eller var billige nok i utgangspunktet. Opplevelsen går fra god til dårlig. Vi klarer ikke å gjøre kunden god i egen organisasjon hvis de alltid må gå fra gode til dårlige nyheter.

Bygg så store buffere du kan, men ikke si noe til kunden
De færreste produkteiere eller andre kunderepresentanter har noen formening om hvor lang tid det tar å implementere funksjon x og funksjon y. Hva det koster. En målsetning er da at man unngår å gå fra et estimat til et høyere tall i faktisk forbrukt tid. Det beste du kan gjøre – for begge parter – er å legge til grunn et best mulig rasjonale for ditt høyeste estimat.

Selv om kunden er aldri så misfornøyd med tallet du presenterer (fordi de hadde håpet at det skulle være lavere) så vil man med større trygghet kunne forklare i sin egen rapport til intern ledelse hvorfor dette er slik (intern ledelse har heller ingen forutsetning for å vite hva funksjonen koster, men forholder seg naturlig nok til budsjettet eller tidligere estimater).

Skulle du være så “snill” å gi kunden det laveste estimatet, så er risikoen langt større for at det kommer ubehagelige overraskselser senere. Ingen liker å gå fra gode nyheter til dårligere nyheter. Alle liker å gå fra dårlige nyheter (høyt estimat) til bedre nyheter (levert under estimat). Skulle det vise seg at de dårlige nyhetene (høyt estimat) forblir dårlige nyheter (leveres på tid), så har man med tiden vent seg til tanken. Det gjør ikke så vondt lenger.

Bare tenk dere forskjellen på om man i første scenario kommuniserer et “snilt” estimat på 50 timer, hvorpå sluttresultatet blir 75 timer. I scenario to argumenterer du først for et estimat nærmere 100 timer, hvorpå endelig forbrukt tid ender på 75 timer.  Hva er å foretrekke?

Det er konsulentens ansvar å lære opp kunden
Man kan ikke forvente at kunden som til vanlig jobber med et helt annet domene, skal vite hvordan et komplekst system som IT-utvikling må håndteres. Som proffesjonelle utøvere innenfor utvikling av IT-løsninger, må vi bistå en kunde og deres organisasjon konsekvensene av sine valg (både fordeler og ulemper).

Hvorfor skal vi alltid starte med å sende ut minst fem endringsmeldinger i løpet av de to første ukene i et fastprisprosjekt? Det er for å lære kundene effekten og resultatet av å “sikre seg” gjennom fastpris-avtaler. Gjør man ikke dette, så vil man for det første ende opp med at kunden ikke forstår at det koster å omprioritere ofte (det er krevende å endre kontekst ofte).I tillegg er det viktig at alle parter forstår hvordan den underliggende konsekvensen av å kjøre fastpris-prosjekter er at a) kunden ikke blir så opptatt av hva som er innenfor eller utenfor omfanget og b) leverandøren blir veldig opptatt av å ikke inkludere mer enn nødvendig i kravene. Og tilslutt endre man opp med å bruke altfor mye tid på å diskutere hva som er utenfor og innenfor oppdraget…

I smidige prosjekter sier man at man omfavner endringer. Det betyr ikke at det er uten kostnad å omprioritere og bytte kontekst ofte. Grunntanken her er at man ikke skal låse seg til en detaljert krav-/løsningsspesifikasjon gjennom et prosjekt.

Vi har alle behov for å føle oss trygge

Uansett hvilken stilling og rolle vi har fått i samfunnet, så har vi alle de samme grunnleggende behovene. Det må vi aldri glemme.Helt avslutningsvis har jeg valgt å sitere et utdrag fra en av mine tidligere bloggartikler (og starten på noe som kan bli en bok en dag), “People. Culture. Fire. A gut feeling.“:

“As a human being I am filled with emotions. Sometimes I laugh. Sometimes I cry. Sometimes I get upset, even though I´m not sure why. Sometimes I can´t control my emotions. Sometimes my pride gets in my way – in everyone’s way. Please don´t fight me. Try to see my perspective. Help me, and I will want to help you. I´m only human.”

I DEL III vil jeg dele mine erfaringer fra hvordan vår streben etter å føle kontroll og måten vi organiserer oss i realiteten undergraver vår evne til å optimalisere helheten og nå våre mål.

Bang

Om PROSJEKTSTYRING som du ikke lærer på kurs eller leser om i bøker

Hvorfor skriver jeg denne serien med blogginnlegg om prosjektstyring?

Fordi jeg ønsker å dele egne erfaringer og høre andres synspunkter om den underliggende psykologien i IT-prosjekter, og årsakssammenhenger som man ikke lærer om på kurs eller i bøker, men som er realiteten. IT-prosjekter er som egne økosystemer hvor vi må evne å gjøre bærekraftig for å lykkes. Vi må forstå hvordan enkeltelementene i dette systemet gjensidig påvirker hverandre og hva som optimaliserer helheten (understøtter primærmålet).

Skjønner vi dette så vil vi også i større grad evne å skape bærekraftige endringer i organisasjoner, men vi må gjøre det i små steg – hver dag (Kaizen).

Det er noe av det samme som Jurgen Appelo tar opp i sin nye bok Management 3.0, når han snakker om “Complexity theory” som bl.a handler om å forstå kompleksiteten i å lede endring i en organisasjon eller blant en gruppe mennesker.

Husk å dele dine erfaringer og synspunkter som kommentar til denne artikkelen når du er ferdig!

 

 

 

 

 

 

 

 

DEL I

“Vi styrer våre egne valg” – en sannhet med modifikasjoner
Jeg går inn i en sportsbutikk og skal kjøpe nye ski til skisesongen. På vei inn minner jeg meg selv på mitt “budsjett”.

Selgeren sier: – Hei, hva kan jeg hjelpe deg med?

Jeg sier: – Jeg skal ha nytt alpinutstyr. Sånne carvingski. De gamle fungerer ikke så bra lenger (Jeg tenker: “De er ikke ødelagt eller noe, men jeg føler ikke akkurat at jeg følger med i utviklingen”)

Selgeren sier: – Det finnes ulike alternativer, som varierer litt i pris ift behov og ønsket kjøreopplevelse. Fra kr 4000 til kr 10 000. Hvor mye kjører du? Mest off piste eller i preparert løype?

Jeg sier: – Ja, skjønner. (Jeg tenker: “Det eneste jeg skjønner er at jeg må revurdere budsjettet mitt.”). Jeg kjører mest i bakke, men også en del off piste (Jeg tenker: “I realiteten har jeg hatt 3-4 turer i sesongen de siste 5-6 årene, hvor jeg kun ved to tilfeller har kjørt i løssnø, som skyldtes at preppemaskinen ikke hadde kjørt bakken ennå. “)

Selgeren sier: – Hvis skal kjøre mest i preparert løype, så vil jeg anbefalle disse skiene. Bestselger, som også fungerer fint om det er litt løsnø i bakken. Ikke fullt så bra om du skal gå mye toppturer med pudderkjøring. Skiene koster kr 4999, men vi har de også i et pakketilbud med støvler, bindinger og staver til kr 8 900. Vi har solgt masse av disse. Jeg kjører selv på fjorårsmodellen og hadde en sinnsyk god opplevelse i de franske alpene. Da har du utstyr i mange år fremover. Aksel Lund Svindal kjører med samme merket.

Jeg sier: (Jeg tenker: “Aksel Lund Svindal – kult!. Det må jeg bare fortelle gutta! Han sa jo også at det var en bestselger. Nå må jeg bare ikke virke for ivrig. Prute litt”). Det var litt stiv pris, synes jeg.

Selgeren sier: – Vi har også andre ski som er på tilbud. Bl.a et par fra en modell som utgikk i fjor.

Jeg sier: – Men, som du sier så vil jeg ha utstyret i mange år fremover. (Din rasjonelle hjernehalvdel rettferdiggjør valget og valget ditt bør fremstå veloverveid.). Det er greit. Jeg tar dem. Ha´kke tid til å stå her. Må komme meg ut i pudderet, vet du! (Jeg tenker: “Pudder? Takket jeg ikke nettopp ja til ski som var best egnet i preparert løype?…”). Takk for hjelpen!

Denne historien illustrerer i hvor stor grad den emosjonelle delen av hjernen vår påvirker våre valg. Det meste handler om det vi opplever som “magefølelsen” (som egentlig er Det Limbiske System i hjernen som driver følelser og oppførsel hos mennesker) og gir oss en sterk indikasjon på hva vi virkelig ønsker, mens vårt rasjonelle “jeg” febrilsk jobber med å rettferdiggjøre valget. Dette betyr i praksis at vi er mer opptatt av hva andre mener om oss, enn resultatene vi skaper. Det er et helt grunnleggende og naturlig instinkt for de fleste av oss.

Hva gjør en god konsulent her?

Det er ikke selgeren som tar valget, han bare legger frem alternativene så jeg skal kunne gjøre det beste valget utifra mine behov. Problemet oppstår så snart jeg ikke helt vet hva mine behov er. Kanskje burde jeg lånt med meg to par ski og kjørt dem en uke, for så å kjøpe paret som fungerte best i “produksjon”?

En virkelig god selger ville foreslått nettopp utlån av ski, for å sikre at jeg gjorde et godt valg.

Denne problemstillingen er velkjent når man jobber med produktutvikling og er nærmere utredet i artikkelen om “The User Feedback Problem”

Hovedpoenget mitt her er at vi må bedre forstå det underliggende behovet hos våre kunder. Vi må både forstå hva bedriften trenger, samtidig som vi forstår hva kundens produkteier eller prosjektleder trenger for å gjøre gode valg. Forstå hvilket enormt press det innbærer å stå mellom leverandøren og sin egen ledelse. Det holder ikke å bare avfeie folk med “Å, de skjønner jo ingenting!”.

Hvis kunden forstår hvorfor og selv kan ta nødvendige valg fordi vi er flinke til å presentere valgalternativene med fordeler og ulemper, så blir det enklere å forsvare det mot egen styringsgruppe eller ledelse. Da er også sannsynligheten større for at man vil se på arbeidet som vellykket fordi man tok det beste valget i rådende situasjon (man hadde tross alt ikke noen bedre alternativer).

Som konsulent så forplikter du å gjøre mer enn “jobben din”, om det være seg programmere, designe eller å teste. Du forplikter å gjøre kundens jobb så enkel som mulig. Husk at det er ikke engang sikkert vedkommende har bedt om å bli prosjektleder eller produkteier for et IT-prosjekt (i tillegg til jobben i linja). Ta ansvar og bry dere om hverandre. Vi er ikke roboter, men mennesker med kjøtt, blod og følelser – masse følelser.

Hvilke tanker vekker dette hos deg?

 

Neste gang skal jeg ta utdype dette som er din viktigste oppgave som konsulent, rådgiver eller leverandør; nemlig å gjøre kunden god i egen organisasjon.

 

Bang

I systemutvikling er Kanban en metode som passer spesielt godt til vedlikeholdsprosjekter. Når man snakker om smidig utvikling tar man ofte for gitt at man vil jobbe Scrum. Erfaringsmessig fungerer ikke Scrum like bra i alle typer situasjoner. Når det gjelder vedlikeholdsprosjekter møter man mange utfordringer med Scrum. Mange av utfordringene kan løses ved å bruke Kanban-metodikken.

Hovedutfordringen med Scrum i et vedlikeholdsprosjekt er uforutsigbarheten som ligger i et slikt prosjekts natur. Kanban er laget for å håndtere uforutsigbarhet og passer derfor godt.

Kanban baserer seg, som Scrum, i stor grad på empiri og prosessforbedringsteori. Hovedtankene er tatt fra Lean og involverer prinsipper som ”Eliminate Waste”, ”Pull Scheduling”, ”Stop the Line” og ”Just in Time”. Reglene for Kanban er enklere og krever litt mer av team og kunde, men fungerer erfaringsmessig meget bra for vedlikehold av programvare.

Kanban-regler

Det er tre regler man må følge i Kanban:

• Visualiser arbeidsflyten: Som i Scrum er det viktig å visualisere flyt. Dette gjøres enkelt ved å benytte en tavle og Kanban-kort som representerer oppgavene.
• Reduser samtidig arbeidsmengde: Det er et mål å ha så korte køer som mulig. Det vil si at man skal redusere antall samtidige oppgaver. Dette sørger for at flere oppgaver blir løst på kortere tid og at man får en bedre flyt i arbeidet.
• Mål gjennomstrømningstid: For å kunne forbedre prosessen må man kunne måle resultatet av endringer. Ved å måle tiden fra et problem dukker opp til det er løst og satt i produksjon, kan man lett måle om endringer gjør denne tiden lengre eller kortere.

Kanban-kort

Et Kanban-kort representerer en oppgave. Man kan sette regler for at ingen kan jobbe på mer enn én oppgave av gangen, men man åpner for at flere kan jobbe på samme oppgave. Dette er aktuelt for eksempel i forbindelse med parprogrammering. Et Kanban-kort inneholder informasjon om hvilken oppgave det gjelder, gjerne en ID til et issue tracker-system, hvem som utvikler, hvem som tar QA, og revisjonsnummer fra versjonskontrollsystemet.

Kanban-tavle

En Kanban-tavle er veldig lik en Scrum-tavle. Det viktigste er at den visualiserer den faktiske arbeidsprosessen. På denne måten kan man lett se hvor køene oppstår Bildet under viser tydelig at man har altfor mange åpne QA-oppgaver.

Dette løses opp i ved å sette grenser for antall samtidige arbeidsoppgaver for å sikre flyt. Dette er gjort på bildet under.

Begrense antall samtidige oppgaver.

Det viktigste prinsippet for å sikre god flyt er å redusere antall køer og lengden på de køene man må ha. Dette må man eksperimentere med samtidig som man måler gjennomstrømningshastigheten for å finne de reglene og begrensningene som gir best flyt. I noen tilfeller kan det faktisk være at man må ha færre åpne oppgaver enn man er teammedlemmer. Kanskje kan et team på 10 personer bare ha 5 åpne oppgaver totalt. Dette vil måtte løses ved bruk av parprogrammering, noe som vil kunne øke hastigheten totalt sett.

Daglig møte

Daglig møte er ikke noe krav i Kanban, men en god skikk å ta med seg fra Scrum. En viktig forskjell er at man skifter fra å stille de tre klassiske spørsmålene fra Scrum og heller fokuserer på arbeidsoppgavene på tavla. Man går igjennom oppgavene og spør hver enkelt oppgave: “Hva kan vi gjøre for deg, kjære arbeidsoppgave, så du blir løst raskest mulig?”. Dette øker fokuset på oppgavene betraktelig og er med på å holde flyten oppe.

Hva skiller Kanban fra Scrum?

I korte trekk er det fravær av sprinter som er den største overgangen. Dette vil gi betraktelig bedre respons fra teamet og man vil kunne gjøre de viktigste tingene ferdig og produksjonsklare først uten å måtte vente på at alle andre oppgaver i sprinten skal bli ferdig.

Det åpner igjen for hyppigere utrulling av produksjonsklar kode, noe som minsker tiden før tilbakemeldinger kommer tilbake til utvikler, som igjen gjør eventuell feilretting enda raskere. En god sirkel, men andre ord.

Ulempen med Kanban er man ikke har sprintene som forutsigbare leveranser. Når man driver et vedlikeholdsprosjekt må man vurdere om man vil bytte ut denne forutsigbarheten med muligheten for raskere og mer effektivt vedlikehold.

Kanban sier heller ingenting om roller. Erfaringsmessig er rollene i Scrum godt definerte og fungerer fint sammen, så det er god praksis å fortsette med Produkteier og Scrum Master. I tillegg tar man med seg retrospektivet fra Scrum, som et hjelpemiddel for å forbedre prosessen.