Planlegging eller kommunikasjon?

«Skjer ‘a?» Det er nesten vanskelig å tenke tilbake på tiden før mobiltelefon. Tiden da man måtte planlegge «vi møtes ved kinoen klokken 20:00, og dersom noe går galt, så møtes vi i stedet ved billettluka 21:00». Tiden da man måtte legge igjen en beskjed, eller låne en telefon for å ringe hjem for, ja nettopp, høre om noen hadde lagt igjen beskjed. Normalen i dag er at man har en omtrentlig plan «og så ringes vi når jeg er på vei til byen.» Fordelen er at man kan tilpasse seg. «Jeg har hørt at Ole feirer 35 år. Skal vi stikke innom i stedet for å gå på bar?»

Dette er et eksempel på hvordan kommunikasjon erstatter planlegging. Slik kan det også være i prosjekter. Man må være enige om hva målet med prosjektet er, men dersom man kommuniserer underveis, kan de nøyaktige midlene bli til underveis.

Nesten daglig sitt-ned-møte

Mange bruker «daglige stå-opp møter» i Scrum. Teamet står rundt tavla og koordinerer utførte, pågående og kommende oppgaver. På mitt forrige prosjekt ble vi inspirert av en blogpost til å utvide stå-opp møtet med et «nesten daglig sitt-ned møte» når det var hensiktsmessig.

På stå-opp møtet gikk vi gjennom hvilke oppgaver utviklerne hadde gjort ferdig, og hvilke oppgaver produkteier hadde sett gjennom. Etter stå-opp møtet satt produkteieren og utviklerne seg sammen og gikk inn i detaljene:

  • Produkteier hadde med seg en liste med forbedringer fra tidligere funksjoner. De forbedringene som tok under 2 minutter å utføre gjorde utvikleren der og da. Oppgaver som ville ta litt lengre tid noterte utvikleren seg. Oppgaver som var for omfattende ble tatt inn i fremtidige planer.
  • Utvikleren viste produkteieren de tingene som var «ferdige» i går. Produkteieren kom med direkte feedback der og da, og noterte seg hva han skulle seg gjennom på egen hånd.
  • Produkteieren gikk gjennom detaljene for funksjonalitet som utvikleren skulle starte på og besvarte spørsmål

«Jeg vet det når jeg ser det»

«Measure twice, cut once» er det noen som sier. Men på utviklingsprosjekter er det slettes ikke sikkert at det å beskrive noe ekstra grundig forbedrer sjansene for å lykkes. De eneste gangene jeg har opplevd at en kunde ikke kommer med tilbakemelding første gang hun ser produktet er når jeg har en kunde som egentlig ikke bryr seg. Eller når jeg hadde brukt alt for lang tid på å dekke alle eventualiteter, inkludert de som ikke var kostnadeffektive.

I et vellykket prosjekt vil prøving, visning og tilpasning være normalen. Jo tidligere prosjektet får tilbakemeldingene, desto bedre og billigere blir prosjektet. Og jo mer nøyaktige planer vi legger i prosjektet, desto vanskeligere blir det å tilpasse seg tilbakemeldingene.

Felles mål, daglig kontakt, daglig tilbakemelding og daglig tilpasning vinner over grundige planer.

Legg inn en kommentar