#2 Zespół Scrumowy bez Designera – Design w Scrumie: 7 grzechów głównych

Design w Scrumie

Bez dedykowanego projektanta, który jest aktywnym członkiem zespołu na pełen etat, Scrum Team to po prostu zespół inżynierów.

Jeśli już pracujesz w sposób w pełni zwinny, to na pewno dostrzegasz w tym stwierdzeniu wiele prawdy. Jeśli nadal zastanawiasz się, czy włączanie projektantów w zespoły Scrumowe jest opłacalne i ma sens – zaparz kawę i rozsiądź się wygodnie – spróbuję przekonać Cię nowego podejścia do roli Designera w procesach zwinnych.

2. Designer jako konsultant

W wielu (pozornie) zwinnych zespołach do dzisiaj pokutuje spojrzenie na rolę projektanta, które korzenie ma w kaskadowym modelu pracy. Waterfall opiera się o następujące po sobie fazy tworzenia produktu – w każdą z tych faz zaangażowany jest inny zespół specjalistów. Wiele zespołów scrumowych powiela ten schemat i błędnie zakłada, że praca w sprintach skupia się na kodowaniu wcześniej zaprojektowanych rozwiązań. Myślenie o Designie jako odrębnej fazie pracy omówiłam już szerzej w poprzednim artykule z grzesznej serii.

Przy takim podejściu trudno jest myśleć o projektancie jako o pełnoprawnym członku zespołu scrumowego. W najlepszym scenariuszu rola designera podczas sprintowej implementacji zamyka się więc w postaci konsultanta, który od czasu do czasu komunikuje się z zespołem programistów tłumacząc „jak to ma działać”.  W najgorszym wypadku, ograniczona przez pracę w silosach komunikacja, sprowadza się tylko do szczegółowej dokumentacji, a projektanci zostają zupełnie odcięci od specjalistów implementujących design.

Rola designera podczas sprintowej implementacji ogranicza się często do konsultanta, który od czasu do czasu komunikuje się z zespołem programistów tłumacząc "jak to ma działać".

3. Designer poza zespołem scrumowym – problemy

Wykluczenie designerów z zespołu Scrumowego niesie ze sobą szereg problemów. Nie mówię tu tylko o podejściu, w którym projektanci pracują w odrębnej fazie designu, po której zakończeniu następuje hand-off  ekranów do zespołu developerskiego i tutaj kontakt między specjalistami się urywa. Kwestie, które wypunktowuję poniżej dotyczą także sytuacji, gdzie staramy się działać w sposób zwinny, ale prace projektowe są outsourcowane poza zespół developerski.

Problemy te łączą się częściowo z tymi które wymieniałam w artykule o Fazie Designu.

  • Brak wspólnego zrozumienia problemów i ograniczona możliwość czerpania z różnych perspektyw.
    Jeśli prace projektowe są zlecane designerowi spoza Scrum Teamu, zespół mimowolnie powraca do kaskadowego stylu pracy. Developerzy nie mają możliwości uczestniczenia w kreowaniu rozwiązań i wniesienia w nie swojej perspektywy.  Projektant zostaje natomiast pozbawiony dostępu do aktualnego kontekstu, w którym znajduje się produkt i niuansów biznesowych oraz technologicznych, widocznych tylko jeśli na bieżąco śledzimy rozwój produktu.

Projektant zostaje pozbawiony dostępu do niuansów biznesowych oraz technologicznych, widocznych tylko jeśli na bieżąco śledzi rozwój produktu.

  • Zmniejszone zaufanie do decyzji podejmowanych przez innych specjalistów
    Jeśli nie pracujemy ze sobą na co dzień niełatwo będzie nam nawiązać relacje z pozostałymi specjalistami zaangażowanymi w tworzenie produktu. A to właśnie na relacjach opiera się wzajemne zaufanie i otwarcie się na krytyczny feedback ze strony innych osób. Słynna walka pomiędzy projektantami-artystami, nie-da-się-developerami i „betonami z biznesu” wynika w dużej mierze z braku zrozumienia kolegów i koleżanek z zespołu, o które trudniej jeśli nigdy nie udało nam się poznać ich od bardziej „ludzkiej” strony.

 

  • Brak czasu ze strony projektanta może wpłynąć na opóźnienia w Sprincie
    Gotowość do zmiany jest wpisana w pracę zwinną, często więc wstępnie określone rozwiązania wymagają opracowania nowego podejścia. Jeśli w naszym zespole nie ma dedykowanego designera, który mógłby doraźnie wspomóc nas swoją wiedzą i umiejętnościami, musimy liczyć się z opóźnieniami. Projektant pracujący poza zespołem ma wiele innych zobowiązań i nie zawsze będzie w stanie zarządzić pozostałymi zadaniami w taki sposób, żeby to te z naszego backlogu uzyskały najwyższy priorytet. Może się zdarzyć, że na zaangażowanie ze strony projektanta będziemy musieli czekać nawet kilka dni, a to znacząco wpłynie na przebieg całego sprintu.

 

  • Gorsza jakość dostarczanych rozwiązań.
    Wszystkie problemy, które wymieniłam powyżej – brak czasu na pełne zaangażowanie w problematykę produktu; ograniczony dostęp do perspektywy biznesowej i technologicznej; zmniejszony komfort pracy w zespole – sprowadzają się do jednego rezultatu: rozwiązania, które będziemy dostarczać jako zespół będą po prostu gorszej jakości niż te, które możemy zaproponować z dedykowanym projektantem na pokładzie.

Rozwiązania, które będziemy dostarczać jako zespół bez projektanta, będą gorszej jakości niż te, które możemy zaproponować z dedykowanym designerem na pokładzie.

4. Jakich błędów unikać włączając designerów w Zespoły Scrumowe:

Jeśli zdecydujemy się na zmianę roli projektanta z konsultanta na pełnoprawnego członka Zespołu Scrumowego czeka nas proces, w którym jesteśmy narażeni na pułapki. Jakie są najczęstsze błędy, które popełniamy?

  • Osobny backlog dla zespołu projektantów.
    Praca designerów, developerów i badaczy – wszystko to powinno lądować w jednym backlogu. Jak zauważa Jeff Gothelf: Jeśli podzielimy pracę na kilka backlogów, to na pewno któryś z nich stanie się “głównym”, a inne zostaną zaniedbane [źródło]. Dodatkowo, jeśli w parze z osobnymi backlogami będzie szła praca w osobnych sprintach designerskich i developerskich, wprowadzimy w naszą pracę mini-kaskadę, a więc będziemy pracować w sposób tylko pozornie zwinny. Więcej na temat minusów mini-kaskady z znajdziesz w artykule o błędnej fazie designu.
  • W skład zespołu włączamy tylko UX lub UI Designera.
    Praca w Scrumie to proces niezwykle dynamiczny, wymagający dużej elastyczności i szybkiego reagowania na zmiany. Jeśli w Zespole Scrumowym brakuje którejkolwiek z podstawowych kompetencji, szukanie doradcy ds. UX lub UI spoza teamu opóźni dostarczenie rozwiązań, a dodatkowo może wpłynąć na ich jakość. Wyobraź sobie, że jesteś projektantem UX, do którego programista zwraca się z prośbą o feedback dotyczący UI. Poproszenie o pomoc w ocenie wizualnej części interfejsu UI Designera spoza zespołu może wymagać czasochłonnego tłumaczenia kontekstu, w którym powstał interfejs, który dodatkowo może zostać źle zrozumiany. Warto więc zadbać o to, aby w Zespole Scrumowym znalazł się projektant lub zespół projektantów, łączący kompetencje tak UX-owe, jak i UI-owe.

 

  • Designer pracuje przy więcej niż dwóch produktach jednocześnie
    Pełne zaangażowanie w projekt możliwe jest wyłącznie, jeśli mamy na nie czas. Praca w Scrumie wiąże się nie tylko z regularnym uczestniczeniem w takich wydarzeniach, jak Daily Scrum, ale też ciągłymi iteracjami i dyskusjami dotyczącymi proponowanych rozwiązań. Bycie członkiem więcej niż jednego Zespołu Scrumowego implikuje ciągłe zmiany kontekstu, w jakim działamy, co utrudnia skupienie i pełne wniknięcie w problem. W idealnym świecie projektant powinien być członkiem tylko jednego Zespołu Scrumowego, ale jestem świadoma, że może być to trudne do zrealizowania, szczególnie jeśli dopiero wychodzimy z kaskady i zanurzamy się w nowy, zwinny styl pracy. Sugeruję więc, aby designerów angażować w pracę nad maksymalnie dwoma produktami jednocześnie – to maksimum pozwalające na utrzymanie higieny pracy i kontynuowanie efektywnej realizacji zadań.

Bycie członkiem więcej niż jednego Zespołu Scrumowego implikuje ciągłe zmiany kontekstu, w jakim działamy, co utrudnia skupienie i pełne wniknięcie w problem.

Mam nadzieję, że przekonałam Cię o wartości jaką może wnieść Designer w Zespół Scrumowy. Jeśli zainteresował Cię ten artykuł i chcesz otrzymywać więcej materiałów na temat zwinnego projektowania zapisz się na mój Newsletter!

Czekają na Ciebie:
? Dawka opiniotwórczych artykułów
? Porcja materiałów edukacyjnych
? Dyskusja dotycząca roli Product Designu w świecie Agile.

Dołączając do odbiorców Newslettera otrzymasz dodatkowo mini poradnik “6 podstawowych zasad pracy Designera w Scrumie.”