“Honesty and Visibility” – verdier som gir effekt
“Hvorfor i huleste er det blitt så populært å klistre opp disse lappene på veggene?”
Jeg har selv fortalt ivrig om hvordan mange Scrum Team foretrekker Task Board fremfor IT-verktøy når de håndterer Sprint Backlog’en. Med et lite skjevt smil om munnen, som om dette bare var en artig kuriositet. Selv om teamet er samlokalisert og sitter med de samme dataverktøyene for hånden foretrekker de det intuitive og svært konkrete i disse lappene. Hver lapp representerer en konkret oppgave – og når vi koordinerer oss (blant annet i de daglige små møtene) gjør vi det rett foran Task Boardet.
Vi vet jo at Lean og Scrum verdsetter det å gjøre informasjon lett tilgjengelig høyt. At “kommunikasjon er viktig” uttaler vi til det kjedsommelige. Men hvor mange har forstått potensialet? Klarer vi virkelig å profittere på dette?
For å kommunisere status
Jeg har ganske nylig diskutert dette med ulike firmaer som har erfaring med Scrum. Typiske “ScrumButt” tilfeller (for de som ikke vet det, ScrumButt er Jeff Sutherlands merkelapp på alle utilstrekkelige Scrum implementasjoner. “I’m using Scrum, But …” fyll inn det som passer).
De uttaler typisk slikt som:
“Nei, vi skjuler ingenting, vi verdsetter åpenhet! Sprint Backloggen ligger på L:/Documents/Projects/MyProject/Scrum/SprintBacklog12. Hvis du mounter fellesdisken med L: da. Nei forresten jeg tror den heter SprintBacklog13 nå. “
Eller:
“Nei, vi skjuler ingenting, vi verdsetter åpenhet! Sprint Backloggen ligger i ScrumWorks. Du kan installere gratisversjonen av ScrumWorks fra denne linken: blablablabla. Og så må du søke på MyProject. Husk å filtrere på Sprint nr 13.”
Selv om vi jobber i IT-bransjen bør vi kunne innrømme at dataverktøy ikke alltid er det beste. Det som virker veldig lett tilgjengelig for de som sitter tett på teknologien kan ha høye terskeler for andre. Jeg anbefaler ofte Jira som verktøy for både Product Backlog og Sprint Backlog. Jira er ikke spesielt lett tilgjengelig for andre enn utviklerne, men da har man Confluence – et Wiki-verktøy som er veldig god på å publisere data fra Jira. Flott! Men skal man nå ut av utviklingsavdelingen med informasjonen må de da forholde seg til Confluence. Ikke alle på salg eller i ledergruppa ønsker å ha et forhold til dette verktøyet. Har man et velfungerende intranett – som de ansatte har flere grunner til å besøke hver dag – kan dette være et godt hjelpemiddel for å øke synligheten av det som foregår. Men du er da fremdeles prisgitt dataskjermens begrensninger.
Skal vi virkelig lykkes med kommunikasjon må vi bruke mye mer visuelle og ikke-tekniske hjempemidler. Lapper-på-veggen-verktøyet kan med fordel benyttes til mer enn Task Board. Fordelene her er mange:
- Gir et visuelt, oversiktelig øyeblikksbilde
- Har en lokal tilhøringhet – man må oppsøke de som er tettest på informasjonen
- Trigger lett kreativitet – det er lett å gjøre små endringer for å prøve ut en ide
Toyota er fullstendig oppslukt av synlighet. De oppfatter det slik at det å putte informasjon inn i maskiner reduserer synligheten. I stedet bruker de gjerne store tavler og kort for å visualisere prosessene og hva som faktisk foregår. “Learn to see Waste” er en viktig verdi og da må så mye som mulig være oppe i dagen. Kanban er kanskje den mest kjente teknikken, der de lar fysiske små enheter (ofte kort) representere kapasiteten til et system. Når man skal oppnå Just-in-time flow er det viktigt at flyten inn er regulert av kapasiteten og en Kanban signaliserer da oppover at når man er klar til å ta imot med arbeid.
Om det var Toyota eller Allistair Cocburn som var først ute med begrepet Information Radiator skal være usagt, men ideen her er å avsette veggplass til å tydelig vise fram statusinformasjon. Vi må ikke være redd for å synliggjøre problemer, vi vil i det lange løp vinne på full gjennomsiktighet. Et synlig problem kan løses. Jeg har nevnt det før, men jeg synes det er så lysende eksempel: På en av de mest vellykkede bilfabrikkene til Toyota har de malt noen spesielle skorsteinspiper signalgule. Dette fordi det gir mest mulig kontrast mot sot. De eksponerer da problemet soting for hele verden – slik at de kan reagere og sette igang rengjøring på et riktigst mulig tidspunkt.
Som samarbeidshjelpemiddel
Jeg har forsøkt en del ulike samarbeidsformer – som foreksempel å bruke word sin “track changes” med tilbehør. Vi skal da i samarbeid produsere ett dokument eller en eneste leveranse. Den sikreste måten å “samarbeide” på er mye brukt – en person lager et utkast og sender så dokumentet på høring. Og så får man forsøke å flette inn alle kommentarene i etterkant. La oss indelig håpe at vi ikke får kommentarer som er i konflikt med hverandre, eller at kommentarene går på helt grunnleggende uenighet om premissene for dokumentet! Litt bedre er det å ta fram dokumentet i fellesskap gjennom å holde rede på hvem som jobber med hva og hva som er gjeldende revisjon. Vi slipper allikevel ikke unna en slags sekvensiell arbeidsflyt. Og min erfaring er entydig – dette skalerer dårlig! Når dokumentet blir stort vil det å holde rede på endringene samtidig som helheten skal ivaretas blir uhyggelig arbeidskrevende. Dessuten vil en eller noe ytterst få personer eie dokumentet og resultatet, mens de som har vært involvert vil ha lagt lite av sjela si i produktet.
Skal vi klare å få på plass virkelig, tett, tverrfaglig samarbeide – i meningen at mange personer involveres tett i å komme fram til sluttresultatet – må vi riste av oss denne vanen med å lage ett dokument. Vi kan stykke opp informasjonen i små fragmenter som vi til slutt pusler sammen til en helhet. Dette er jo en velkjent idé-dugnad teknikk som nettopp er laget for å engasjere mange mennesker i paralell og i tett samarbeid. Det er utrolig hvor mye en sammensveiset gruppe mennesker kan få utrettet i løpet av to dagers workshop med lapper-på-veggen som drivkraft. Arbeidskrevende (utmattende vil noen si) javel, men med svært vel utnyttet kalendertid.
Denne formen for samarbeid anbefales sterkt når man skal starte en større satsning (noen kaller dette et prosjekt) og utarbeide en Product Backlog (PB). En PB er jo en prioritert liste over funksjonalitet der elementene i utgangspunktet er ganske friboblet fra hverandre. Ved å samle interessentene sammen med teamet som skal gjøre jobben i la oss si 2 dager klan man oppnå veldig mye. Men det betinger at man har en ganske strukturert prosess og har et klart mål. 
En god PB består av bolker med funksjoner som til sammen utgjør en slags minimums-funksjonalitet. En slik bolk skal det være mulig å lage 100% ferdig slik at den kan demonstreres og aksepteres. Den skal ideelt sett ha en så stor verdi for brukerne et den kan releases – i så fall kalles dette gjerne Minimal Marketable Feature (MMF). Identifiser de viktigste brukerne og deres arbeidsprosesser som skal støttes. Prioriter og detaljer de viktigste av disse – de nest viktigste kan vi la ligge. Denne formen for forarbeid kalles gjerne Feature Mapping.
Om man velger å bruke User Story formatet kalles det User Story Mapping som Jeff Patton har beskrevet her, og som Nils Christian Haugen presenterte på Smidig2008.
Teknikken er også velegnet og mye brukt i forbindelse med erfaringsmøter (Retrospectives på Scrumsk). Her er det utrolig viktig at alle i teamet engasjerer seg slik at alle føler eierskap til prosessen og resultatene i form av forbedringsområder.
“De beste i klassen” tenker nytt også på området kommunikasjon. Overraskende nok er svaret denne gangen mindre og ikke mer teknologi!
In: Lean, Scrum · Tagged with: kommunikasjon