Agile Inception. Foto: Jonas Ljungdahl
Detta är andra delen i artikelserienAgile Inception – The loop approach. Samtliga artiklar är tagna ur Softhouse utgåva Agile inception in 60 min. Vi hoppas att du uppskattar läsningen och hur man kan kombinerar olika agila inceptionstekniker. Kom ihåg att loop-ansatsen av de tre huvudsakliga agila inceptionstrategierna vi använder oss av inom denna artikelserie är tre av många som finns där ute. Givetvis väljer du själv inceptionstrategierna som passar dig för att sätta samman den loop du behöver. Njut av läsningen och lycka till med dina loopar! Första delen hittar du här!
LOOP 2: KÖR!
För en organisation som levererar nya eller förbättrade tjänster genom en befintlig kundlivscykel, som har ett behov av snabb affärsberättigande och prioritering av berättelser, är ”Kör!” en smidig samarbetsloop som levererar en användarberättelsekarta och en releaseplan, i motsatsen till en traditionell affärsinitiativ, levereras ”Kör!” på 3 arbetsdagar!
Denna loop genererar en användarberättelsekarta och en produktutvecklingsplan efter en snabb affärsberättigandekontroll. Loop 2 är lämplig för team och organisationer som är kapabla att fatta snabba strategiska beslut baserat på en övergripande ryggrads-releaseplan.
En förutsättning för att lyckas med loopen är att utföra teknikerna med ett samlokalisert, tvärfunktionellt team och ha nyckelintressenter tillgängliga samtidigt för snabba svar och validering av resultat.
När ska man använda Loop 2?
Den används när svaret är ja på någon av följande frågor:
- Behöver ditt produktsammanhang nya eller förbättrade tjänster genom en befintlig kundlivscykel?
- Behöver du en övergripande framåtblickande plan som täcker flera iterationer av releasen för att samordna dina utvecklingsinsatser med leveransorganisationen?
- Behöver du förbättra ditt smidiga planeringsspel med en tätare koppling till affärsvärdeleverans, då kan denna loop passa dina behov.
Tidsbox
3 arbetsdagar.
Låt oss gå in i loopen
Det är lätt att generera massor av fantastiska idéer, men det är svårt att sålla ut den där speciella idén med hög affärspotential. Använder vissa människor en magisk trollstav eller gömmer de en kristallkula i sin garderob? Faktum är att det finns ett verktyg som fungerar på riktigt! Använd din hjärnkapacitet och gör dig redo för en affärsmodellscanvas, ett genialiskt koncept på en sida som hjälper dig att gräva efter guld.
Business Model Canvas (BMC)
Genom att börja med BMC hjälper teamet till att fokusera på ”göra rätt sak rätt och snabbt”. Många smidiga team börjar sin resa genom att vara upptagna med att ”göra rätt sak rätt och snabbt”, och att börja loopen med en BMC lägger tonvikt på värdemodellen och att hitta rätt värdestrategi som ligger i hjärtat av smidighet! En BMC utforskar genomförbarheten för en produktidé, vanligtvis genom att testa prototyper, t.ex. landningssidor, mot identifierade kundsegment. Huvudsyftet är att skapa en giltig affärsmodell eller att tidigt avsluta projektet om den inte är livskraftig.
Om ditt projekt är helt nytt rekommenderar vi att du och ditt team bygger en BMC. Även om du arbetar med att planera nästa stora steg i livscykeln för en befintlig produkt kan det vara fördelaktigt att prova denna teknik för att verkligen begränsa de mest kritiska stegen som krävs för att uppnå ett konkret affärsresultat.
Börja med Kundsegment och Värdeerbjudande för att ha en god kund- och användarcentrerad fokus när du identifierar de värden som är unika för din planerade insats. Om du planerar nästa stora insats för en befintlig produkt behöver du fortfarande fånga Värdeerbjudandet i jämförelse med dina konkurrenter, men du kanske också vill betona hur nästa releasen kommer att skärpa värdeerbjudandet ytterligare. När denna produkt- och kundcentrerade kärna är identifierad kan du lägga till ett annat lager till din modell, där du diskuterar och fokuserar på Nyckelresurser, Nyckelaktiviteter och Nyckelpartners som skulle möjliggöra leverans av värdeerbjudandet till Kundsegmenten.
När du har fyllt i denna information är det dags att börja tänka på kostnadsstruktur och intäktsströmmar. Sedan utforma en hypotes och formulera en kvantifierbar mätare. Skapa slutligen en prototyp och generera insikter från ditt kundsegment. Observera att vi vid detta tillfälle inte har ägnat tid åt att förstå de faktiska produktkapabiliteter som kommer att hjälpa till att förverkliga BMC – men vi börjar röra oss åt det hållet!
När vi skapar affärsmodellen behöver vi vanligtvis svar på följande frågor: Vilka kanaler behöver vi? Vem behöver vara involverad? Hur relaterar våra kanaler till kundrelationer och nyckelresurser?
Denna viktiga information är ibland svår att greppa. Vi behöver ofta se det från ett annat perspektiv för att få det rätt. Att titta på kundlivscykeln är ett användbart sätt framåt och ger oss en bra grund för en mer användarcentrerad perspektiv under planeringsarbetet.
Customer life cycle “CLC” (Kundlivscykel)
När vi letar efter produktkapabiliteter under inledningsarbetet rekommenderar vi att använda en modell för CLC för att identifiera de övergripande kundinteraktioner som produkterfarenheten behöver omfatta. CLC är en modell som kommer från Customer Relationship Management (CRM)-området, Sterne och Cutlers ursprungliga modell är baserad på fem grundläggande steg: nå, förvärv, omvandling, behållning och lojalitet.
Vi brukar använda denna modell för att gå från en affärsmodellscanvas med ett värdeerbjudande till faktiska högnivåkapabiliteter. Vår hybridmodell nedan är mer av ett verktyg relaterat till affärsbehov och vi har använt den i olika kundprojekt, främst inom IT- och telekomdomänen. Det är en bra modell för att förstå produktens nuvarande tillstånd (om du har en sådan) och för att visualisera var våra kapabiliteter i hög nivå kommer att dyka upp i den övergripande kundupplevelsen. En modell för CLC underlättar också prioritering av värde när det gäller att fatta avvägningsbeslut mellan att lägga till nya produktkapabiliteter eller att lägga till kapabiliteter i processer/system som möjliggör kundupplevelsen, ett beslut som är kopplat till var din produkt befinner sig i sin produktlivscykel.
Använd tankekartläggning och klistermärken som sätt att modellera kapabiliteterna och var de behöver visas i CLC-modellen. I vissa team använder vi färgkodade klistermärken för att visualisera och skilja mellan nuvarande kapabiliteter och önskade nya kapabiliteter.
På en hög nivå, har vi nu utökat vårt värdeerbjudande för att potentiellt täcka mer än bara produktkapabiliteter. Efter viss kämpande, prioritering, omröstning och beslutsfattande är affärsmodellen äntligen tillräckligt bra och överenskommen. Vi förstår på en övergripande nivå vilka kapabiliteter vår tjänst måste leverera för att göra värdeerbjudandet levande, men hur ska det egentligen fungera?
Låt oss introducera kundresan, ett verktyg för tjänstedesign, som detaljerar kundupplevelsen i ett värdeflödesformat. Det pekar ut vilka tjänstleveransroller (och stödsystem) och vilka informationspunkter de har och förstärker återigen fokus på kund- och användarupplevelsen.
CLC och Kanaler
CLC kan delas upp i (kommunikations)kanaler, t.ex. butik, webbutik osv. Beroende på var din produkt befinner sig i sin livscykel kan fokus för ditt kommande produktarbete mycket väl vara mer relaterat till kundlivscykeln än enbart produktrelaterat. Det är viktigt att behålla en kundcentrerad syn eftersom kunden inte skiljer mellan de faktiska produktkapabiliteterna och de stödjande processerna.
Kundresa
En kundresa beskriver kundinteraktion på hög nivå, medan en kundresa skildrar hela kundupplevelsen genom att visualisera varje kontaktpunkt med en produkt (eller tjänst). Använd kundreseläggning för att identifiera kapabiliteter (och villkor och begränsningar) vid varje kontaktpunkt. Om kundlivscykeln har delats upp i kanaler krävs en kundresakarta per kanal (eller färgkodade klistermärken).
Kontaktpunkterna är de faktorer som utgör den totala upplevelsen av att använda en produkt (eller tjänst). Kontaktpunkter kan anta olika former, från reklam till personliga kort, webb-, mobil- och datorgränssnitt, fakturor, fysiska butiker, callcenter och kundrepresentanter.
En kundresa är i grund och botten en mycket övergripande flödesdiagram som visar kundens huvudsteg och hur det kopplar till manuell och/eller digital processstöd i varje huvudsteg (dvs. vilka enheter som är involverade). Återigen är kontext avgörande.
Eftersom en kundresakarta visualiserar den övergripande tjänsten är det enkelt att fånga högnivåproduktkapabiliteter som vi kan skriva som användarberättelser. Dessa högnivåberättelser blir ryggraden i en berättelsekarta innan de bryts ned till lämplig detaljnivå. Ett tips för att få en ”total översikt” är att bygga dessa modeller på samma vägg, med användarberättelsen under kundresan. Vid detta tillfälle kan du ha spenderat totalt 2 dagar på att bygga BMC och fånga produktkapabiliteter genom att skapa en kundresa. Låt oss ta det sista steget i denna loop, som är att bygga den övergripande ryggradsreleaseplanen.
Team Releaseplan. Foto: Jonas Ljungdahl
RELEASEPLANEN
Nu har vi, i utvecklingsteamet, allt vi behöver för att gemensamt bygga vår releaseplan. Detta är det sista steget i loopen, och nu tittar vi på och ger initiala tids- och kostnadsestimeringar för de kommande produktinsatserna som planeras (dvs. release/releaser). Vi rekommenderar User Story Mapping som ett utmärkt sätt att visualisera det arbete som krävs och samtidigt identifiera din releasestrategi.
User Story Mapping
Organisera dina kapabiliteter, dvs. dina epics berättelser och nedbrutna användarberättelser, i en strukturerad modell för att visualisera produktbackloggen som helhet inklusive varje aktörs användarperspektiv.
Epic berättelser ordnas från vänster till höger i tidsföljd. Varje epic berättelse bryts ned i flera mindre användarberättelser. En hög position indikerar att de är absolut nödvändiga, medan en lägre position indikerar att de har mindre affärsmässig betydelse.
Nedbrytning av användarberättelser
Formatet för användarberättelsekartan kommer att stödja behovet av att bryta ned berättelser eftersom epic berättelser (ryggraden) är direkt relaterade till de mindre berättelserna under dem (de användaruppgifter som krävs för att lyckas med aktiviteten). De måste brytas ned i flera underberättelser, det vill säga ytterligare användarberättelser med större detaljnivå. Att göra detta medan du bygger användarberättelsekartan passar bra eftersom det ger berättelserna kontext och ger även prioritering av användarberättelserna. Alla berättelser måste också ha en uppskattning, föredragligen genom att använda relativ estimeringstekniker som ideal utvecklingstid eller story points.
Observera att nedbrytning av berättelser är en pågående aktivitet inom smidig produktutveckling. En tumregel är att ligga en iteration före genomförandet. Just nu skapar vi output som behövs för en kommande releaseplan, när releasen har startat tillämpar vi principen om en iteration i förväg (så kallad produktbacklogförfining eller ”förbereda backloggen”).
Nu har vi en större uppsättning kontextualiserade kapabiliteter utifrån ett användarperspektiv som vi direkt kan koppla till de högnivåkapabiliteter som behövs för att stödja den BMC som vi försöker uppnå.
RELEASEPLANERING
De användarberättelser som placeras högt på berättelsekartan beskriver den minsta produktens funktionalitet (eller tjänst) som skulle ge en helhetsfunktionalitet och leverera det affärsvärde som anges i en releasemål. Denna funktionalitet bör släppas först, innan något annat arbetas med. Rita en linje över användarberättelsekartan för att visualisera användarberättelserna för produktversion 1.
En releaseplan specificerar kapabiliteterna, dvs. användarberättelserna, för varje produktversion och datum för release. Denna ”tidsplan” eller framåtblickande plan är lämplig för att kartlägga långsiktiga element med lång ledtid, som inköp av utrustning och externa leveranser, parallellt med planerade iterationer i releasen/releaserna. Det är också en användbar visualisering att använda med intressenter som är vana vid en mer Gantt-liknande syn på projekt.
Observera att vi inte främjar en omfattande planering i förväg med fullständig nedbrytning av alla produktkapabiliteter/användarberättelser. En releaseplan har mer nedbrutna iteratkandidater för den första iterationen, medan resten av releasekandidaterna hålls på en högre detaljnivå. Vi använder oss av rullande vågplanering medan vi arbetar med en iteration för att förbereda och nedbryta kommande iteratkandidater under releasen när arbetet fortskrider.
Dela upp den initiala produktversionen i iterationer och bestäm varaktigheten
En förutsättning för releaseplanering är den förväntade hastigheten med vilken användarberättelser implementeras och längden på iterationen. Det är också vanligt att sätta en kostnad för iterationen (baserat på antalet personer i teamet och deras fördelning).
- Hastighet = berättelsepoäng/iteration (25).
- Längd på iteration (4 veckor).
- Kostnad för iterationen (10 000 $).
Sammanfatta det totala antalet berättelsepoäng för release av produktversion 1 (75) och dela upp det i iterationer baserat på hastigheten (75/25 = 3).
- Release av produktversion 1 kommer att levereras i 3 iterationer.
- Release av produktversion 1 kommer att kosta 30 000 $.
Bestäm varaktigheten genom att beräkna antalet iterationer x längd på iteration (3×4 = 12 veckor).
- Release av produktversion 1 kommer att levereras på 12 veckor.
Återbesök användarberättelsemodellen efter varje iteration
Eftersom ansträngningen för användarberättelse (berättelsepoäng) uppskattas och hastigheten (berättelsepoäng/iteration) ”gissas”, kommer de inledande releaseplanerna att återbesökas och justeras i enlighet med den verkliga uppmätta hastigheten när iterationen påbörjas.
Användarberättelsekartan kan användas som den är, men den delas vanligtvis upp i produktbacklog, releaseplan och iterationsplan av praktiska skäl, som versionskontroll, informationsdelning och lagring. Releaseplanen kan användas under demo-/genomgångsevenemang såväl som vid iterationplaneringsevenemang för att behålla fokus på att samordna en kadens mellan utvecklingsteamets arbete (iterationer) och leveransorganisationen och deras leveranser.
Grattis, du har avslutat Loop 2!
Du har nu en BMC i linje med en användarberättelsekarta och en övergripande framåtblickande plan – releaseplanen. Dessa resultat kommer att stödja det pågående strategiska beslutsfattandet kring dina utvecklingsinsatser samt hjälpa teamet att fokusera på mer långsiktig värdeleverans än bara nästa iteration.
Sista delen i serien publiceras nästa vecka!
