Working Agreement Canvas

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.

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.

Reklama


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.


Jeżeli chcesz poznać więcej wskazówek (hintów), dotyczących danego tematu oraz całego Agile’a (począwszy od kontraktowania po techniki deweloperskie), sięgnij do książki AgileHints.

 

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X