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.

1 komentarz w “O ustaleniach zasad współpracy

Dodaj komentarz

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