Dual-Track Scrum

Gdy po raz pierwszy spotykam się ze zwinnymi zespołami produktowymi, członkowie zespołu zazwyczaj znajdują się w sytuacji, w której dręczą ich długie i frustrujące spotkania Sprint Planning, ponieważ elementy Backlogu są słabo zdefiniowane i źle rozumiane. Velocity jest niska, a design słaby, ponieważ szczegóły są dopracowywane nawet w trakcie Sprinta. Ponadto jest dużo marnotrawstwa i poprawek do wykonania, ponieważ elementy Backlogu nie były zwalidowane.

Należy pamiętać, że naszym nadrzędnym celem jest walidowanie naszych pomysłów w jak najszybszy i najtańszy sposób. Faktyczne wdrożenie pomysłu na produkt i wypuszczenie go na rynek jest zasadniczo najwolniejszym i najdroższym sposobem, aby to zrobić.

Czym jest Dual-Track Scrum?

Z tego powodu jestem wielkim zwolennikiem czegoś, co jest nazywane między innymi Dual-Track Scrum. Wcześniej używałem na to terminu „Discovery Sprints", ale wywołuje to wrażenie czasowo ograniczonej fazy odkrywania i serializacji faz.

Po raz pierwszy Jeff Patton opowiedział mi o „Dual-Track Scrum". Wolę ten termin, ponieważ lepiej oddaje równoległość Discovery i Delivery.

W Product Discovery Track chodzi o jak najszybsze generowanie zwalidowanych elementów Product Backlogu. W Product Delivery Track chodzi o generowanie gotowego do dostarczenia oprogramowania.

Kolejnym powodem, dla którego tak bardzo lubię metaforę dwóch „torów" w Dual-Track Scrum, jest fakt, że często widzę ludzi, którzy w zasadzie wbudowują mini-wodospady w swój framework Scrum. Menedżer produktu wykonuje jakąś „pracę nad wymaganiami", którą przekazuje designerowi. Ten tworzy projekt i generuje swoje artefakty (zazwyczaj opatrzone adnotacjami wireframe'y), po czym wszystko jest przekazywane do zespołu delivery do budowania i testowania.

W przeciwieństwie do tego, przepływ pracy w Dual-Track Scrum nie polega na przekazywaniu przez poszczególne role artefaktów do kolejnego etapu. Zamiast tego Dual-Track Scrum jest kolaboratywny — menedżer produktu, designer i główny deweloper pracują ramię w ramię, aby tworzyć i walidować elementy Backlogu.

Czytelnicy moich artykułów wiedzą, jak ważny jest w moich oczach User Experience Design. Jednak tempo i szybkość Scrum mogą stanowić problem dla wielu tradycyjnych zespołów UX. Dlatego jestem takim wielkim zwolennikiem Lean UX. Lean UX i Dual-Track Scrum są stworzone dla siebie. Zamiast skupiać się na artefaktach, przy Discovery skupiamy się na prototypach i walidacji tych prototypów. Dodatkową zaletą jest to, że te prototypy służą jako specyfikacje dla Delivery.

Jednak najważniejsze jest to, że walidacja nie następuje jak przy procesie kaskadowym po wydaniu, lecz przeprowadzamy walidację w Dual-Track Scrum już podczas Discovery. Mając na uwadze zasadę walidowania czegoś tak szybko i tanio jak to możliwe, możemy często przeprowadzić walidację, zanim w ogóle zostanie napisany kod — zgodnie z mottem „udawaj, zanim to zbudujesz".

Podsumowanie dotyczące Dual-Track Scrum

Jeśli więc Twój zespół jest sfrustrowany z powodu dużej ilości marnotrawstwa i powolnego osiągania konkretnych wyników biznesowych, powinieneś rozważyć Dual-Track Scrum. Być może może to prowadzić do lepszej współpracy, szybszego iterowania i walidacji, a tym samym do lepszej pracy.

Tekst pochodzi z bloga Marty'ego Cagana i został przez nas przetłumaczony.

Strategia firmy a strategia produktu

Dowiedz się więcej o potencjalnych konfliktach strategicznych w naszym artykule na temat różnicy między strategią firmy a strategią produktu.