när jag först börjar arbeta med ett agilt produktteam är en av de vanligaste situationerna jag hittar där lagen har långa och frustrerande Sprintplaneringsmöten eftersom backlog-artiklar är dåligt definierade och inte väl förstådda; de har långsam hastighet och dålig design eftersom detaljer fortfarande utarbetas under sprinten; och mängden avfall och omarbetningar är mycket hög eftersom backlog-artiklar inte har validerats.

kom ihåg att vårt högre ordermål är att validera våra ideer på det snabbaste och billigaste sättet. Att faktiskt bygga och lansera en produktide är i allmänhet det långsammaste och dyraste sättet att validera tanken.

det är därför jag är en stor förespråkare för vad som ibland kallas Dual-Track Agile (aka Dual Track Scrum, Fake It Before You Make It, Bygg saker som inte skalar/bygger saker som skalar, rör sig snabbt/Bryt inte saker, kontinuerlig upptäckt/kontinuerlig leverans etc.).

jag brukade hänvisa till detta som helt enkelt Discovery Sprints, men det har en implikation av tidsboxad upptäckt och även serialisering av faser. Jeff Patton delade först med mig termen” Dual-Track Scrum ” och jag föredrar den här termen eftersom den bättre fångar den parallella naturen av upptäckt och leverans.

Upptäcktsspåret handlar om att snabbt generera validerade produktbackloggartiklar, och Leveransspåret handlar om att generera släppbar programvara.

en annan anledning till att jag gillar den dubbla Spårformiga metaforen är att jag tycker att många människor i huvudsak gör små mini-vattenfall inom deras Scrum-ramverk. Produktchefen gör något slags “krav” – arbete, och det skickas till en designer som gör sina mönster och genererar sina artefakter (vanligtvis annoterade wireframes), och sedan överlämnas det till leveransteamet för att bygga och testa.

däremot, i dubbelspårig smidig, kännetecknas arbetsflödet inte av att varje roll levererar artefakter vidare till nästa steg; snarare är det samarbete – produktchef, designer och lead engineer arbetar tillsammans, sida vid sida, för att skapa och validera eftersläpningsobjekt.

läsare av dessa artiklar vet hur viktigt jag anser användarupplevelse design, men en av svårigheterna för många agila team är att rytmen och takten i Agile kan vara mycket svårt på traditionella UX-team. Det är därför jag är ett fan av Lean UX. Lean UX och Dual-Track Agile är gjorda för varandra. I stället för att fokusera på artefakter fokuserar vi på prototyper och validerar dessa prototyper i Discovery, med den extra fördelen att prototypen fungerar som spec för leverans.

viktigast av allt, till skillnad från en Vattenfallsprocess där valideringen sker efter release, i dual-Track Agile, validerar vi under Discovery. I principen att validera så snabbt och billigt som vi kan, mycket av tiden kan vi faktiskt göra vår validering innan vi skriver någon produktionskod, i andan av “fake it before we make it.”

så om ditt produktteam är frustrerat över mängden avfall och den långsamma takten för att uppnå faktiska affärsresultat, överväg att prova dubbelspårig smidig. Se om detta kan inspirera till en nivå av samarbete, snabb iteration och validering som resulterar i mycket bättre arbete.

Lämna ett svar

Din e-postadress kommer inte publiceras.