Ambitionen i många agila transformationer är att uppnå en högre ”software delivery performance” i sin ”Product Delivery”. Det är grundläggande och helt rätt att börja i den änden – en agil produktutvecklingsprocess behöver vara effektiv med korta cykeltider för att den ska kunna erbjuda en utforskande produktutveckling – Product Discovery.
Många förknippar agilitet med snabbare leveranser (time-to-market) genom snabba iterationer av utveckling och inkrementella leveranser. Detta är rimligt och eftersträvansvärt. Begreppen Product Delivery och software delivery performance handlar ofta om behovet att snabbare omsätta utvecklingsbehov till lösningar för våra kunder och användare. Att bränna ned en backlog snabbare. Men många stannar vid, eller fortsätter med optimeringen av, sin Product Delivery process och att ”göra saker rätt”.
Ett värde som vi förknippar med agila arbetssätt är att ”göra rätt saker” – att vara målsökande i att testa våra produkter gentemot användare och kunder för att kunna anpassa vägen OCH målet. Då krävs att vi fortsätter transformationen av vår produktutvecklingsprocess uppströms – där idéerna väcks och kopplingen mot vår organisations riktning sker.
Detta utforskande och målsökande kallas för Product Discovery och bör vara en naturlig fortsättning på en organisations agila transformation. Det är länken som binder samman produktutveckling med mjukvaruutveckling – digitalisering som söker rätt leverans både för interna användare i nya och effektiva processer och gentemot våra kunder. Vi reducerar risken genom att ta bort våra egna antaganden om deras behov och förväntningar samt genom att ständigt lära känna dem då vi testar våra idéer, tar emot deras feedback (datadriven och/eller subjektiv) och justerar riktningen utifrån våra lärdomar. Det här blir garanten för att göra rätt.
Vi ser ofta i våra uppdrag att kunderna har, eller håller på att få, väletablerade Product Delivery processer. Idag är det t.ex. stort fokus på DevOps, vilket är bra.
Samtidigt hanteras inflödet av utvecklingsbehov i en hybrid mellan traditionellt och agilt tänkande; stora batchar av utvecklingsbehov fördefinieras genom t.ex. förstudier och bryts ned till s.k. minimum viable products (MVP), men ofta är redan omfattning och mål inramat, åtagandet budgeterat och färdplanen lagd. MVPn blir i detta fall endast en platshållare för en fördefinierad leverans.
På detta sätt förlorar vi möjligheten att vara målsökande – vår förmåga till att ”göra rätt saker” ur ett kund- och användarperspektiv.
Vi uppmanar därför till att inte nöja sig med en högeffektiv Product Delivery process, utan att sträcka ut transformationen uppströms i organisationen.
I en ”SAFe värld” handlar detta om att jobba med vad man inom ramverket kallar för “Continuous exploration” och i en ren Scrum värld kanske endast ”Product Discovery”.
Grunden är desamma; att etablera en hypotesdriven produktutveckling där vi gör antaganden om våra idéers önskvärdhet, livskraftighet och genomförbarhet i ett tätt samarbete mellan produkt- och systemutveckling för att sedan iterativt och inkrementellt testa dessa hypoteser mot verkligheten – våra användare och kunder i små steg. Genom den feedback vi får kan vi avslöja våra egna antaganden och baserat på verkliga behov och förväntningar ta ut ny riktning och även mål för det vi vill uppnå. På detta sätt blir vi sant målsökande och skapar en stor följsamhet (agilitet) mot marknad, kunder och användare.
Vi vet att detta är nästa steg när du har fått stora delar av ”göra saker rätt” på plats. I alla fall om du söker innovation, nöjda kunder och användare.
Vill du veta mer, eller bara ta ett snack, om hur din organisation kan komma vidare på spåret med att ”göra rätt saker” så hör av dig. Det är inte raketforskning, men ställer en del invanda mönster på ända.
Författare. Mattias Tronje
© Brejn Consulting AB