Według badań, które cytuje Scrum Inc, ponad 60% sukcesu zespołu jest tworzone, zanim zespół zacznie pracować. Jest to jasny sygnał, że dobre zespoły się nie zdarzają, ale są tworzone. Dlaczego o tym piszę? Ponieważ Team Working Agreement Canvas, który chcę Wam w tym wpisie przybliżyć, jest elementem uzgodnienia pewnych rzeczy jeszcze zanim zespół zacznie pracować.
Scrum Inc. stworzył template, którego poszczególne elementy w tym wpisie opiszę. Wpis ten jest on rozwinięciem wpisu Kuby dotyczącego wystartowania zespołu scrumowego.
Wiele zespołów pracuje w oparciu o pewne zasady, umowę. Definiuje ona najczęściej kwestię nie spóźniania się na Codziennego Scruma, zachowania umiaru w komentowaniu innych zespołów, silent hours, jak również DoD. Jednak poza w/w zespołami istnieją także takie, które w żaden sposób nie omówiły zagadnień wymienionych w Working Agreement. I przede wszystkim, nie zrobiły tego tuż przed lub tuż po starcie życia zespołu. Ratowaniem sytuacji jest stworzenie umowy w trakcie funkcjonowania zespołu. Bez niej często tylko przypadkiem zespół dogra się na tyle, aby porozmawiać o wszystkich elementach Working Agreement lub zrobi to bardzo późno, co jest oczywistym marnotrawstwem.
Reklama
Prowadząc warsztaty lub obserwacje już istniejących zespołów, często na moją sugestię, że warto zrobić w zespole umowę (kontrakt) słyszę, że “mamy to dograne, nie potrzebujemy, nie podniesienie to naszej efektywności, znamy się przecież”. Prawda (przynajmniej częściowo). Tylko inaczej wygląda moja znajomość, kiedy z kimś rozmawiam przy porannej kawie, a inaczej to wygląda, kiedy jestem z nim w jednym zespole i jako zespół prognozujemy zrealizowanie określonego celu. Innymi słowy musimy na sobie polegać.
Scrum Inc. sugeruje, aby zacząć tworzenie ustaleń zespołu od sekcji 3, 4 i 5. I trudno się z tym nie zgodzić, ponieważ Team Mission (pol. Misja zespołu inaczej cel jego istnienia, Roles & Responsibilities – role i ich odpowiedzialności, Metrics – miary (KPI) ze zespołu i jego produktu) są najważniejszymi elementami.
Przechodząc kolejno przez w/w elementy:
- Team Mission – opisuje cel istnienia zespołu. Po co w ogóle zespół istnieje i co chce osiągnąć w dłuższym (2 – 3 lata) terminie. Zespół został na przykład stworzony po to, aby utrzymać i rozwijać produkt (lub jego określoną część) albo aby realizować projekty z konkretnego obszaru (np. tylko dla banków),
- Roles & Responsibilities – sekcja ta ma za zadanie wskazać określone role występujące w zespole i opisać ich odpowiedzialności. Najlepiej aby wypełnienie tej sekcji wiązało się z dłuższą rozmową zespołu na temat ról, ich odpowiedzialności i oczekiwanych przez zespół zadań jak i opisu tego, co dana rola myśli o sobie. Innymi słowy, jeżeli np. rozmawiamy o liderze zespołu, niech zespół jak i lider porozmawiają jakie są odpowiedzialności i oczekiwania co do konkretnej roli i niech to zostanie zapisane. Sekcja ta powinna również zawierać opis tego, co nie należy do obowiązków danej roli. Przykład takiego podejścia znajdziecie poniżej.
*) na potrzeby tego wpisu Product Manager równa się Product Owner (pol. Właściciel Produktu)
- Metrics – zgadzam się z promowanym przez Scrum Inc. zestawem, który wygląda tak (jest to oczywiście jedna z wielu propozycji. Inny zestaw metryk znajdziecie także w jednym w moich poprzednich postów):
- Velocity – suma ukończonych w danym sprincie zadań spełniających DoD,
- Work Capacity – “pojemność” zespołu przed sprintem; Scrum INC idzie w kierunku mierzenia story points (tudzież innej miary) wszystkich zadań w sprincie, nawet tych nieskończonych,
- Focus Factor – Velocity / Work Capacity – ile zespół realizuje zadań mierzonych w dowolnej skali do “pojemności” zespołu w danej iteracji,
- Percentage of Adopted Work (pol. procent zadań dobranych, nie będących w oryginalnym planowaniu zadań w sprincie) – suma zadań dobranych / przewidywana pojemność sprintu (nie Capacity rozumianego przez Scrum INC, czyli ile wzieliśmy na sprint, a nie ile zostało zrobione lub “rozgrzebane”),
- Percentage of Found Work (pol. procent zadań odkrytych w trakcie iteracji, czyli np sytuacja, kiedy jako zespół odkrywamy, że jednak musimy poprawiać bieżący kod zanim przystąpimy do pracy nad nową funkcjonalnością; może to efekt długu technicznego) – suma estymat znalezionych nowych zadań / przewidywana pojemność sprintu (patrz wyżej),
- Accuracy of Estimation (pol. dokładność szacowania) – zakłada się, że zespół na bieżąco rejestruje wszelkie rozbieżności względem oryginalnego szacowania. Jeżeli tak jest, to metryka powinna wyglądać jako: 1 – (suma delty oryginalnej estymaty / przewidywana pojemność sprintu (patrz wyżej)),
- Accuracy of Forecast (pol. dokładność prognozy) – suma oryginalnych estymat / (suma oryginalnych estymat + suma estymat zadań odkrytych w trakcie iteracji + suma estymat zadań dobranych),
Dopiero po ustaleniu w/w elementów zespół powinien przejść przez pozostałe sekcje takie jak Team Name (pol. nazwa zespołu), Team Motto (pol. motto zespołu), Strengths & Skills (pol. mocne strony zespołu), Gaps & Growth Opportunities (pol. luki (ryzyka) i szanse na wzrost (rozwój), Celebrate & Improve (pol. jak będziemy celebrować sukcesy i jak będziemy poszukiwać usprawnień); to ostatnie jest mocno związane z wpisem Izy dot 5 WHY’s oraz poszukiwaniem wąskich gardeł.
Jeszcze na chwilę chcę powrócić do sekcji Strengths & Skills. Sekcja, jak pisałem wyżej określa mocne strony zespołu, czyli de facto kompetencje. Kiedyś w jednym zespole z którym pracowałem zrobiliśmy taką macierz. Znajdziecie ją poniżej. Oczywiście dane zostały w niej zmienione ale na potrzeby tego co chcę przekazać jest ona wystarczająca. Chodzi mi mianowicie o to, że w zespole mogą występować kompetencje, o których nikt nie wie albo wie o nich bardzo niewielka grupa ludzi. Te kompetencje mogą być wykorzystane do budowy nowych produktów a w skrajnym przypadku do programu rozwojowego. Szczegółowo temat rozwinę w jednym z następnych wpisów.
Wystartowanie nowego zespołu jest z jednej strony bardzo proste, ale jak widzicie powyżej istnieje szereg aspektów, na które warto zwrócić uwagę. Od porozmawiania o oczekiwaniach, poprzez nazwę a na ustaleniu wspólnych celebracji kończąc.
Dokument (wzorzec) znajdziecie pod linkiem Working Agreement.