Czym jest zespół? Grupą ludzi – to oczywisty warunek. Ale nie każdy zbiór osób będziemy mogli nazwać zespołem. Potrzebne jest coś, co spaja wszystkich. Będzie tym jeden, wspólny cel. Zespół musi mieć powód swojego istnienia, a bez niego napotkamy na wiele dobrze znanych problemów.
Bez wspólnego celu – bez sensu
Zaczęło się wczoraj, od tematu „Agile odkrywa problemy, a nie je powoduje„. W trakcie pisania tego tekstu zacząłem przypominać sobie wszystkie patologie w budowie zespołów, jakie mieliśmy okazję widzieć i próbować rozwiązać.
Jedną z najgorszych rzeczy, jaką można zrobić osobom wspólnie pracującym nad jednym zadaniem, jest rozdzielenie ich na specjalistyczne zespoły. Oderwijmy się na chwilę od tworzenia oprogramowania i przywołajmy jeden z naszych ulubionych przykładów, czyli remont mieszkania.
Trudno przy remoncie zatrudniać profesjonalistów od wszystkiego i stworzyć z nich Development Team. Niestety, każdy będzie znał się tylko na swojej części pracy. I nawet jeśli wykonają ją właściwie, ale bez porozumienia z innymi, to skutki dla naszego końcowego produktu mogą być opłakane.
Gdy zabraknie wizji, spajającej naszą pracę w całość, to możemy dostać rozwiązanie „teoretycznie poprawne”, ale niespełniające naszych wymagań. Bo hydraulik nie przewidzi, że w tym miejscu nie wystarczy miejsca na zawór, a stolarz niekoniecznie będzie zaprzątał sobie głowę wysokością grzejnika i koniecznością poprowadzenia elektryki.
Ktoś mógłby krzyknąć „Wystarczyłby dobry projekt!”. Tu jednak wychodzi brak doświadczenia takiego krzykacza i nieznajomość realiów remontowo-budowlanych. Bo nigdy nie jest tak, że wszystko można przewidzieć. Nie tylko plany często nie odpowiadają rzeczywistości, ale też nie da się zmusić niepowiązanych ze sobą osób do współpracy. Szczególnie, jeśli odpowiedzialni są za zupełnie rozłączne zadania.
Ekipa budowlana to piękna, chociaż smutna, analogia na zespoły rozproszone. Nie tylko oddalone geograficznie, ale i pod względem odpowiedzialności. Skoro „analitycy” i „testerzy” mają inne zadania, to trudno, żeby ich praca zmierzała ku spójnej wizji przedstawionej przez Product Ownera.
My kontra oni
Podział czegoś, co powinno być jednym zespołem na kilka specjalistycznych tworów promuje tworzenie się „silosów”. Mamy gwarancję, że każdy specjalistyczny zespół okopie się na swoich stanowiskach i będzie zajmował się tylko i wyłącznie „swoją” pracą. Zgodnie z zasadą „skin in the game” będzie ją wykonywał w takim zakresie w jakim odczuwają konsekwencje. I to rodzi problemy.
Gdy „zespół architektoniczny” przygotowuje projekt aplikacji, którego później nie będzie implemenetował, skupi się on na postępowaniu zgodnie z zasadami sztuki i wzorcami projektowymi. Nie weźmie pod uwagę łatwości implementacji w tym konkretnym systemie czy możliwości reużycia już istniejącego kodu. Nie leży to w kręgu jego odpowiedzialności, ale przede wszystkim – w żaden sposób go to nie dotyka.
Sugestia, żeby zwracać na coś uwagę, nie pomoże, jeśli nie odczuwamy bezpośrednio (lub pośrednio) skutków naszych decyzji. Gdy otrzymamy uwagi do naszego projektu, będą to „narzekania deweloperów”. Zupełnie inaczej sytuacja będzie wyglądała, jeżeli wymagania będą realizowane całościowo, przez jeden zespół.
Przebywanie razem i „granie od jednej bramki” zupełnie zmienia postrzeganie innych i ich pracy. To już nie są „kiepskie analizy od analityków”, tylko „nasza kiepska analiza”. Przygotowana przez kolegę bądź koleżankę z zespołu, która siedzi biurko obok. Zamiast bez sensu narzekać na innych, spróbujemy znaleźć rozwiązanie trapiącego nas problemu (np. na Sprint Retrospective).
Czy można podejść do zagadnienia w podobny sposób, gdy nie pracujemy w jednym zespole? Można, ale jak pokazuje praktyka i natura ludzka – zwykle się to nie dzieje. Identyfikujemy się ze swoim „plemieniem” i na jego rzecz pracujemy. Inni są na dalszych miejscach.
Dwa w jednym
Odwrotną sytuacją do niepotrzebnego dzielenia zespołów jest łączenie niepowiązanych ze sobą osób w jedną grupę i przylepienie jej etykietki „zespół”. Jeżeli takie ćwiczenie przeprowadzimy np. w metodyce Scrum, to konsekwencją będą narzekania na „niepotrzebne Daily Scrum„, „brak Celu Sprintu” i „zupełnie bezużyteczny Sprint Retrospective„.
I wcale mnie to nie dziwi, bo jeżeli każda osoba pracuje nad innym zagadnieniem dla innego klienta, to nie mają one ze sobą nic wspólnego. Nie mają nawet powodów, żeby rozmawiać o pracy, ani też poczucia, że pracują nad częścią większej całości. To nie wspólne miejsce pracy, ani nie nazwa w stopce stanowi zespół! Warunkiem koniecznym do zaistnienia takiego tworu jest wspólny cel, czyli w naszym agile’owym światku – wspólny backlog.
Jeżeli po skończeniu swojego zadania nie mogę zabrać się za dowolne inne z Backlogu Sprintu (w ramach swoich kompetencji), to znaczy, że nasz zespół zbudowany jest bez sensu. W Zespole Deweloperskim nie powinny istnieć podgrupy! Nie może więc być „ich” i „naszych” zadań, bo to wyraźnie pokazuje, że nie mamy jednego zespołu, a dwa (bądź więcej) połączone na siłę.
Jak uniknąć wspomnianych powyżej problemów? Przede wszystkim nauczmy się tworzyć zespoły celowe! Nie powołujmy ich „bo mamy ludzi, których trzeba zagospodarować”, ale najpierw zastanówmy się, co chcemy osiągnąć. Z takim celem bądź wizją zbudujmy wstępny backlog i sprawdźmy, kogo tak naprawdę będziemy potrzebowali do jego realizacji.
Jeżeli jesteśmy w stanie obdarować naszym backlogiem więcej niż jeden zespół, z których każdy liczy 4,6 osób (patrz: idealna wielkość zespołu), to zróbmy to właśnie w ten sposób. A jeżeli trudno nam znaleźć 0,6 osoby, to zaokrąglamy to do pełnych pięciu i upewniamy się, że współdzielą oni jeden cel i są prawdziwym zespołem.
Tematykę zespołów i organizacji pracy poruszamy na szkoleniu Zwinna Struktura Organizacyjna, a o dużych organizacjach scrumowych opowiadamy na Skalowaniu Scrum.
