Mieliśmy taki okres na naszym blogu, kiedy publikowaliśmy dużo tekstów opisujących najczęstsze pomyłki, największe błędy i innego rodzaju listy. Dziś wracamy do tego z listą trzech największych błędów popełnianych przy tworzeniu Zespołów Scrumowych.
(Tylko) wspólny przełożony
Bez zbędnego marudzenia zacznijmy od jednego z najczęstszych przypadków, który można zaobserwować na polskiej scenie IT (i nie tylko). Jest nim tworzenie grup ludzi ze wspólnym przełożonym i nazywanie tego zespołami.
Zespół Scrum powinien być samoorganizujący się i sam zarządzać swoją pracą. To znaczy, że wszyscy w takim zespole powinni być na jednym poziomie w hierarchii i wspólnie planować oraz rozwiązywać skomplikowane problemy.
Stworzenie zespołu, w którym mamy formalnie wskazanego przełożonego, który przydziela wszystkim zadania, a następnie ich z nich rozlicza nie ma absolutnie nic wspólnego z samą ideą procesu Scrumowego. Product Owner nie jest niczyim przełożonym i nie przydziela nikomu zadań, a „jedynie” układa je w odpowiedniej kolejności w backlogu! PO nie decyduje w jaki sposób ma być coś zrobione i na pewno nie planuje prac Sprint po Sprincie.
Jeżeli PO samodzielnie analizuje wymagania, a następnie rozbija je na zadania do wykonania i na Planowaniu ustala kto ma zrobić co, to rozpoczyna to całą kaskadę patologii. Taki Product Owner później na Daily weryfikuje czy wszystko „dobrze idzie”, a na Review – rozlicza zespół z wykonanych prac. To jest jakieś totalne nieporozumienie i należy sobie zadać pytanie, po co w ogóle chcemy to nazwać Scrumem?
Takie podejście nic nam nie daje, nie osiągamy żadnych korzyści ze zwinności, a jedynie oszukujemy ludzi, którzy chcą się zatrudnić w naszej organizacji i wydaje im się, że będą pracowali zwinnie. Oszukujemy też samych siebie, bo udajemy, że przeprowadzamy jakąś zwinną transformację, a tak naprawdę cały czas tkwimy w tym samym miejscu.
(Wyłącznie) indywidualne prace w zespole
Drugą pomyłką jest budowanie zespołów ze specjalistów i indywidualistów w taki sposób, aby każda osoba miała swoje określone poletko i żeby przypadkiem nikt nie musiał z nikim współpracować tylko grzecznie przekazywał pracę z rąk do rąk.
Już jakiś czas temu w tekście pod tytułem „Co stanowi zespół?” mówiliśmy, że zespół jest to grupa osób realizująca jeden wspólny cel. Ten cel w Scrumie nazywany jest Celem Produktu i jest jedną z najważniejszych rzeczy, która spaja nam nasze zespoły. Niestety, bardzo często zespół stworzony jest po prostu z osób, które mniej więcej zajmują się podobnymi rzeczami, jednym projektem albo jedną aplikacją. Bez celu, bo i sama aplikacja nie jest rozwijana w żadnym konkretnym kierunku.
Traktowanie każdej osoby indywidualnie, a nie jako zespół, powoduje, że wszystkie wydarzenia, pogardliwie nazywane Ceremoniami Scrum, przestają mieć sens. Przecież na Planowaniu nie planujemy wspólnie pracy, tylko każdy ma swoje własne zadania. Nie ma po co spotykać się na Daily, bo przecież nie mamy żadnych interakcji ani zależności. I tak dalej, i tak dalej. Jeżeli każdy z nas wykonuje swoją indywidualną pracę. to nie ma po co bawić się w jakikolwiek Scrum.
Oczywiście, nie jest tak, że w Zespole Scrum powinien potrafić zrobić wszystko (patrz: kross-funkcjonalność). Natomiast sytuacja, w której każdą kompetencje mamy pojedynczą i zupełnie rozdzielną (patrz: Bus Factor) powoduje masę problemów. I to zarówno z samym planowaniem, jak i dostarczaniem wartości co Sprint.
Jeżeli mamy jednego frontendowca, jednego bakendowca i jednego grafika, to zaraz pojawi się pytanie „Co zrobić, gdy w danym Sprincie nie ma żadnych elementów graficznych do wykonania?” Równie szybko znajdzie się równie interesujące rozwiązanie „To może wypożyczmy tego grafika do innego zespołu albo niech przygotowuje materiały, których w żaden sposób nie będziemy w stanie pokazać klientowi, no ale przynajmniej nie będzie siedział bezczynnie.” Brzmi znajomo?
Scrum nie jest od tego żeby każdy był obłożony pracą na 100%. Naszym celem powinna być powinno być efektywne wytwarzanie wartościowego. A to nie to samo.
Zespoły (za bardzo) specjalistyczne
Trzeci największy błąd, żeby nie powiedzieć grzech, to budowanie zespołów specjalistycznych, które będą wykonywały tylko i wyłącznie kawałek jakieś pracy.
Klasyczną manifestacją, jest tutaj tworzenie zespołu analitycznego, zespołu deweloperskiego i zespołu testerskiego. W takim modelu analitycy tworzą analizę, deweloperzy na jej podstawie tworzą rozwiązanie, a testerzy na podstawie tych dwóch poprzednich rzeczy wykonują swoją pracę. Żaden z tych „zespołów” nie patrzy na gotowy produkt. Żaden też nie jest zainteresowany rozwiązywaniem skomplikowanych problemów przy zachowaniu wysokiej jakości i efektywności. Każdy po prostu „robi swoje”, jak na taśmie.
Oczywiście to tylko jeden z wielu problemów, które ujawniają się w takiej konfiguracji. Zastanówmy się chociażby, jak stworzyć Definition of Done? Co to znaczy, że „analiza została zrobiona”? Kiedy zespół deweloperski kończy swoją pracę, jeśli nie wiadomo czy ta praca jest pozbawiona błędów, bo jeszcze musi zajrzeć do niej zespół testerski? Gdzie tu mowa o wytwarzaniu wartości w każdym Sprincie, skoro analitycy tworzą analizę, która z punktu widzenia naszego klienta jest zupełnie bezwartościowa. Przecież nie jest działającym produktem, nic on z nią nie zrobi.
Te same problemy (i kilka innych) pojawią się, jeżeli nasze zespoły będą podzielone warstwowo – frontend, backend, itd. Znów, po co klientowi sam frontend bez backendu (albo odwrotnie)?
Trzy problemy, jedno źródło
Jeżeli miałbym te trzy typowe błędy podsumować jednym zdaniem to byłaby to zupełna niezgodność naszych zamiarów z przeznaczeniem metodyki Scrum. W podręczniku znajdziemy jasno i wyraźnie napisane, do czego powinniśmy używać Scruma:
„Scrum to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów.” – Scrum Guide 2020
Mamy złożony problem i chcemy rozwiązać go adaptacyjnie. To znaczy, że wiemy jaki ten problem jest (złożony), mniej-więcej wiemy co chcielibyśmy osiągnąć (wizja, Cel Produktu), ale to niech Zespół Scrum rozwiąże go iteracyjnie i/lub przyrostowo. Z każdym kolejnym Sprintem będziemy bliżej tego rozwiązania, a nasi klienci i odbiorcy będą mieli coraz więcej wartości z tworzonego Przyrostu.
Jeżeli chodzi nam o coś innego, np. „efektywne ułożenie pracy”, „sprawne wykonywanie zadań”, „pełne obłożenie każdego członka zespołu”, „łatwe zarządzanie pracą jednego zespołu dla kilku różnych klientów”, „pracę dwa razy szybciej i dwa razy taniej”, to nie tędy droga. Tak samo, jeżeli chcemy w Scruma wcisnąć „klasyczne” myślenie pod tytułem „klient doskonale wie, co chce, a my w szczegółach wiemy jak to wykonać” lub „wystarczy wszystko precyzyjnie przeanalizować, dokładnie zaplanować, a potem już tylko zrealizować”, to napotkamy na mnóstwo problemów. I sami sobie będziemy winni.
