Scrum jawi się jako wyzwanie dla wielu zespołów UX. Dlaczego? Projektanci, którzy włączeni są do pracy w Scrumie, muszą zrozumieć, na czym polegają ceremonie Scrumowe, dostosować rytm pracy do regularnych Sprintów i nauczyć się komunikować swoje zadania w taki sposób, aby można je było efektywnie wpisać do backlogu. Na szczęście, można połączyć design ze Scrumem i dzisiaj pokażemy wam jak się za to zabrać.

Angażując sporą część zespołu w pracę nad produktem, musimy znaleźć system, framework lub proces, który zapewni nam jasny podział zadań oraz komfortową, efektywną i usystematyzowaną pracę. Taki sposób powinien również dać nam możliwość szybkiej modyfikacji planu działania w obliczu nowych danych lub zmieniających się oczekiwań. Scrum jest jednym z takich frameworków.

Scrum umożliwia zespołom produktowym sprawniejszą organizację pracy, ale co gdy część naszego zespołu to projektanci, którzy muszą wykonać dużo dodatkowych czynności (odkrywanie potrzeb, testowanie hipotez itd.), zanim będą w stanie zaprojektować funkcjonalne rozwiązanie? Jak zintegrować pracę projektantów ze Scrumem? W tym artykule opowiemy Ci, jak wygląda nasza współpraca z zespołami Scrumowymi.

Projektowanie UX/UI a Scrum

Filary i wartości Scruma odpowiadają w pewnym stopniu zasadom projektowania produktów cyfrowych. Scrum opiera się na trzech filarach: przejrzystość, inspekcja i adaptacja oraz uznaje wartości takie jak zaangażowanie, odwaga, skupienie, otwartość i poszanowanie. Te filary i wartości są spójne z tymi, którymi kierują się projektanci UX i UI podczas projektowania.

Ponadto, podstawę Scruma stanowi empiryzm – zbieranie wiedzy i doświadczenia pomaga nam w podjęciu lepszych decyzji. Podobnie jest z procesem projektowym. Doświadczenie, które zdobywamy w trakcie pracy, ma wpływ na nasze dalsze kroki. Dopóki nie siądziemy do pracy, nie jesteśmy w stanie przewidzieć, jak powinno wyglądać ostateczne rozwiązanie. Tak jak w Scrumie – działamy iteracyjnie i dostosowujemy nasze kolejne działania do tego, co udało nam się wspólnie wypracować. Pozwala nam to na nanoszenie poprawek zaraz po ich odkryciu, przez co możemy uniknąć kosztownych zmian po wydaniu produktu.

Niestety na tym podobieństwa wydają się kończyć, ponieważ Scrum nie jest procesem ani metodyką a frameworkiem – ramą działania stosowaną w celu sprawniejszej organizacji pracy zespołu developerskiego. Scrum daje zespołowi wskazówki zachowań, ale nie mówi, co i jak zespół ma robić, aby dostarczyć produkt. Z drugiej strony, praca nad doświadczeniem użytkowników i organizacją interfejsu z reguły podlega procesowi. W naszym przypadku jest to proces User Centered Design Proces, który ma jasno określone etapy, które należy wykonać, aby przekazać projekt zespołowi developerskiemu.

Co ważniejsze, tak jak pisaliśmy w artykule o podejściu agile i lean UX, Scrum Guide mówi jedynie o organizacji pracy developerów – i niestety, praca projektantów UX i UI nie była brana pod uwagę, kiedy opracowywano Scruma, a to powoduje szereg wyzwań dla designerów. Oto niektóre z nich:

  1. Ciasne okienka projektowe – projektanci przede wszystkim narzekają na ciasne okienka projektowe. Większość projektantów jest przyzwyczajona do pracy w innym podejściu do tworzenia produktów – User Centered Design Process, który ma własne etapy pracy. Zaczyna się od odkrycia i zdefiniowania problemu, a kończy się na zaprojektowaniu rozwiązania, które wcześniej przeszło przez serię testów z użytkownikami.
  2. Sprinty ma dostarczyć przyrost a niekoniecznie skończony produkt – Scrum to sposób wytwarzania produktów w oparciu o Scrum Guide. W przeciwieństwie do procesu UCD, który nie ma ściśle określonych ram czasowych, Scrum działa w tygodniowych lub dwutygodniowych Sprintach, które mają jasno sprecyzowany cel i mają dostarczyć przyrost (ang. increment). Przyrostem nie musi być przetestowane rozwiązanie problemu użytkownika – to może być ważna część kodu, która jest ukończona i gotowa do wydania.
  3. Scrum ma pomóc developerom w lepszej efektywności pracy – Scrum dba o to, aby praca zespołu była jak najbardziej zoptymalizowana. Ceremonie w Scrumie służą do tego, aby developerzy śledzili swój postęp względem Celu Sprintu i w porę reagowali na zmieniające się okoliczności, ale przede wszystkim po to, aby nauczyli się pracować w wydajny sposób. Developerzy i Scrum Master (facylitatorem pracy w Scrumie) zbierają informację zwrotną, która pomaga im podejmować lepsze decyzje.
  4. Informacja zwrotna w Scrumie jest po to, aby pracować wydajniej – Projektanci UX i UI również są przyzwyczajeni do wydajnej pracy, która nakierowana jest na uzyskanie informacji zwrotnej. Jednak w przeciwieństwie do zespołu developerów ta informacja zwrotna jest trudniejsza do przewidzenia, gdyż nie polega tylko na udoskonaleniu praktyk zespołu lub technik inżynieryjnych. Feedback, jaki uzyskują projektanci UX i UI pochodzi od użytkowników i wynika z psychologii oraz życiowych doświadczeń. Nawet najbardziej doświadczony projektant nie jest stuprocentowo pewien, czy zaproponowane rozwiązanie jest właściwe, posiłkując się jedynie swoim przeczuciem. Dlatego tak ważne są testy UX.
  5. Scrum jest nieoceniony, jeżeli chodzi o skomplikowane tworzenie produktów, ale co z etapami tworzenia specyfikacji użytkownika? – niektórzy ślepo ufają Product Ownerowi w tym zakresie, inni decydują się na prowadzenie Design Sprintów lub Sprintu 0. Jednak to projektanci są adwokatami użytkowników w zespole. Powinni mieć przestrzeń do tego, aby zbierać informację o użytkownikach, aby spełnić tę rolę.

Jak włączyć zespół UX do Scruma?

Internet roi się od przypadków, w których ludzie używają Scruma do celów innych niż rozwój oprogramowania (np. przy budowie domu, zarządzaniu ogniskiem domowym lub w sprzedaży i marketingu). Scrum jest dużym udogodnieniem, jeśli chodzi o organizację pracy developerów – zapewnia efektywność, usprawnia komunikację, przyznaje autonomię i zbliża zespół do siebie. Projektanci UX i UI też mogą na tym skorzystać, jeśli rozprawimy się z najczęściej spotykanymi wyzwaniami związanymi z pracą nad UX i UI w Scrumie. Jak to zrobić? Jeśli chodzi o nas, to radzimy sobie z tym przez stosowanie się do kilku zasad.

Zasady efektywnej integracji UX i UI ze Scrumem

Wyróżniliśmy pięć zasad, które pozwalają projektantom na komfortową pracę w Scrumie.

  1. Projektanci wiedzą, jak działa Scrum – każda osoba, która jest częścią zespołu produktowego, powinna rozumieć, na czym polega Scrum, do czego służą eventy Scrumowe. Warto to powtórzyć nawet jeśli większość pracowała już w Scrumie.
  2. Developerzy rozumieją, na czym polega rola projektantów w zespole produktowym – projektanci razem z Product Ownerem i Scrum Masterem powinni zrozumieć, czym jest UX i UI, poznać procesy projektowania. W blog poście o wartości UX opublikowaliśmy ćwiczenia, które pomogą uświadomić reszcie zespołu, dlaczego UX jest ważny: Jak przekonać zespół i przełożonych do wartości UX?
  3. Projektowanie UX ma miejsce przed developmentem – aby zmieścić się w Sprincie, specjaliści od Scruma sugerują, aby projektowanie było ukończone przed developmentem. W wielu organizacjach projektanci doszlifowują projekty, przygotowując specyfikację i finalny projekt w tym samym Sprincie, w którym ma miejsce kodowanie projektu.
  4. Research i testy UX są wpisane osobno do backlogu – większość projektantów nie czuje się dobrze w Scrumie, ponieważ brakuje im czasu na wykonanie researchu i testowanie rozwiązań, przez co nie mogą zaprojektować odpowiedniego rozwiązania. Wystarczy przewidzieć czas na research i czas na testowanie w backlogu, zapisując je jako oddzielne taski.
  5. Wykonujemy tylko niezbędne artefakty dokumentacji – zwinne podejście do UX utrzymuje, że tworzymy tylko niezbędne materiały i tak też jest w przypadku Scruma. Prototypy, grafiki, opisy powinny być tworzone tylko wtedy, kiedy tworzą fundament do dalszej pracy, tj. user flow, customer journey maps, wszystko to, co pozwala nam zbliżyć się do celu Sprintu.

Dzięki tym zasadom jesteśmy w stanie projektować w Scrumie bez większych problemów. Jeśli zespół nie będzie wiedział, czym jest Scrum, jak wygląda praca projektantów UX i UI, projektowanie nie będzie poprzedzało developmentu, pominiemy research i testy UX oraz skupimy się na nieprzydatnych artefaktach, napotkamy problemy z pracą projektową ze Scrumem. A jak wygląda integracja designu ze Scrumem w praktyce?

Jak nasza agencja UX/UI współpracuje z zespołami Scrumowymi?

Porównaliśmy Scruma do sposobu projektowania UX i UI, odkryliśmy potencjalne przyczyny niepowodzenia połączenia pracy zespołu designerów ze Scrumem i poznaliśmy zasady współpracy, które pomogą nam przezwyciężyć trudności. W takim razie czas na to, abyśmy opowiedzieli wam, jak to wygląda w naszej agencji. Jak wygląda integracja UX i UI ze Scrumem w praktyce?

Na potrzeby klienta jesteśmy w stanie dostosować się do pracy w Scrumie. Idealnie jest kiedy możemy dołączyć do zespołu od początku projektu, choć zdarzyło nam się, kiedy to musieliśmy rozpocząć pracę, kiedy prace developerskie już trwały. Niezależnie na jakim etapie rozwoju jest produkt, pracujemy dwa tygodnie przed Sprintem developerskim. To daje nam przestrzeń na to, aby skończyć projekt i omówić go z developerami.

A co z Eventami Scrumowymi? Czy bierzemy udział w daily, demo, planowaniu i retro? Jako część zespołu scrumowego, projektanci UX i UI powinni być wszędzie, gdzie zespół uzna, że to koniecznie. Jeżeli w zespole jest osoba, która może reprezentować potrzeby użytkowników w miejscu projektanta, to czasem wystarczy, że taka osoba raportuje UX i UI, co miało miejsce na spotkaniach. Jednak idealnie byłoby, gdyby user stories oraz inne decyzje, które mają wpływ na interfejs użytkownika, najpierw przechodziły przez zespół designerski.

Projektant także działa w trybie doraźnym. Utrzymuje kontakt z resztą zespołu Scrumowego przez wewnętrzny komunikator, np. Slack, śledzi postępy na Jirze i zajmuje się projektowaniem dodatkowych elementów, jeśli czegoś zabrakło, a zajdzie taka potrzeba, aby cel Sprintu został osiągnięty. To samo tyczy się maintenance’u. Projektant przygotowuje wtedy design system lub style guide, sporządza niezbędną dokumentację, a kiedy developer składa widoki, projektant towarzyszy mu, sprawdzając, czy wszystko jest zgodne z projektem.

W jaki sposób wyceniamy taką pracę? Na początku rozliczamy tygodnie pracy, a gdy przełączamy się w tryb maintanace’owy godziny – projektowanie wycenia się godzinowo lub za tzw. Mon-Fri, czyli za dni pracy. Na tym współpraca się nie kończy. Po wydaniu produktu projektanci optymalizują UX, przeprowadzają testy z użytkownikami i dokonują usprawnień na podstawie wyników badań. Rekomendacje na podstawie wyników testów wpadają jako taski do backlogu.

UX i UI w Scrumie jest możliwy

Jeśli nie wytłumaczymy członkom zespołu, jak (i dlaczego) pracuje się w Scrumie, nie poświęcimy czasu, aby zrozumieć znaczenia UX/UI i nie damy przestrzeni projektantom na wykonanie niezbędnych czynności, np. researchu UX lub przetestowaniu projektu, to możemy mieć problem z integracją UX i UI ze Scrumem. Jednak jeśli będziemy trzymali się zasad, to jesteśmy w stanie pracować efektywnie. Pamiętajmy, że Scrum ma służyć naszemu całemu zespołowi a eventy takie jak Retro służą do tego, aby wypracować workflow, w którym wszyscy czują się dobrze.