Produkttankesett i digital produktutvikling. Hva betyr det for teamene?
Produkttankesett — i myndiggjorte autonome team med psykologisk trygghet.
I forrige bloggpost skrev jeg om produktutvikling og produkttransformasjon. Det kan ses på som en evolusjon og videreutvikling av smidig utvikling. Hva skal til og hvordan vil dette påvirker utviklingsteamene? For å lykkes med en produkttransformasjon må også kulturen og menneskene støtte opp om den — de må skape et produkttankesett. Dette tankesettet vil ofte påvirke hvordan teamene og medlemmene arbeider og tenker.
«Vi trenger team med misjonærer, ikke team med leiesoldater.» — John Doerr
Tankesett
Et produkttankesett en helhetlig tilnærming for å skape verdi til brukerne eller kundene. Den fokuserer på kontinuerlig utforskning, utvikling og datadrevne desentrale beslutninger. Teammedlemmene arbeider i myndiggjorte autonome team, og er ‘besatt’ av brukeren eller kunden for å skape gode opplevelser. Suksess måles i verdien man skaper for brukerne eller kundene og for virksomheten. Med et ende til ende syn på produktet arbeider IT med å løse brukerbehov, forretningsproblemer og levere løsninger — i stedet for ressurser og timer. Målet er ofte at produktet skal bli sett, brukt, likt og anbefalt av brukerne til andre.
«Leiesoldater utvikler det de blir bedt om å utvikle. Misjonærer tror på produktvisjonen og er til for å løse problemer for brukerne eller kundene sine.» — Marty Cagan
Endringen til et slikt tankesett kan være er en stor transformasjon — alle må arbeide sammen for å sette brukerne eller kundenes behov først og kontinuerlig forbedre produktene. Det er en videreutvikling av det smidige tankesettet, og det krever fokus på virksomhetens mål i stedet for kortsiktige tiltak og leveransefokus. Teamene vektlegger outcome og produktets innvirkning — mer enn leveransene, tidsplaner og budsjetter. Målene er ofte å skape begeistring for produktet, løse jobben som brukeren ønsker å få utført (jobs to be done), vinne markedsandeler eller bygge merkevare.
Suksesskriteriet er gode bruker- eller kundeopplevelser gjerne utrykt i en visjon, strategi og en roadmap som sikrer hyppige leveranser av verdi, basert på innsikt og utvikling av det riktige produktet. Produktutviklingsfelleskapene har ikke utarbeidet et manifest, men noen av verdiene i tillegg til de smidige kan være:
- Outcome og ønsket innvirknig fremfor utvikling av features
- Løse problemer fremfor implementere løsninger
- Utforskning av hypoteser fremfor meninger og tiltak
- Empati med brukeren fremfor antagelser om brukerbehov
Med et grunnleggende syn på teammedlemmene som kunnskapsarbeidere kan tankesettet, verdiene og prinsippene kanskje uttrykkes slik:
På samme måte bygger praksiser på de smidige praksisene med fokus på samskaping, myndiggjorte autonome team, digital ledelse og ulike praksiser for utforskning. Tilsvarende benytter man flere varianter av moderne prosesser, teknikker og nyere verktøy som støtter opp om dem.
Kultur
Det handler om å skape en kultur som gjør det mulig for virksomheten og teamene å være dynamiske, utforskende, innovative, og tilpasningsdyktige i en verden preget av stadige endringer og høy grad av usikkerhet. Den bygger videre på den smidige kulturen som flere kjenner. Virksomhetene må bygge en kultur som verdsetter tillit, samskaping, mangfold og autonomi. Der teamene og teammedlemmene som utgjør kulturen, utvikler et mer utviklings-, vekst- og mulighetsorientert tankesett. Ledelsen må snakke om og ta inn over seg usikkerhet. Det vil kreve litt mot men vil skape trygghet i teamene at de snakker om det kjente ukjente. Det man ikke kjenner til og hvordan vi går videre for å finne ut mer. Før man bestemmer seg hva som er løsningen og når det skal være ferdig.
K. Omholt sammenlignet det veldig bra med Pippi Langstrømpe «Dette har jeg aldri gjort før, så det klarer jeg helt sikkert».
Psykologisk trygghet
Team i en åpen og tillitsbasert kultur der teammedlemmene har psykologisk trygghet og arbeider i myndiggjorte autonome team med et klart ansvar, viser både erfaring med og forskning på slike at de er bedre og mer effektive. Det er en sterk sammenheng mellom teamenes mulighet til selvorganisering og psykologisk trygghet, og en sammenheng mellom psykologisk trygghet og teamets produktivitet og evne til å lære. Den autonomien teamet får, gjør medlemmene mer villige til å eksperimentere, ta initiativ, utforske nye løsninger og øker evnen til innovasjon. Autonomi bidrar til høyere psykologisk trygghet, og øker teamets evne til å utvikle seg, lære og forbedre seg.
«Det er ikke noe du kan vedta, det er noe du må gjøre, og du må gjøre det hver dag og du må fortsette å gjøre det.» — Marte Pettersen Buvik
Teamene
For teamene vil det selvfølgelig variere avhengig av hvor man er og hvor langt man har kommet. Tradisjonelle utviklingsteam som kjører Scrum og ‘spiser’ ferdigprioritert backlogg med stor presisjon, har et forbedringspotensiale. Mens andre team har kommet lengre. Dette varierer fra team til team i samme virksomhet, og i enda større grad mellom virksomheter.
Den største forskjellen for tradisjonelle utviklingsteam er å arbeide mer med utforskning; hva skal man utvikle og hvorfor. Eller for andre er spørsmålet om de får lov til å delta i utforskningen. Den andre store forskjellen er at teamet må ta mer ansvar for å utarbeide sin visjon, strategi, mål og roadmap. Dette selvfølgelig sammen med ledelsen og innenfor virksomhetens og eventuelt avdelingens sine. Teamene må ha mindre fokus på bestillinger og backlogg, og mer fokus på hvilke problemer de skal vi løse.
Kravene er ikke diktert til teamet men de er aktivt med i utforskning av behov, problemer og løsninger.
Forskjellen mellom leveranse- og produktteam er fokuset på å oppnå bruker og kunderesultater, ikke utelukkende fokus på produksjon og levering. De er myndiggjorte, prioriterer og optimaliserer for verdi og kvalitet. Er f.eks. løsningen bærekraftig, gjennom hele kodebasens livsløp. Det er ingen lett oppgave å endre tankesettet men det finnes mange eksempler, bøker og bloggposter skrevet i de siste årene om produktutvikling, produktledelse og utforskning som kilde til inspirasjon og kunnskap.
For at dette skal virke må teamene være transparente på prosessen og resultatene. Både vertikalt og horisontalt slik at ledelsen får tillitt og at andre team ser hvor de er på vei. Være proaktive og kommunisere til ledelsen hvilken innvirkning tiltakene har, for å dreie fokus bort fra tiltakslyst og over på behov og problemløsning.
En annen konsekvens ved at man utvider fokuset mer mot utforsking er at teamene kan få behov for mer breddekompetanse og tverrfaglighet. Det er kanskje ikke lengre nok å bare ha en designer i utviklingsteamet. Tradisjonelle utviklingsteam må ofte bygge ny kompetanse eller få inn ny kompetanse i form av nye medlemmer.
Noen kan også opptrer som kunnskapsmeglere og grensekrysser mellom teamet og andre team og kompetanseområder. Eller benytte teknikker som f.eks. Event Storming for å tilegne seg domenekunnskap for å forstå hvor man skal og hvorfor.
Hvordan får man det til? En av de viktigste praksisene er å komme i gang for å lære. Starte opp med utforsking og utvikling samtidig, på samme plass, sammen og i samme team. Utviklere og design/UX må være tidlig involvert i utforskning for å unngå kunnskapsoverføring og overlevering med alle de utfordringene det medfører.
I noen tradisjonelle utviklingsteam er behovet ofte fremstilt i form av en ferdig spesifikasjon, enn hva som egentlig skal oppnås. Det kan derfor være en utfordring å løfte seg opp for å utforske problemstillingen. Skaffe seg oversikt, tenke kreativt som utenforstående hvorfor og hva skal egentlig løses. Vurdere forskjellige muligheter for å oppnå samme effekten med innsikt og eksperimentering.
Ikke se skogen for bare trær — det er slik vi alltid har gjort det!
Teamet må arbeide med ulike teknikker for å være spørrende, nysgjerrig og kritisk til nye oppgaver. Ta ansvar for å forstå hva de egentlig ønsker å oppnå. Utforske hvordan problemet passer inn i en større sammenheng, for å se verdien og jobben som brukeren ønsker å utføre. Dette medfører ofte erkjennelsen av at man vet ikke alt, og teamet må arbeide for å lære mer. Hvordan går vi frem for å skaffe oss mer innsikt. Vi har ofte en forutinntatt holdning til å for tidlig bestemme oss for løsningen. Før vi har forstått problemet.
Være lojal til hensikten og stille spørsmål med hvorfor og hva — ikke bare være lydig til planen.
Dette arbeidet blir mer viktig ved at det handler mindre om tradisjonelle prosesser enn tidligere. Utforskning er viktig men teamene må også arbeide med å utvikle litt, måle, skaffe seg innsikt og forståelse, tilpasse og utvikle litt til. I motsetning til å ‘spise’ backlogg: ferdig — neste, ferdig — neste.
For å kunne arbeide mer med utforskning må teamet ha slack slik at de kan få frem kreativiteten og læringen. Det er en utfordring med å ha for mange baller i luften, og teamet må arbeide aktivt for å redusere WIP. Fokusere på et behov, problem eller domene som f.eks. Amazon sitt konsept ‘Single-threaded team’.
Teamledelse
Arbeid i myndiggjorte autonome team er utfordrende og teamledelse blir enda viktigere. Den tradisjonelle produkteieren eller Scrum Masteren er ikke nok. Veldig gode team løser dette med selvledelse og selvorganisering, men det er vanskelig å få til og krever erfaring. Team- eller produktledelse er ikke det samme som prosjektledelse eller produkteierskap. Det er ofte ikke mulig å gjøre samme jobben samtidig av en person. Det er forskjellige tankesett. Team- eller produktledelse handler om å fasilitere teamet og balansere brukerbehov og virksomhetens behov.
Tradisjonelle utviklingsteam er kanskje vant til at det er noen rundt dem som bestemmer at det kan være vanskelig å ta større ansvar som team. En av de viktigste oppgavene som leder er å motivere, coache teamet og omgivelsene. Teamet må fokusere mindre på tidsfrister og sprinter. Mange av teknologiselskapene benytter f.eks. verken Scrum eller kjører sprinter.
Reelle frister skjønner de fleste. Det er rimelig lettfattelig at noe må være ferdig til neste år fordi Stortinget har vedtatt nye regler. Eller at det er en kvartals-/årsavslutning.
Datoer er omtrent like inspirerende for et team som å lese et regnskap.
Det er viktigere å ha fleksibilitet i hvordan man løser problemene med fokus på hensikten. Teamledelsen må arbeide proaktiv med ledelsen slik at de kan se på investering i tid i forhold til den potensielle effekten som kan oppnås i en tidsperiode, heller enn å estimere oppgaver.
Et veldig godt tegn på at man er på rett vei er når mål, fokus og kommunikasjon dreier seg om bruker og kundeproblemer og jobben som brukeren ønsker å få utført. Ikke om statusrapporter, planer, leveranser og tidsfrister.
Digital produktutvikling er ikke lett. Det er en lagsport og det er gøy!
Referanser:
Buvik P.M. & Tkalich A. (2021). Psychological Safety in Agile Software Development Teams: Work Design Antecedents and Performance Consequences.
John Cutler og Shreyas Doshi. Twitter.
Omholt K. (2021). Kultur og tankesett — De myke sidene av smidig.
Orosz G. (2021). How Big Tech Runs Tech Projects and the Curious Absence of Scrum
Powers S. (2021). Change.
