Zespół to grupa fachowców mająca wspólny cel. Jakie cechy sprawiają, że zespół pracuje wydajniej, a jego członkowie spełniają się zawodowo?

Ludzie są zwierzętami stadnymi. Potrzebują wzajemnej aprobaty oraz odnoszenia wspólnych zwycięstw. Żeby odnosić zwycięstwa, musimy być przygotowani na nowe sytuacje, np. skierowanie produktu do nowej grupy użytkowników. Zespół zawsze gotowy na nowe sytuacje jest zespołem zwinnym (agile team). Zwinny zespół lepiej radzi sobie w zmieniającej się rzeczywistości - rzeczywistości, która nas otacza.

Zwinny zespół posiada co najmniej trzy cechy:

  1. współdzieli cel, sukcesy i porażki,
  2. organizuje swoją pracę samodzielnie,
  3. amortyzuje braki w składzie i zmiany personalne.

Wspólny cel, wspólne sukcesy, wspólne porażki

Podstawową cechą jakiegokolwiek zespołu jest posiadanie wspólnego celu. Cel jest kompasem projektu - określa dokąd idziecie. Posiadając cel, możecie dostosowywać zakres projektu, czas jego trwania lub jakość wykonania. Bez wspólnego celu podejmujecie losowe decyzje bez solidnych podstaw.

Każdy sukces zespołu i każda porażka jest waszym wspólnym mianownikiem. Żaden sukces nie jest indywidualny. Tak samo żadna porażka. Nie ukończyłeś zadania - ukończyliście je wspólnie. To nie kolega Zbyszek dostarczył klientowi zbugowaną fukcję - wszyscy daliście ciała. Każdy z was miał okazję sprawdzić kod i porozmawiać o problemach, więc nie szukajcie kozła ofiarnego. Jeżeli nie mieliście okazji - macie wspólny problem z kooperacją.

Jeżeli udało się wam sprostać trudnemu zadaniu, celebrujcie to. Wspólne wyjście po pracy na kilka głębszych na pewno skończy się historią opowiadaną (w różnych wersjach) przez następne kilka miesięcy. Tak właśnie powstają zgrane zespoły. Gdy nie wszystko poszło po waszej myśli, zastanówcie się wspólnie nad przyczynami. Co pięć głów to nie jedna. Gdy uda wam się zdefiniować przyczyny porażki, określcie akcje do podjęcia. W ten sposób nie sparzycie się drugi raz na tym samym.

Samodzielna organizacja pracy

Podążanie za pierwotnym planem rzadko kończy się dotarciem do celu. Im więcej czynników zewnętrznych wpływa na waszą pracę, tym większa szansa, że oddalicie się od osiągnięcia celu. Dlatego kluczowe jest reagowanie na zmiany zaraz po ich wykryciu, zanim ich skutki się zbyt rozrosną.

Zamiast czekać, aż ktoś zauważy i naprawi problem - zrób to sam. Opowiedz wszystkim o sytuacji, zaproponuj rozwiązanie, nakłoń ludzi do wyrażenia swojej opinii i wprowadź zmiany, jeżeli wszyscy tego chcecie. Podejście samodzielnego reagowania na zmiany nazywa się podejściem proaktywnym. Po przeciwnej stronie mamy podejście reaktywne - bierne oczekiwanie na bodziec, np. decyzję przełożonego.

Podejście proaktywne ma kilka zalet:

  • krócej czekasz na dostosowanie się zespołu lub produktu do sytuacji,
  • rozwiązując problem bezpośrednio u jego źródła, rozwiązujesz go dużo lepiej,
  • w zespole nie powstają napięcia związane z trwaniem w demotywującej sytuacji,
  • zarażasz zespół swoim podejściem, przez co wszyscy działacie coraz efektywniej.

Przykłady podejścia proaktywnego:

Widzisz, że infrastruktura projektu jest ciężka w zrozumieniu i droga w utrzymaniu. Słyszałeś już kilka razy podobne opinie członków zespołu i interesariuszy. Przygotowujesz kilka sposobów na usprawnienie infrastruktury - zaczynasz od najtańszych we wprowadzeniu i dających największe rezultaty. Określasz konsekwencje pozostania w obecnym stanie oraz konsekwencje poszczególnych rozwiązań. Rozmawiasz o nich z zespołem deweloperskim, przełożonym, klientem. Wspólnie ustalacie które działania chcecie podjąć w pierwszej kolejności.

W zespole znajduje się czarna owca - osoba, która torpeduje prace zespołu i nie angażuje się w dostarczanie wartości do projektu. Człowiek jest nowy w zespole i nikt nie chce na niego naciskać. Widzisz jednak, że rośnie napięcie wśród pozostałej części zespołu. Na najbliższej retrospektywie mówisz otwarcie o sytuacji i pytasz świeżaka, w jaki sposób reszta zespołu może mu pomóc. Szukasz rozwiązania, które zadowoli wszystkich - takie rozwiązanie bardzo często istnieje. Jeżeli jednak go nie ma, a czarna owca dalej psuje owoce waszej pracy, mówisz o całej sytuacji przełożonemu i wymagasz od niego podjęcia działań.

Jeżeli nie działasz proaktywnie, to działasz reaktywnie. Podchodząc biernie do problemów możesz spóźnić się z podjęciem akcji. Produkt przestanie pasować do rynku. Koszt utrzymania infrastruktury sprawi, że zarząd zamknie projekt. Czarna owca doprowadzi do fali zwolnień. W podejściu proaktywnym to ty kontrolujesz sytuację. W podejściu reaktywnym to sytuacja kontroluje ciebie.

Projekt - wspólna własność całego zespołu

Projekt jest waszą wspólną własnością. Cały kod i dokumentacja jest waszą wspólną własnością. Zadania i ich opisy są waszą wspólną włanością. Wszystkie artefakty wytarzane w projekcie (kod, dokumentacja, zadania, pomysły etc.) przechodzą przez kilka par rąk, zanim zostaną wdrożone. Nic nie jest dziełem pracy jednej osoby.

Wpólna własność projektu oznacza:

  • mniej nietrafionych pomysłów do zrealizowania,
  • większe zrozumienie celu,
  • lepiej doprecyzowane wymagania,
  • większa odporność zespołu na bus factor.

Wspólny kod

Aby kod był wspólną własnością całego zespołu, konieczne jest zrozumienie wymagań zadania oraz co najmniej wykonanie przeglądu kodu (code review). Programujecie w parach? Tym lepiej.

Jeżeli nie będziecie się wymieniać obszarami projektu i przeglądać kodu kolegów, bardzo szybko się okaże, że wytworzyliście silosy kompetencyjne. Oznacza to tyle, że jedna dziedzina projektu (lub fragment kodu) jest rozumiany i utrzymywany tylko przez jedną osobę. Takie podejście jest tykającą bombą. Eksploduje ona w momencie, gdy zabraknie eksperta kompetencyjnego - na przykład odejdzie z zespołu. Jeszcze gorzej będzie gdy okaże się, że pozostawiony fragment systemu jest kiepskiej jakości, niezrozumiały i nie nadaje się do utrzymania.

Wpólny kod oznacza również, że ludzie spoza zespołu deweloperskiego mogą go modyfikować. Mając jasno określone zasady akceptacji zadania, nic nie stoi na przeszkodzie, żeby właściciel produktu lub scrum master wprowadził zmiany. Programiści nie mają monopolu na programowanie - są do tego jedynie najlepiej przygotowani.

Wspólne zadania

Zadania, które implementujesz jako programista są waszą wspólną własnością. Każdy w zespole powinien wiedzieć jaki jest cel zadania - naczęściej wyraża się to za pomocą opowieści użytkownika (user story, US). Zadanie powinno określać wymagania potrzebne do uznania go za skończone - np. wyrażone w formie kryterów akceptacji (acceptance criteria, AC). Każdy członek zespołu powinien mieć możliwość negocjowania zmian w zadaniu - również w trakcie trwania sprintu. Negocjując zadania jesteście w stanie dostarczyć więcej przydatnych rzeczy. Jeżeli spełnicie cel, możecie uprościć szczegóły. Przykładem uproszczenia szczegółów jest zrealizowanie dużo łatwiejszej implementacji, która zmienia jedynie mało istotne kryteria akceptacji. Każda zmiana musi być uzgodniona z właścicielem produktu (product owner, PO) oraz zaakceptowana przez resztę zespołu. Właściciel produktu nie ma monopolu na tworzenie i spisywanie zadań - jest do tego jedynie najlepiej przygotowany.

Właściciel produktu ma za to monopol na ustalanie priorytetów, o czym warto pamiętać.

Fluktuacja członków zespołu

Projekty wymagające utrzymania spotykają się ze zmianami kadrowymi. Każda zmiana w składzie twojego zespołu spowoduje zaburzenia produktywności i powstanie nowych wyzwań. Nowe osoby trzeba przygotować do bycia członkiem zespołu - nauczyć kultury pracy i pokazać cel. Po starych współpracownikach trzeba wypełnić lukę kompetencyjną. Konieczna może być zmiana zasad, na jakich współpracujecie.

Podsumowanie

Siłą zwinnego zespołu jest zdolność do wspólnego rozwiązywania problemów. Silniejsi podciągają słabszych, słabsi uczą się od silniejszych. Silniejsi poszerzają zakres kompetencji, słabsi ulepszają swoje obecne umiejętności. Pytania słabszych napędzają myślenie silniejszych. Im jesteście lepsi jako zespół, tym lepiej organizujecie pracę i tym bardziej jesteście zadowoleni z jej efektów.