Był sobie zespół scrumowy. Po kilku miesiącach, od jego utworzenia, zaczęły się w nim srogie tarcia. Prawie każdy na coś lub kogoś narzekał. Przykładowo “Krzysiek wszystko robi wolno, zbyt dogłębnie analizuje, ciągle chce bawić się w refaktoryzację”. Takie problemy wynikały m.in. z różnic w sposobach pracy. Wszyscy chcieli dobrze, ale każdy jednak inaczej.
I nie tylko ten zespół miał taki kłopot. Zespołom brakuje jasnych wytycznych, wspólnych postanowień – potrzebują „working agreement”. Spotykam się z tym dość często. Na tyle często, że teraz z każdym zespołem, z którym zaczynam współpracę, upewniam się, że ustalenia w ogóle istnieją, są wszystkim znane i przez wszystkich rozumiane w taki sam sposób. Do tego wystarczy niedługa sesja, spotkanie, na którym sobie ustalimy lub przejrzymy zasady współpracy.
Często wydaje nam się, że skoro “każdy z nas już gdzieś pracował” i “nikt nie jest zupełnym świeżakiem”, to przecież wiemy jak robić tę robotę. Nie potrzebujemy kodeksu, standardów, bo przecież „my to wszystko wiemy”. Zakładamy, że sprawy się same ułożą – z czasem się dotrzemy i ustalimy wspólne podejścia do problemów, robienia kolejnych projektów. Wydaje się, że spotkanie, na którym pogadamy o “working agreement”, to strata czasu. Kierujemy się niby dobrymi motywami – chcemy skupić się na pracy i bieżących priorytetach, ufamy sobie nawzajem, że będzie dobrze itd. Ale takie ustalenia wspólnych oczekiwań i standardów to nie jest strata czasu. Dzięki nim wiemy czego od siebie wymagać, jakie są nasze priorytety i zasady – jeśli chodzi np. o code review (przegląd kodu), role, odpowiedzialnoci, komunikację, dostępność i wiele innych.
Jednym z najpopularniejszych modelów rozwoju zespołów jest Model Tuckmana. Wg niego, prędzej czy później, każda grupa dochodzi do “Stormingu”, w którym różne doświadczenia, motywacje, charaktery się docierają, prowadząc do konfliktów itp. Z tej fazy niektórym zespołom nie udaje się wyjść i np. zostają rozwiązane, podzielone itp. Ta faza jednak mogłaby przynosić mniejsze straty, mniej konfliktów i szybciej przechodzić w następną fazę („Norming”), gdyby na możliwie wczesnym etapie ustalono jak ze sobą współpracować.
Z zespołem, o którym wspomniałem na początku, zrobiliśmy w końcu taką sesję ustaleń. Okazało się, że oczywiście każdy chciał dobrze, ale do tego “dobrze” próbował docierać w inny sposób, wg własnych przyzwyczajeń i doświadczeń. Udało nam się wypracować wspólne standardy – od prostych typu “nie spóźniamy się na spotkania”, “nie przerywamy sobie wypowiedzi” po te bardziej skomplikowane jak zasady dotyczące code review, workflow, ról i odpowiedzialności. Od tego czasu wracaliśmy kilka razy do tych ustaleń i je aktualizowaliśmy. Gdy były łamane – mieliśmy się na co powołać. Polecam takie ustalenia każdemu – im szybciej tym lepiej i nigdy nie jest za późno ^_^
W poście użyłem ilustracji od Skyla Design.