Grunnpillarer i IT: Feedback

I innlegget om læring argumenterer jeg for at læring er den mest sentrale aktiviteten i IT-utvikling. Dersom man er enig i dette argumentet, så blir et naturlig neste spørsmål: Hvordan kan vi legge til rette for at læring skjer mest mulig effektivt?

Til dette spørsmålet finnes det mange svar (den som ønsker å lære vil sannsynligvis stadig finne flere og bedre måter å gjøre det på). Og for oss som er glade i smidig programvareutvikling så har det stadig kommet nye idéer og løsninger som bidrar til dette. Ser man på mange av disse teknikkene, så ser man at det veldig ofte er et tema som går igjen, og det er feedback. Og i nesten alle tilfeller så er fokus raskere feedback.

Fra de siste prosjektene jeg har jobbet på har vi blant annet fått bedre feedback ved å gjøre følgende:

• Ved å bruke test-drevet design/utvikling (TDD) får jeg rask feedback om koden jeg skriver fungerer, og om koden jeg skriver har ødelagt annen funksjonalitet
• Ved å bruke parprogrammering (to utviklere sitter sammen og jobber) får jeg rask feedback på idéene mine og koden min fra den jeg jobber med
• Ved å bruke feature teams (alle som trengs for å løse oppgaven er i samme tverrrfaglige team) får jeg rask tilgang på og feedback fra folk med kompetansen som trengs for å komme videre
• Ved å ha jevnlige retrospectives (evalueringsmøter internt i teamet) får vi jevnlig gitt feedback til hverandre, slik at vi stadig finner bedre måter å jobbe på
• Ved å jobbe fokusert med få oppgaver av gangen (redusert «work-in-progress», WIP) blir oppgavene raskt fullført, og vi får rask feedback på om det vi har laget fungerer
• Ved å bruke kontinuerlig leveranse («continuous delivery» – automatisering av releaseprosessen) kan jeg levere nye versjoner ofte, slik at jeg får rask feedback fra kundene mine

Legg merke til at de forskjellige typene tilbakemelding kommer fra mennesker i forskjellige roller, og på forskjellige tidspunkt i utviklingsprosessen. Figuren under illustrerer dette:

Alle disse feedback-sløyfene er viktige. Hvis du jobber med et produkt eller i et prosjekt der én eller flere av disse mangler, så øker du risikoen for at din bedrift kaster bort tiden sin eller taper i konkurransen mot de som faktisk mestrer dette.

Et annet relevant spørsmål i denne sammenhengen er:

Fra hvem / på hvilket nivå er feedback viktigst? 

Det finnes flere gode svaralternativer her, og hvis du spør personer i forskjellige roller vil du kanskje få forskjellige svar. Jeg vil imidlertid argumentere for at den aller viktigste feedbacken vi får er fra kunden (eller brukeren). Hovedårsaken til dette er å finne i hensikten med hele aktiviteten vår: Vi lager IT-systemer fordi det skaper verdi for kunden/brukerne. Uten en validering av at det vi lager har verdi risikerer vi å lage ubrukelige løsninger. Mary og Tom Poppendieck skriver at den mest bortkastede tiden er den man bruker på features som ikke brukes.

Det er utfordrende å bygge en organisasjon som har rask feedback på alle nivåer, men belønningen er stor. I fremtidige innlegg vil jeg komme inn temaer som er til hjelp på veien dit.

For deg som vil lære mer:

• Implementing Lean Software Development, Mary og Tom Poppendieck. En fin gjennomgang av prinsipper og praksis som er nyttige for å lykkes med programvareutvikling
• Continuous Delivery – David Farley & Jez Humble. «Bibelen» på kontinuerlig leveranse. En omfattende gjennomgang av de fleste relevante aspekter rundt det å levere programvare kontinuerlig
• Smidig («agile») programvareutvikling.  Wikipedias artikkel om temaet
• Test Driven Development: By Example – Kent Beck . Lærebok i bruk av TDD
• Agile Retrospectives – Esther Derby & Diana Larsen. Lærebok om retrospectives som inkluderer et stort utvalg øvelser man kan bruke

Bilde: pixabay.com