Scrum + UX to połączenie doskonałe!

U moich klientów czasami widzę, że UX jest traktowany po macoszemu. Na poziomie deklaracji mówi się, że UX jest ważny, jednak w praktyce główny nacisk kładzie się na prace inżynieryjne i rozwiązania techniczne. Kwestie takie jak design produktu, spełnianie potrzeb przyszłych użytkowników, wizja biznesowa czy w ogóle zasadność produktu są na drugim planie.

---

Grzechy główne

Problem, który często dostrzegam, to powstanie dwóch oddzielnych silosów: discovery (UX) i delivery, czyli prace deweloperskie. Praktycznie zawsze prowadzi to do zwiększenia prawdopodobieństwa konfliktów o polaryzującym haśle przewodnim „to ich wina!” oraz lokalnej optymalizacji, gdzie każda ze stron skupia się na swojej specjalności i brakuje synergicznej współpracy.

Często słyszę od UX-owców: „każdy nasz pomysł jest blokowany”, „deweloperzy nic nie rozumieją, powinni siedzieć cicho i po prostu robić to, co im każemy”, podczas gdy deweloperzy wtórują: „UX jest kompletnie oderwany od rzeczywistości, kompletnie nie myślą o tym, że to trzeba zaimplementować”, „znowu Ci UX-owcy coś mieszają, po co zmieniać coś co już działa? Lepiej robić nowe funkcjonalności!”. Kolejny problem to długi czas od momentu powstania pomysłu do momentu wdrożenia go na produkcję (Customer Lead Time). Wydłużają się przez to pętle zwrotne i rośnie drastycznie koszt opóźnienia – a przecież każda sekunda, kiedy użytkownik nie może jeszcze korzystać z funkcjonalności, to niepowetowana strata!

Walidacja hipotez

Esencją podejścia empirycznego, takiego jak Scrum, są pętle zwrotne z rzeczywistością, które pozwalają nam potwierdzać lub obalać hipotezy biznesowe oraz techniczne. Dodanie UX do Scruma zwiększa ilość pętli zwrotnych oraz daje dodatkowe okazje, by weryfikować czy robione są właściwe rzeczy. Co niezmiernie ważne, walidacja może odbywać się na różnych poziomach wiarygodności. Przed jakąkolwiek walidacją jesteśmy w kompletnej, błogiej ignorancji.Warto zwrócić uwagę na kilka kwestii. Ogromną ilość walidacji można zaaplikować do procesu empirycznego zanim powstanie jakikolwiek kod. Można to robić przez wywiady z użytkownikami, prototypy papierowe lub też w formie makiet. Można też zastosować tak zwany „Wizard of Oz”, technikę polegającą na tym, że użytkownik myśli, że korzysta z ostatecznego produktu, gdy tak naprawdę istnieje tylko wydmuszka, za którą stoi człowiek. W ten sposób walidowano czy użytkownicy będą chcieli rozmawiać z Alexą, czyli wirtualną asystentką obdarzoną sztuczną inteligencją. Zanim zaczęto implementować ostateczny produkt, analizowano reakcje ludzi, którzy myśleli, że rozmawiają z „puszką” obdarzoną sztuczną inteligencją. Tak naprawdę w „zwykłej puszce” znajdował się mikrofon i rozmowa prowadzona była z człowiekiem z pokoju obok. Taki sposób walidacji jest niesamowicie tani w stosunku do wytworzenia końcowego produktu. Pozwala uniknąć niepotrzebnej pracy i na przykład gdyby się okazało, że potencjalny produkt jest nieatrakcyjny, prace nawet by się nie zaczęły i miliony dolarów zostałyby zaoszczędzone.

Inkrement produktu kwintesencją Scruma

Scrum to narzędzie, które waliduje hipotezy biznesowe i techniczne poprzez tworzenie kolejnych inkrementów produktu. Inkrement jest gotowy do zreleasowania w każdej chwili: gruntownie przetestowany, zintegrowany i – co najważniejsze – użytkownik może go… użyć. Te inkrementy są poddawane walidacji, przykładowo poprzez feedback userów, interesariuszy z użycia, wydanie BETY czy poprzez release na rynek. Taka walidacja wnosi ogromną wartość, daje silny kontakt z rzeczywistością, ale… jest niesamowicie kosztowna. Największy koszmar każdego Product Ownera to wydać fortunę, stworzyć produkt i w ten sposób udowodnić, że to całkowicie bezsensowne przedsięwzięcie! Warto jeszcze dodać, że nawet wydanie produktu na rynek nie jest walidacją ostateczną, można jeszcze robić badania UX z użycia wydanej aplikacji – i to jest dopiero walidacja ostateczna.

Poziomy dojrzałości 

Scruma i UX można połączyć na różnych poziomach dojrzałości. Im wyższy poziom dojrzałości tym współpraca UX i delivery jest lepsza.

#0 – Scrum bez UX

Pół żartem, pół serio, można powiedzieć, że zaletą tego rozwiązania jest brak problemów komunikacyjnych pomiędzy UX i delivery. Mówiąc poważniej, należy zauważyć, że walidacja zaczyna się od działającego produktu, nie ma też najprawdopodobniej ostatecznej walidacji w formie badań produktu na rynku. 

#1 – UX Scrum Fall

To poziom, gdy UX poprzedza pracę dewelopmentu. Zanim powstanie jakikolwiek kod, wykonywane są wszystkie badania potrzeb userów i powstaje gotowy design aplikacji. To makiety, które mają być zaimplementowane przez deweloperów z dokładnością co do piksela. Najczęściej UX jest wykonany przez zewnętrzne firmy albo oddzielny dział.

Jest to prosty przepis na stworzenie podziału „my” kontra „oni” oraz budowanie kultury „to ich wina!”. Dodatkowo, zanim powstanie coś, co może „dotknąć” użytkownik, minie dużo czasu. Najgorsze, że nie ma tutaj pętli zwrotnych discovery – delivery. Nie ma takiej możliwości, aby deweloperzy wzięli udział w decyzjach designerskich, na przykład sugerując, że zaproponowane rozwiązanie jest bardzo trudne w realizacji. Deweloper nie ma okazji powiedzieć: „takie rozwiązanie to 5 dni pracy, ale możemy to zrobić z użyciem gotowej biblioteki w 30 minut, musimy tylko lekko zmienić wygląd”. 

#2 – Sprinty Naprzemienne (Staggered Sprints)

W tym podejściu UX pracuje „sprint wstecz” w stosunku do delivery. Jest to ogromny postęp w stosunku do UX Scrum Falla, wszystkie wcześniejsze problemy ulegają zmniejszeniu. Pojawia się współpraca pomiędzy delivery i discovery, silosy są mniej wyraźne i niewątpliwie czas dostarczania drastycznie skraca się. 

Desiree Sy i Lynn Miller, czyli autorki tego podejścia, zakładały, że UX i deweloperzy będą pracowali jako jeden zespół. Jednak praktyka pokazuje inaczej. UX i Deweloperzy pracujący w Sprintach Naprzemiennych najczęściej tworzą dwa oddzielne zespoły, skupione po prostu na czymś innym.

Jest postęp, ale może być jeszcze lepiej!

#3 Discovery + Delivery = Scrum Team

Najwyższy poziom dojrzałości w połączeniu Scruma i UX-a to jeden Zespół Scrumowy składający się z delivery i discovery. W nomenklaturze scrumowej UX-owcy stają się deweloperami – czyli osobami odpowiedzialnymi za dostarczenie kolejnej wersji inkrementu.

Przykład zastosowania

Takie połączenie może przybrać bardzo różne formy. W końcu Scrum to framework dający duży poziom swobody. Najlepiej więc posłużyć się przykładem.

Kilku członków zespołu ma wysokie zdolności UX. Jednak jest powszechną praktyką, że w swoje działania wciągają resztę zespołu. Chociaż to właśnie eksperci UX najczęściej prowadzą wszelkiego rodzaju UX-owe warsztaty, bierze w nich udział cały zespół. Część prac UX zawiera się w Product Backlog Refinemencie, czyli czynności która sprawia, że elementy Product Backloga można zaciągnąć na Sprint Planningu. W naszym przypadku to wstępny wywiad z klientem i przetestowanie na potencjalnych użytkownikach prototypów (papierowych albo jakichś wireframe’ów). Oczywiście eksperci UX zachęcają do uczestnictwa cały Scrum Team.

W ramach Sprint Planningu następuje wspólne ostateczne doprecyzowanie designu. Istnieje jeden Product Backlog, a w ramach każdego jego elementu są do wykonania zarówno działania discovery jak i delivery. Tak więc praca UX jest częścią Definition of Done.

Sprinty mają długość dwóch tygodni. W każdy pierwszy czwartek Sprintu odbywają się wywiady i testy UX prototypów z potencjalnymi userami. W takich spotkaniach biorą udział też niektórzy deweloperzy. 

W każdy drugi wtorek, odbywa się walidacja gotowych feature’ów (z poprzednich Sprintów) na użytkownikach. Zamyka się usera w pokoju i cały zespół obserwuje jak używa aplikacji (jest pogląd na wszystkie jego akcje). Na tej podstawie powstają pomysły co można zmienić w aplikacji. Zostają stworzone nowe wymagania i Product Owner określa ich kolejność w Product Backlogu.

W każdej chwili programiści mogę poprosić ekspertów UX o pomoc gdy nie są pewni jak coś zrobić. 

W tak zwanym międzyczasie, UX-owcy mierzą istotne dla produktu wartości. Na przykład stosują badania kohortowe, określają retencję użytkowników czy robią testy A/B na userach.

W zależności od Sprintu stosunek czynności UX-owych i delivery różni się, zdarzają się Sprinty, że większość czasu jest poświęcane na warsztaty UX-owe z klientami i userami, są też takie, że główny nacisk jest położony na pracę delivery.

Przeszkoda #1

Należy pamiętać, że wejście na wyższy poziom dojrzałości to często gigantyczna zmiana kulturowa. Proponuję tutaj podejście ewolucyjne. Jeżeli nigdy nie pracowaliście z UX-em, nie zaczynajcie stosować wszystkich praktyk z przykładu od razu. Jak mawiał Pan Miyagi: „Najpierw naucz się stać, a potem latać”.

Przeszkoda #2

Warto wspomnieć, że krytyczną przeszkodą przed skutecznym użyciem UX-a ze Scrumem jest pycha. Skuteczne stosowanie UX wymaga ogromnej pokory. Trzeba jasno sobie powiedzieć na temat potrzeb userów i rynku: „Wiem, że nic nie wiem”, przynajmniej do czasu, aż nie zrobi się odpowiednich badań.

Przeszkoda #3

To, co może skutecznie powstrzymać sprawne działania UX to coś, co nazywam „syndromem myślenia projektowego”. Czyli skupienie się na sukcesie projektu, z pominięciem sukcesu produktu. Jak kogoś interesuje tylko coraz wyższa prędkość prac w każdym Sprincie to UX będzie tylko przeszkadzał. Po co weryfikować? Lepiej w tym czasie tworzyć więcej funkcjonalności!