working agreement ustalenia współpracy z zespołem

O ustaleniach zasad współpracy

Takie tam

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.


Też chcesz przeprowadzić taką sesję ustalania warunków współpracy ze swoimi zespołem? Zapisz się na newsletter!

Już niedługo i o tym napiszę :) Jeśli nie chcesz tego posta przegapić, to zapraszam Cię na mojego fejsbuka oraz do zapisania się na newsletter.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *