når jeg først begynder at arbejde med et Agile produktteam, er en af de mest almindelige situationer, jeg finder, hvor holdene har lange og frustrerende Sprintplanlægningsmøder, fordi backlog-genstande er dårligt definerede og ikke godt forstået; de har langsom hastighed såvel som dårligt design, fordi detaljer stadig udarbejdes under sprinten; og mængden af affald og omarbejdning er meget høj, fordi backlog-genstande ikke er valideret.

Husk, at vores højere ordensmål er at validere vores ideer på den hurtigste og billigste måde. Faktisk er opbygning og lancering af en produktidee generelt den langsomste og dyreste måde at validere ideen på.

derfor er jeg en stor fortaler for det, der undertiden kaldes Dual-Track Agile (aka Dual Track Scrum, falske det, før du laver det, bygge ting, der ikke skalerer/bygger ting, der skalerer, bevæger sig hurtigt/bryder ikke Ting, kontinuerlig opdagelse/kontinuerlig levering osv.).

jeg plejede at henvise til dette som simpelthen Opdagelsessprints, men det har en implikation af Tidsbokset opdagelse og også serialisering af faser. Jeff Patton delte først med mig udtrykket” Dual-Track Scrum”, og jeg foretrækker dette udtryk, fordi det bedre fanger den parallelle karakter af opdagelse og levering.

Discovery-sporet handler om hurtigt at generere validerede produktefterslæb, og Leveringssporet handler om at generere frigivelige programmer.

en anden grund til, at jeg kan lide Dual-Track Agile metafor, er, at jeg finder mange mennesker, der i det væsentlige laver små mini-vandfald inden for deres Scrum-rammer. Produktchefen udfører en slags “krav” – arbejde, og det overføres til en designer, der udfører sine designs og genererer sine artefakter (normalt kommenterede trådrammer), og derefter afleveres det til leveringsteamet for at bygge og teste.

i modsætning hertil er arbejdsstrømmen i Dual-Track Agile ikke kendetegnet ved, at hver rolle leverer artefakter videre til næste trin; det er snarere samarbejde – produktchefen, designeren og lead engineer arbejder sammen side om side for at skabe og validere backlog-elementer.

læsere af disse artikler ved, hvor vigtigt jeg betragter brugeroplevelsesdesign, men en af vanskelighederne for mange Agile teams er, at rytmen og tempoet i Agile kan være meget vanskeligt på traditionelle U-teams. Derfor er jeg fan af Lean. Lean og Dual-Track Agile er skabt til hinanden. I stedet for at fokusere på artefakter, vi fokuserer på prototyper og validering af disse prototyper i Discovery, med den ekstra fordel, at prototypen fungerer som spec til levering.

vigtigst, i modsætning til en Vandfaldsproces, hvor valideringen sker efter frigivelse, i Dual-Track Agile, validerer vi under Discovery. I princippet om at validere så hurtigt og billigt som vi kan, meget af tiden kan vi faktisk gøre vores validering, før vi skriver nogen produktionskode, i ånden af “falske det, før vi laver det.”

så hvis dit produktteam er frustreret over mængden af affald og det langsomme tempo i at opnå faktiske forretningsresultater, kan du overveje at prøve Dual-Track Agile. Se om dette kan inspirere til et niveau af samarbejde, hurtig iteration og validering, der resulterer i meget bedre arbejde.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.