Która z wartości Scruma jest najważniejsza? Devdebata

Czym jest Scrum i jak wygląda praca z nim w praktyce? O to zapytaliśmy Adama Trzcińskiego, Scrum Mastera w XTB, Kamilę Nowak, Projektantkę UX w XTB oraz Annę Bąkiewicz, Scrum Masterkę w Robert Bosch. Z artykułu dowiecie się m.in. o tym, jak poradzić sobie z problemem interdyscyplinarność zespołu a wspólną wyceną w Scrumie.

W devdebacie udział wzięli:

• Adam Trzciński. Team Leader, Senior Developer, Scrum Master w XTB. Swoją przygodę z komputerem rozpoczął kopiując skrót gry na dyskietkę, ale wkrótce potem podzielił ją na “n” dyskietek i zrozumiał, że matematyka i informatyka to jego przeznaczenie. W pracy dużą uwagę przywiązuje zarówno do rozwoju umiejętności technicznych, jak i miękkich. Pasjonat nowych technologii, fan SpaceX i szeroko pojętej eksploracji kosmosu.
• Kamila Nowak. Projektantka UX w XTB, rozwijająca międzynarodowe platformy i usługi inwestycyjne. Z wykształcenia antropolożka, co wykorzystuje w swoim procesie, traktując badania, jako nieodłączny element dobrego designu. Zwolenniczka łączenia technik UX ze zwinnymi metodami wytwarzania oprogramowania. Aktywnie uczestniczy w lokalnych inicjatywach designowych oraz wolontariatach odpowiadających na problemy społeczne i wspierających organizacje pozarządowe.
• Anna Bąkiewicz. IT Analityk oraz Scrum Master w firmie Robert Bosch. Po ukończeniu studiów ekonomicznych swoją karierę rozpoczęła w obszarze zarządzania projektami IT. Ze scrumem związana od prawie 3 lat, choć ze zwinnymi projektami styczność miała już wcześniej, kiedy to w ramach PMO wspierała globalne projekty (zarówno waterfallowe jak i agilowe). Poza pracą, miłośniczka teatru oraz społecznik od urodzenia.

Wyzwania Scrum Mastera

Jakie znasz największe wyzwania w implementacji Scruma?

Adam Trzciński, Team Leader, Senior Developer, Scrum Master: Trudności w implementacji Scrum jest wiele, między innymi dlatego, że sam Scrum Guide nie rozwiązuje wszystkich problemów, z którymi się spotykamy w codziennym życiu i o wszystkim nie mówi. Pewne aspekty zależą od specyfiki projektu czy zespołu, niemniej jednak ważną kwestią jest to, żeby zespół rozumiał potrzebę stosowania Scrum i wiedział, że wiąże się z tym zaangażowanie wszystkich osób. Wyzwaniem może być np. sytuacja, w której jedna z osób nie jest zainteresowana pracą w Scrum lub uważa, że uczestniczenie w wydarzeniach scrumowych to strata czasu. Wtedy należy delikatnie przekonać ją pokazując zalety takiej praktyki. Jeśli zrobi się to w nieodpowiedni sposób, to taka osoba może zdemotywować pozostałych członków zespołu, dlatego praca nad nią jest jednym z najtrudniejszych wyzwań. Nie można też spocząć na laurach, kiedy wszystko wydaje się działać idealnie – nigdy nie jest tak dobrze, żeby czegoś nie można było ulepszyć.

Kamila Nowak, UX Designer: Fundamentalnym wyzwaniem, z którym mierzą się specjaliści praktykujący Scrum jest według mnie koncentracja na wspólnym i całościowym celu, jakim jest dostarczenie działającej, gotowej do wydania porcji usługi odpowiadającej na potrzeby klienta.

Scrum jest pod tym względem bardziej wymagający od modeli kaskadowych, w których każdy specjalista jest odpowiedzialny zwykle tylko za własną pracę, swój wkład domenowy, a odpowiedzialność za tak zwany “big picture” skoncentrowana jest na liderach. Istotne jest tutaj wyjście od problemu, który mamy rozwiązać, oraz nieustanne dążenie do odpowiedzenia sobie na pytanie “jak ja, z moimi kompetencjami, mogę przyczynić się do realizacji celu, w warunkach, które zastaję oraz w kontekście potrzeb i specyfiki prac pozostałych specjalistów?”.

Scrum to zdecydowanie gra zespołowa i to właśnie dobrze zaimplementowana współpraca, daje możliwość “szycia rozwiązań na miarę”, bieżącego reagowania na zmienne środowisko.

Anna Bąkiewicz, IT Analityk oraz Scrum Master w firmie Robert Bosch: Dla mnie największym wyzwaniem było zderzenie wizji „czystego” scruma, którą miałam w głowie, z realnym przypadkiem biznesowym w dużej organizacji. W międzynarodowych korporacjach istnieją pewne procesy i role, które zapewniają porządek i ułatwiają zarządzanie całym przesiębiorstwem. To jednak oznacza, że wprowadzając wybrane podejście projektowe (np. scrum) nie zaczyna się z białą kartką. Za to ma się już wyznaczone pewne ramy, do których trzeba umieć się dopasować. Aczkolwiek scrum nie jest sztywną metodyką, lecz luźnym frameworkiem, więc to dopasowanie jest możliwe…. choć nie zawsze jest łatwe.

Jak stosujesz i identyfikujesz cel sprintu?

Adam Trzciński, Team Leader, Senior Developer, Scrum Master: Wyobraźmy sobie, że idziemy do restauracji. Na sam pomysł o przepysznej zupie borowikowej, kaczce z buraczkami na drugie danie, kompocie z suszu owocowego, kieliszku wina i deserze w postaci waniliowych lodów ze świeżymi malinami cieknie nam ślinka… a na koniec kieliszek naleweczki. Jaki jest nasz główny cel wybrania się do restauracji? Najeść się i zaspokoić chwilowe pragnienie. Czy tak naprawdę kieliszek wina, nalewki, a może sam deser jest dla nas must-have? Czy bez tych dodatków nie odwiedzilibyśmy restauracji, nie najedlibyśmy się? Niekoniecznie. Tak samo jest z celem sprintu.

Planując nadchodzący Sprint Backlog układamy z Product Ownerem różnego rodzaju zadania, ale nie wszystkie z nich są oznaczone najwyższym priorytetem i czasem nieskończenie kilku mniej istotnych zadań nie boli nas tak, jak nieskończenie najważniejszego z nich. Ba! Celem sprintu nie musi być zadanie – często wprowadzam zmiany w samym procesie. Jeśli od kilku iteracji zauważam potrzebę pilnej modyfikacji i natłok zadań mi to uniemożliwia to staram się zasugerować ją jako nasz cel. Cały zespół powinien brać odpowiedzialność za jego dostarczenie. Identyfikacja go nie należy do najprostszych, dlatego jeśli nie pochodzi z punktu widzenia biznesu – często staram się ten temat poddawawać dyskusji na forum zespołowym i zazwyczaj ustalamy jeden, góra dwa główne cele.

Anna Bąkiewicz, IT Analityk oraz Scrum Master w firmie Robert Bosch: Jako scrum master nie jestem za to odpowiedzialna. SM może jedynie przypomnieć product ownerowi o potrzebie identyfikacji takiego celu, aby sprint planning zakończył się nie tylko przypisanymi do sprintu user storiesami, ale również poczuciem zespołu, że kolejny sprint ma konkretną wartość i przybliża nas do osiągnięcia celu produktowego. I to jest chyba słowo klucz. Cel produktu – bez niego ciężko stworzyć cel sprintu.

Development i UX w Scrumie

Jaki masz sposób na integrację developmentu i UX w Scrumie?

Adam Trzciński, Team Leader, Senior Developer, Scrum Master: Za wytworzenie stabilnego oprogramowania odpowiada zespół developerski złożony m.in. z programistów. Jednak jeśli dane funkcje systemu mają być łatwe i praktyczne w zastosowaniu przez użytkownika końcowego niezbędna jest współpraca z UX. Integracja tych z pozoru dwóch oddzielnych światów wcale nie jest taka prosta, ale później okazuje się, że ma wiele wspólnego. Aby osiągnąć stabilność w tej integracji potrzeba trochę czasu i wysiłku po obu stronach. Przede wszystkim należy użyć empatii i postarać się zobaczyć świat z innej perspektywy, zrozumieć oczekiwania drugiej strony, a przy tym określić swoje potrzeby.

Z mojego doświadczenia bardzo ułatwiają również wspólne warsztaty, które pomagają nie tylko w podjęciu decyzji, ale również w osiągnięciu kompromisów. Projektanci UX mogą też aktywnie współpracować z developerami, aby szybko zlokalizować problemy czy poddać analizie swoje pomysły i rozwiązania. Najważniejsze jest jednak to, aby development i UX zawsze szli w parze i przede wszystkim mieli określony jasny cel, do którego wspólnie dążą. Jeśli te dwie drogi się ze sobą spotkają i będą w ciągłym kontakcie, to zaplanowanie zadań i praca nad jednym produktem w dwóch oddzielnych asynchronicznych sprintach nie będzie problemem.

Kamila Nowak, UX Designer: Celem zarówno w UX, jak i Scrum jest rozwiązywanie złożonych problemów, adaptacji produktu, do wymagań klienta. Dlaczego więc integracja tych praktyk nastręcza tyle problemów?

Wynika to według mnie, ze specyfiki obu ścieżek, ponieważ są to dwa rodzaje pracy i dwa rodzaje myślenia. Prace rozwojowe (development) koncentrują się na przewidywalności i jakości, prace projektowe (design) skupiają się na szybkim uczeniu się i walidacji. Jak w związku z tym je pogodzić?

Z mojego doświadczenia, istotne jest aby:

• Cały zespół rozumiał i uczestniczył w obu rodzajach pracy. Jest to możliwe dzięki… braku podziału odpowiedzialności na: projektantów, którzy zastanawiają się, co zbudować, oraz deweloperów, którzy to budują. U nas, w tym celu, dobrze sprawdziła się warsztatowa forma pracy, tak jak już wspomniał Adam. Innym rozwiązaniem jest też praca w design sprintach, w których wszyscy specjaliści (nie tylko projektanci) stawiają sobie za cel sprintu na przykład product discovery, prace odkrywczą, która potem wyznaczy kierunek pracom developerskim.
• Nie tylko Time to Market, ale też Time to Learn. Dedykacja czasu i priorytet, aby dowiedzieć się wystarczająco dużo o problemach, które rozwiązujemy, po to aby podjąć dobre decyzje dotyczące tego, co powinniśmy zbudować.
  Dlaczego jest to tak istotne? Przede wszystkiem pozwala uniknąć marnowania czasu na nadmierne inwestowanie w wysokiej jakości rzeczy, których nie powinniśmy budować w pierwszej kolejności. Dla przykładu: chcemy dostarczyć użytkownikowi funkcje przenoszenia danych z jednego systemu do drugiego, z CRMu do systemu do księgowego. Najlepszym, rozwiązaniem byłaby integracja systemów, ale podczas jej realizacji zespół napotyka problem, którego rozwiązanie jest kosztowne i pracochłonne. Dlatego w pierwszej iteracji szukamy innego rozwiązania dla MVP, może to być w tym przypadku danie użytkownikowi możliwość zbiorczego skopiowania zestawu danych do pamięci podręcznej. Czy jest to najbardziej jakościowe możliwe rozwiązanie – nie, ale pozwala na “dowiezienie” na czas oprogramowania, jednocześnie nadal realizując cel użytkownika i dając zespołowi czas na usunięcie problemów związanych z integracją. Chcemy zdobywać wiedzę o produkcie i użytkowniku tak szybko (i tanio), jak to tylko możliwe. Tak więc prędkość jest ważna również podczas projektowania i product discovery – ale jest to prędkość uczenia się.
• Nie tylko “gotowość do wydania”, ale też “użyteczność”. Przyjęło się myśleć, że kryterium gotowości inkrementu, to taki stan kodu, który po implementacji w środowisku produkcyjnym będzie po prostu prawidłowo działał. A tak naprawdę poprzeczka jest wyżej. Przyrost nie tylko powinien tylko działać, ale też, a może przede wszystkim, powinien odpowiadać na potrzeby użytkownika (i jest to również wymienione w nowym Scrum Guide “Aby zapewnić wartość, Przyrost musi być użyteczny”).

Anna Bąkiewicz, IT Analityk oraz Scrum Master w firmie Robert Bosch: W projekcie, w którym pracuję, nie mamy oddzielnego „UXowca”, dlatego niejako cały zespół jest włączony w te zagadnienia, co ma wiele swoich zalet. Wygląda to tak, że analityk i PO zbierają feedback zarówno od klientów, jak i użytkowników końcowych, aby na jego podstawie doprecyzowywać user stories. Zdarza nam się przeprowadzać badania IDI, ankiety, a w przedpandemicznym świecie nawet warsztaty onsite z użytkownikami. Zaś następnie z całym teamem podczas refinementów staramy się wypracować najlepsze podejście do danego tematu, dzieląc się informacjami i pomysłami. Można powiedzieć, że te aktywności wchodzą w skład naszego „definition of ready”.

Aczkolwiek zdarzało nam się również kilkukrotnie kontraktować wewnętrzny zespół UX do badań nad wybranymi zagadnieniami. I po takim researchu przekładaliśmy wyniki badań na itemy w backlogu.

Oferty pracy z

Jak radzisz sobie z problemem interdyscyplinarność zespołu a wspólną wyceną w Scrumie?

Adam Trzciński, Team Leader, Senior Developer, Scrum Master: Interdyscyplinarność to temat dosyć ciężki i często spędza sen z powiek młodemu Scrum Masterowi. Członkowie zespołu bardzo często błędnie utożsamiają interscyplinarność jako wymienność swoich kompetencji w realizacji zadań. Tester, który nie miał styczności w programowaniu nie zastąpi programisty, a programista nigdy nie będzie myślał tak jak tester. Dlatego Scrum nie wyróżnia ról i konkretnych specjalizacji. Każdy członek zespołu jest nazwany developerem, bo wszyscy są współodpowiedzialni za stworzenie i dowiezienie wartościowego produktu.

W interdyscyplinarności zespołu widzę coś innego – z poziomu każdego członka zespołu to chęć spojrzenia na problem z innej perspektywy, próba zagłębienia się w dane zagadnienie nie zamykając się tylko w swoim obszarze i wsparcie zespołu czy w realizacji danego zadania, czy w ważnej decyzji. Problem interdyscyplinarności bardzo często pojawia się na Refinemencie, gdzie często tworzą się podgrupy osób, które uważają, że nic nie wniosą do danej wyceny, bo to nie jest ich “działka”. Tłumacząc na czym tak naprawdę polega problem interdyscyplinarności i ciągle coachując swój zespół jesteśmy w stanie osiągnąć kompromis – skorzysta na tym nie tylko zespół, ale i sam proces, a w efekcie produkt.

Kamila Nowak, UX Designer: Największym problemem podczas Refinementu wynikającym z interdyscyplinarności zadań jest oczywiście kwestia tego, że specjaliści o różnych domenach nie wiedzą jak wyceniać wzajemnie sobie zadania. Sama miewam z tym problem, kiedy jako projektantka UX przychodzi mi wycenić zadania na przykład dla analityka BI. Rozwiązaniem, które zastosowaliśmy w moim zespole, to wyjście od określenia zadań, które są porównawczą wyceną minimalną. I tak posługując się ciągiem Fibbonacciego, będzie to 1.

Ważne, aby każdy członek zespołu rozumiał poszczególne zadania (developerskie, designowe, testerskie, analityczne, etc.) o tej wartości. Potem podczas planowania posługujemy się analogiami do “referencyjnej jedynki”, co pozwala sprawnie oszacować jego zakres, nawet jeżeli nie praktykujemy danych zadań osobiście – bo rozumiemy z jakich “cegiełek” się składają. Czyli zakładając, że referencyjną jedynką dla zadania związanego z analityką będzie otagowanie jednego eventu, to kiedy analityk wytłumaczy, że dane zadanie wymaga otagowania 30 eventów, wtedy reszta zespołu ma wyobrażenie jaki jest to zakres pracy.

Kolejna rzecz, to nie odpuszczanie wspólnej wyceny (za pomocą np. voting pokera) na rzecz “każdy wycenia dla siebie”. Z biegiem czasu zespół pogłębia wzajemnie swoją wiedzę o specjalności innych osób, a proces planowania z każdym sprintem przebiega coraz sprawniej.

Anna Bąkiewicz, IT Analityk oraz Scrum Master w firmie Robert Bosch: A interdyscyplinarność to problem? Oczywiście, teraz łapię za słówka, ale chcę tylko pokazać, że na tym opiera się scrum. Scrumowe zespoły muszą być inderdyscyplinarne, bo inaczej nie wytworzyłyby wartości.

Jeżeli zaś chodzi o wycenę itemów w backlogu, to oceniają je te osoby, które potencjalnie mogłyby nad nimi pracować. Gdy na planningu lub refinemencie pada pytanie o konkretne user story, wtedy z z całego zespołu włącza się kilka osób, które mają o danym temacie pojęcie. Oni dają swoje propozycje i następuje ustalenie wartości. Zresztą trzeba pamiętać, w samej wycenie nie chodzi tylko o estymacje czasu. Tu chodzi również o wspólne rozumienie zawiłości, z którymi jako zespół będziemy się mierzyć.

Reestymacja zadań w Scrum

W jaki sposób powinna być przeprowadzana reestymacja zadań?

Adam Trzciński, Team Leader, Senior Developer, Scrum Master: Zakończenie sprintu powinno wiązać się ze sfinalizowaniem wszystkich zaplanowanych wcześniej zadań. Jeśli jednak z różnych powodów zdarzają się momenty, gdy zadania nie zostaną zakończone na czas – trzeba je ponownie wyestymować. Znane mi są trzy techniki, czyli: reestymacja w oparciu o pozostałą pracę do wykonania, ponowna estymacja całego zadania na nowo czy też pozostawienie obecnej wyceny. Każda z technik ma swoje wady i zalety – trzeba po prostu znaleźć złoty środek dla zespołu. Zazwyczaj do reestymacji zadań podchodzę tuż po Sprint Review. Z mojego doświadczenia wynika, że należy to robić jak najszybciej, nie tracąc kontekstu m.in. z powodu przerwania prac i ewentualnej przerwy między wydarzeniami Scrum. Pozostałą pracę do wykonania ocenia przede wszystkim osoba, która realizowała dane zadanie i na świeżo jest w stanie przekazać zespołowi więcej szczegółów, aby wspólnie określić pozostałą ilość Story Point.

Anna Bąkiewicz, IT Analityk oraz Scrum Master w firmie Robert Bosch: To zależy o jakiej sytuacji mówimy. Jeżeli ustaliliśmy już coś na refinemencie, a potem dostajemy nowe informacje, które mogą zmienić zakres user story, to należy poruszyć ten temat na planningu. U nas w projekcie na planowaniu zawsze zwracamy uwagę na przypisane wcześniej estymacje i pada niezmienne pytanie – „Czy to jest wciąż aktualne?”.

Co innego, gdy nie dowieźliśmy czegoś w sprincie. Jeżeli dane zadanie było już rozpoczęte, warto wtedy zidentyfikować, co zostało zrobione i czy oddzielenie tego od reszty nieskończonego zadania ma sens. Jeżeli to, co udało się już zaimplementować może istnieć – nazwijmy to – samodzielnie, to dany item zaznaczamy jako DONE, a do backlogu dodajemy nowy item z pozostałym zakresem, którego estymacja (reestymacja?) będzie miała miejsce albo na refinemencie, albo na planningu. Jeżeli zaś nie dowieźliśmy czegoś, ale nawet nie zdążyliśmy się za to zabrać, to estymacja zostaje, choć potwierdzimy ją sobie jeszcze na planningu, na który trafi ten backlog item.

Która z wartości Scrum jest według Ciebie najważniejsza?

Adam Trzciński, Team Leader, Senior Developer, Scrum Master: Wartości są fundamentalną podstawą prawidłowego praktykowania Scrum i osiągnięcia samoorganizacji na poziomie organizacyjnym i zespołowym. Ciężko sprecyzować jednoznaczną odpowiedź, ponieważ dopiero zestawienie wszystkich wartości pozwala na wykorzystanie korzyści Scrum do maksimum. Jeśli jednak miałbym wytypować najważniejszą to wybrałbym zaangażowanie. Według definicji osoba zaangażowana to taka, która oddaje się danej sprawie, jest przekonana o słuszności tego co robi i widzi w tym jasny, określony cel i aby go osiągnąć wkłada w swoją pracę wiele wysiłku. Ten z kolei powinien być nieodzownym elementem pracy nad zadaniami w Sprincie, ale nie tylko. Wysiłek powinniśmy też wkładać w Retrospektywę, podczas której poddając analizie nasze problemy i słabości jesteśmy w stanie cały czas udoskonalać proces. Bez zaangażowania nie można zbudować dobrego procesu, produktu i zespołu.

Kamila Nowak, UX Designer: Wartością Scrum, która obecnie jest dla mnie najbardziej inspirująca jest odwaga. Interpretuję ją jako odwagę do wytyczania nowych ścieżek, zamiast odtwarzania według schematu tego „jak było robione do tej pory”. Sercem zwinnego zarządzania jest ciągłe doskonalenie procesu budowania produktu, czyli przede wszystkim nastawienie na szukanie nowych, lepszych rozwiązań, eksperymentowanie i bazowanie na wynikach tych eksperymentów, czyli na empiryzmie. Zamiast bazowania na teorii, modelach zarządzania, czy formatkach. Wymaga to olbrzymiego zaangażowania całego zespołu, wzajemnego zaufania i właśnie odwagi, ale też daje mnóstwo satysfakcji, coraz większą wiedzę o produkcie i stanowi o tym, że nie powielamy schematów, a stajemy twórcami.

I w końcu kwestia zmian, którym w pracy nad produktem stawiamy czoło na co dzień. Odwaga w zarządzaniu zmianą, szybkość w jej wprowadzaniu jest rewolucją, na którą inne branże, choćby edukacja, czy administracja państwowa wciąż czekają, a my, jako specjaliści IT, już teraz mamy okazję być jej częścią. Praca w Scrumie to praca nad złożonymi produktami, w dynamicznym, burzliwym środowisku. Na co odpowiedzią jest cykl buduj – mierz – ucz się i zmieniaj według tego, czego się nauczyłeś. Nie ma zmiany bez odwagi do jej wdrożenia, oraz eksperymentów, które uczą nas w jakim kierunku jej dokonać.

Anna Bąkiewicz, IT Analityk oraz Scrum Master w firmie Robert Bosch: Moim zdaniem te wszystkie wartości są powiązane. Jedna nie istnieje bez drugiej. Ten temat zasługiwałby pewnie na osobny artykuł, ale w skrócie osobiście widzę to tak: Jeżeli my – jako pojedyncze osoby – oraz jednocześnie jeżeli my – jako zespół – jesteśmy naprawdę zaangażowani w naszą pracę, to skupienie i odwaga przychodzą nam naturalnie. Te wartości bardzo kojarzą mi się z byciem we flow – kiedy ktoś jest tak wciągnięty w dany temat, że z radością podejmuje nawet trudne wyzwania, będąc skoncentrowanym na celu.

Natomiast, gdy jako zespół chcemy dostarczyć najlepsze rozwiązanie, musimy być otwarci na zdanie i pomysły innych. Musimy być również otwarci na zmiany i dzielenie się informacjami. Aby z kolei móc działać w różnorodnym i interdyscyplinarnym zespole nie można pominąć szacunku, który spaja zespół w jedną całość.

Zdjęcie główne artykułu pochodzi z unsplash.com.