Jak wdrażać Design w Scruma? Metoda Pełnej Symultaniczności.

Design w Scrumie

1. Wstęp

Nie ma jedego złotego sposobu na włączenie zadań projektanta w prace Zespołu Scrumowego. Dobra wiadomość jest za to taka, że istnieje kilka metod, które możemy obrać z punkt wyjścia.

Musimy jednak pamiętać, że każda predefiniowana metoda będzie wymagała dostosowania do realiów naszego Zespołu, a sposób w jaki ostatecznie zdecydujemy się działać musi być osadzony w kontekście w jakim powstaje produkt czy usługa.

Istnieje kilka metod, które możemy obrać z punkt wyjścia włączając Design w Scruma. Metoda Pełnej Symultaniczności to tylko jedno z podjeść, które możesz zastosować.

W tym artykule postaram się przybliżyć podejście, które nazywam Metodą Pełnej Symultaniczności. Dowiesz się m.in:

  • na czym polega Metoda Pełnej Symultaniczności
  • jakie są jej plusy i minusy
  • kiedy stosować tą metodą, a kiedy nie będzie ona najlepszym wyborem dla Twojego Zespołu

2.Pełna Symultaniczność – główna zasada

Elementy backlogu, nad którymi w danym Sprincie pracują Designerzy, to te same elementy, nad którymi w tym Sprincie pracują Developerzy.

Dyskusje na temat ostatecznego kształtu implementowanych rozwiązań i towarzyszące im (ewentualne) prototypy powstają w ramach jednego i tego samego Sprintu, w którym przebiega implementacja*. Nie w Sprincie Designerskim, nie asynchronicznie poza Sprintem Głównym.

Działamy wspólnie, w tym samym sprincie. Kropka.

*Działania badawcze mogą oczywiście być prowadzone w uprzedzeniu do Sprintu,  którym będziemy implementować rozwiązania (np. w ramach Spike’ów) – więcej o tym poniżej.

3.Pełna Symultaniczność a odkrywanie potrzeb biznesu i użytkowników

Jeśli decydujemy się na Pełną Symultaniczność pierwsze podstawowe badania i warsztaty odkrywcze powinniśmy przeprowadzić przed rozpoczęciem pracy w Sprintach. Co ważne w ten etap rozwoju produktu musi być zaangażowany cały Zespół Scrumowy, nie tylko Projektanci, Badacze czy Product Owner.

Nie chodzi o to, żeby Developerzy przeprowadzali UX Research (chyba, że chcą i potrafią to robić!), ale możliwość obserwacji badań (np. wgląd w nagrania i raporty z wywiadów pogłębionych), a także uczestniczenie programistów w warsztatach odkrywczych będą niezastąpione w budowaniu problemowego zorientowania całego Zespołu.

Dzięki takiej współpracy wszystkich specjalistów, od wczesnych etapów rozwoju produktu, wytworzymy w naturalny sposób zrozumienie dla problemów biznesowych, które będziemy później, jako Scrum Team, rozwiązywać podczas pracy w Sprintach.

Spike Badawczy

Możliwe jest, że podczas pracy nad implementacją rozwiązań pojawi się potrzeba bardziej szczegółowego zdefiniowania nowo tworzonych modułów. Często wystarczająca będzie dyskusja Zespołu Scrumowego w ramach Backlog Refinementu, czasem jednak będziemy musieli zasięgnąć perspektywy użytkowników lub innych interesariuszy.

W metodzie Pełnej Symultaniczności badania potrzeb użytkowników, a także wszelkie inne działania odkrywcze możemy zamknąć w zadaniach typu Spike. Jak pisze Rafał Markowicz Spike zwykle wykorzystujemy jeśli (…) potrzebujemy „rozpoznać teren” przed podjęciem jakiegoś elementu backlogu produktu do realizacji w sprincie. 

Zadania typu Spike świetnie wpisują się więc w cele Badań UX czy spotkań warsztatowych, które są przecież takim właśnie „rozpoznaniem terenu”. Ważne jest to, że Spike Badawczy musi mieć z góry określony limit czasowy oraz zdefiniowany cel, w którym go przeprowadzamy. Pamiętajmy też o tym, że w jego realizacji mogą (poza designerami i badaczami) uczestniczyć także inni członkowie zespołu.

Pojawia się pytanie organizacyjne czy estymować Spike’i Badawcze w story pointach?  Chociaż ich realizacja będzie konsumowała czas specjalistów, to, podobnie jak Refinementy, nie mają one bezpośredniego wpływu na increment w Sprincie, ich estymacja mogłaby więc zaburzać wartość velocity zespołu. To sugeruje, że zadania typu Spike nie powinny być włączane do estymat. Ostateczna decyzja będzie jednak moim zdaniem uzależniona od specyfiki produktu, pozostawiam ją więc do podjęcia Waszym Zespołom!

Pełna Symultaniczność a planowanie Backlogu Sprintu

W sytuacji, kiedy nie mamy gotowych prototypów, a szczegółowe pomysły na rozwiązania będą powstawać w trakcie Sprintu, uczestniczenie Designera w Planningach jest niezbędne dla poprawnego określenia możliwości Zespołu.

Uczestniczenie Designera w Planningach jest niezbędne dla poprawnego określenia możliwości Zespołu.

To moment, w którym możemy zadać sobie pytanie – jaki stopień zaangażowania ze strony projektanta będzie konieczny przy realizacji danego zadania? Czy Zespół będzie potrzebował szczegółowego prototypu, czy wystarczy schematyczny szkic? A może do rozpoczęcia implementacji wystarczy tylko dyskusja z programistów i projektantów? Z mojego doświadczenia wynika, że na początku pracy nad produktem zwykle konieczne są bardziej szczegółowe prototypu hi-fidelity; w miarę postępu prac, wraz z „dotarciem” się zespołu, często wystarczające jest samo omówienie koncepcji i późniejsze review zaimplementowanych rozwiązań.

Co ważne podczas Planningu Designerzy uczestniczą nie tylko w dyskusji na temat elementów, które będą włączone w kolejny sprint, ale także ich estymacji punktowej.

Dzięki aktywnemu uczestniczeniu w przyznawanie story pointów Designerzy mogą lepiej zrozumieć stopień skomplikowania zadań od strony developerskiej i dzięki temu, w przyszłości,  świadomie proponować rozwiązania mniej lub bardziej czasochłonne pod kątem implementacji. Programiści natomiast stopniowo zaczną rozumieć jakiego zaangażowania ze strony Designera mogą potrzebować do realizacji zadania. Zyskujemy lepsze zrozumienie specyfiki pracy obu stron, większe zaufanie, a co za tym idzie lepszą atmosferę pracy w Zespole.

Przykładowa tablica z opisem punktacji, której używaliśmy w jednym z Zespołów

4. Pełna Symultaniczność a praca w Sprincie

Zaczynamy nowy Sprint – jak w metodzie Pełnej Symultaniczności poprowadzić prace Designerów i Developerów? Nie mamy tu szczegółowych, „przyklepanych” i gotowych do implementacji prototypów. Do realizacji rozwiązań siadamy z czystą kartą, ale (co ważne!) z pełnym zrozumieniem problemu, który mamy rozwiązać!

Z jednej strony może być to dla zespołu trudna sytuacja, szczególnie niewygodna i wprowadzająca nutę dyskomfortu w pracę programistów, którzy nie mają bezpiecznego punktu odniesienia, ściągającego z ich barków odpowiedzialność za ostateczny kształt produktu. Z drugiej jednak strony zyskujemy coś bardzo cennego – możliwość tworzenia rozwiązań w oparciu o perspektywę nie tylko potrzeb użytkownika, ale też biznesu i technologii.

Niezależnie od tego, czy podczas planningu zdecydowaliśmy się na tworzenie szczegółowego prototypu, czy też inną formę przygotowania się do implementacji zadań – zawsze w pracę nad koncepcjami powinniśmy włączać cały Zespół. Developerzy powinni mieć możliwość zasugerowania rozwiązań, zanim zostaną one ubrane w formę wizualną. Designerzy powinni konsultować swoje pomysły z pozostałymi członkami Zespołu i zostawiać im przestrzeń do udzielania feedbacku. Nie wpadnijmy w mini-kaskadę, gdzie tylko Designer decyduje o tym jak będzie wyglądać flow użytkownika i ostateczny kształt produktu. 

Wykres Gantta

Jeśli stosujemy Pełną Symultaniczność to w synchronizowaniu pracy w Sprincie może pomóc nam wykres Gantta.

  • W pionie wylistujmy taski, które mamy zrealizować, w poziomie wypiszmy kolejne dni tygodnia, w których odbywa się Sprint.
  • Każdą ze specjalizacji (np. Design, Mobile, Front-end, Back-end) oznaczmy innym kolorem.
  • Na wykresie zilustrujmy zaangażowanie poszczególnych specjalistów i zależności między ich pracą. Np. jeśli praca nad danym taskiem nie może zacząć się bez zaangażowania ze strony projektanta, oznaczmy kiedy Designer powinien skupić się na zadaniu i jaka forma zaangażowania będzie konieczna.

Zaangażowanie rozrysować możemy w postaci wykresu Gantta

W praktyce jednego z zespołów, w którym pracowałam, Design miał kolor czerwony – czerwone kropki to konsultacje, czerwone bloczki to praca nad wireframe’ami lub bardziej zaawansowanymi prototypami. Sposób w jaki będziecie wykorzystywać Gantta zależy tylko od Was 🙂

Backlog

Jak w swoim artykule, o włączaniu Designu w praktyki zwinne, słusznie zauważa Jeff Gothelf:

Istnieje tylko jeden backlog. Praca developerów, testerów, projektantów, badaczy – wszystko to ląduje w jednym backlogu i jest wspólnie priorytetyzowane przez jeden i ten sam zespół. Jeśli podzielimy pracę na kilka backlogów, to na pewno któryś z nich stanie się “głównym”, a inne zostaną zaniedbane.

Istnieje tylko jeden backlog. Praca developerów, testerów, projektantów, badaczy - wszystko to ląduje w jednym backlogu i jest wspólnie priorytetyzowane przez jeden i ten sam zespół. 

Subiektywnie wolę praktykę, w której nie tworzymy osobnych tasków dla designerów i developerów. Wedle głównej zasady Pełnej Symultaniczności elementy backlogu, nad którymi w danym Sprincie pracują Designerzy, to te same elementy, nad którymi w tym Sprincie pracują Developerzy. Dotyczy to zarówno elementów implementacyjnych jak i badawczych. Jasne jest, że w jednych z zadań będzie konieczne większe zaangażowanie ze strony Developerówm, a w innych Designerów.  Jeśli decydujemy się na Pełną Symultaniczność to moim zdaniem warto jednak dbać o to, aby nie rozgraniczać zadań na czysto designerskie developerskie. To ponownie może wprowadzić w naszą pracę silosy i kaskadę, których chcemy w podejściu zwinnym unikać.

Pełna Symultaniczność – plusy

Pełna Symultaniczność niesie ze sobą wiele pozytywów:

  • Gotowe rozwiązania dostarczane są bardzo szybko, w trakcie jednego Sprintu – a więc po upływie np. 2 tygodni mamy gotowy, namacalny fragment systemu, który możemy poddać walidacji (np. testom użyteczności) w środowisku testowym, lub bezpośrednio w środowisku produkcyjnym.
  • Odpowiedzialność za kształt produktu spoczywa na całym Zespole Scrumowym, dzięki temu zaangażowanie Zespołu wzrasta, a działa toczą się na najwyższych obrotach
  • Jeśli z jakiś powodów, w którymś z zadań wymagane będzie wypracowanie innego, niż wstępnie planowaliśmy, podejścia to mamy możliwość szybkiego wprowadzania zmian. Pracujemy w jednym Sprincie i nad tymi samymi elementami, więc dzieje się to bez zaburzania planu pracy Designerów, którzy w przypadku pracy asynchronicznej mogliby być już zaangażowani w zupełnie inne zadania.

Pełna Symultaniczność – minusy

Wdrażając Pełną Symultaniczność w nasze procesy możemy napotkać też na wyzwania:

  • Zwalidowanie poprawności założeń w uprzedzeniu do implementacji pomysłów jest trudne. Musimy więc liczyć się z tym, że jeśli nasze założenia okażą się błędne, w kolejnych Sprintach już zrealizowane zadania będą wymagać iteracji tak koncepcji jak i kodu.
  • Praca jest bardzo intensywna i może być wyczerpująca. Wymagana jest bardzo dobra komunikacja, a wdrożenie Pełnej Symultaniczności, zanim Zespół zacznie działać „jak w zegarku” może okazać się czasochłonne.
  • Dla zapewnienia dobrej jakości pracy wszyscy członkowie Zespołu muszą być zaangażowani na dużą część etatu.  Praca projektanta na pół etatu, szczególnie w pierwszych sprintach może okazać się niewystarczającym zaangażowaniem.

Pełna Symultaniczność – kiedy jej nie stosować?

Pełna Symultaniczność nie jest metodą, która będzie odpowiednia do pracy w każdym z przypadków.

Pełna Symultaniczność nie jest metodą, która będzie odpowiednia do pracy w każdym z przypadków. 

Metodę tą można stosować jeśli zespół ma pełne zaufanie ze strony klienta, a kontekst, w którym powstaje produkt nie wymaga akceptacji prototypów przed rozpoczęciem prac implementacyjnych. Jeśli pracujemy nad produktem z branży, która podlega wielu regulacjom prawnym i ostateczne flow użytkownika, lub copy z których będziemy korzystać wymagają akceptacji ze strony wielu osób (np. działu prawnego / marketingu) Pełna Symultaniczność zamiast spodziewanych efektów może przynieść frustrację i rozczarowanie.

Znajdź swój sposób

Tak jak pisałam we wstępie do artykułu:

Każda predefiniowana metoda będzie wymagała dostosowania do realiów naszego Zespołu.

Mam nadzieję, że ten artykuł będzie dla Was inspiracją do wypróbowania Pełnej Symultaniczności – traktujcie go jako punkt wyjścia –  pamiętajmy o tym, że proces to narzędzie, które możemy dostosować pod siebie, więc wszelkie zmiany i wariacje są tutaj w pełni dozwolone!

Jeśli nie Pełna Symultaniczność, to co?

Jeśli jesteście zainteresowani innymi metodami, które możemy stosować wprowadzając Design w Scruma to na początku lipca 2021 będę prowadzić szkolenie na ten temat!

? Design w Scrumie w praktyce. 7-8 lipca 2021 

Na szkoleniu dowiecie się:

  • Jak, krok po kroku, włączyć designerów w pracę zespołów zwinnych
  • Jakie są najważniejsze zasady i metody pracy designera w ramach Zespołu Scrumowego
  • Jak efektywnie planować pracę designerów w podczas Sprintu
  • Jakie jest miejsce designu w Backlogu Produktu i Sprintu
  • Jakie wyzwania towarzyszą symultanicznej pracy Designerów i Developerów
  • Jak skalować procesy zwinne w zależności od typu organizacji
  • Gdzie w procesach zwinnych leży miejsce Product Discovery, w tym badań UX

W razie pytań piszcie śmiało na hello@czasnadesign.com