Podsumowanie wrześniowego spotkania PAUG

W miniony poniedziałek, 7 września, odbyło się pierwsze po wakacyjnej przerwie spotkanie poznańskich miłośników zwinności, znane jako PAUG. W ramach spotkania Marta Kossowska iPoznan Agile User Group Łukasz Aziukiewicz przedstawili prezentację “Proces grupowy w Zespole Scrumowym z perspektywy Scrum Mastera i Product Ownera”. Stwierdzenie, że była to tylko prezentacja, to za mało. Podstawą były slajdy, ale dyskusje jakie one wywoływały, zamieniły prezentacje w warsztat, zapewne zgodnie z założeniami prezenterów :).

Marta jako PO i Łukasz jako SM zostali przypisani do jednego z zespołów w ich organizacji. Nie byłyby w tym nic szczególnego gdyby nie fakt, że zespół liczył 18 osób (sic!). Wydawało im się, że dojrzały zespół (działałający już kilkanaście miesięcy), do którego zostali przypisani, będzie poukładany i będzie produkował wartościowe rzeczy. Jednak szybko rzeczywistość sprowadziła ich na ziemię, ponieważ zespół okazał się być zbiorem indywidualności. Dodatkowo nie kończył realizowanych zadań (“neverending stories”) oraz, z uwagi na fakt że projekt był realizowany dla pośrednika, a nie klienta docelowego, nigdy nie widział tego ostatniego – nie wiedział jak i po co używany jest produkt. 

W dalszej części wpisu skupię się na opisaniu poszczególnych faz modelu słowami kluczowymi, których użyli prowadzący. 

Marta i Łukasz podczas wystąpenia

Marta i Łukasz podczas wystąpienia

PO i SM zaczęli patrzeć na zespół poprzez pryzmat modelu Tuckmana, którego opis dla niewtajemniczonych możecie znaleźć tu

Oboje zaczęli pracę z zespołem od zbudowania zaufania. Jest to chyba najistotniejszy element z pierwszej fazy modelu Tuckmana, określanej jako “forming”. Jak zbudować zaufanie w zespole, który jest zbiorem indywidualności, nie posiada Product Backlogu, nie widzi żadnych problemów wokół i wewnątrz siebie? Według prowadzących – na przykład poprzez pokazanie im rzeczywistości. Pokazanie im przez osobę z zewnątrz, że ich rzeczywistość jest trochę wykrzywiona. Co ważne jednak, w czasie formingu nie powinniśmy rezygnować z ograniczeń, jeśli zespół wcześniej jakieś posiadał. Powinniśmy je mieć i dobitnie pokazać zespołowi, czym one są, z jakimi ograniczeniami mamy do czynienia, aby zespół zrozumiał, że jest to świat, w którym musi nauczyć się na nowo poruszać.

Dopiero zbudowanie zaufania w zespole, na przykład poprzez wskazane czynności, spowoduje, że zacznie on dojrzewać do fazy drugiej określanej jako “storming”. Zespół dojrzał do konfliktu, który jest sztandarowym hasłem drugiej fazy modelu. Objawiło się to także w znamiennym stwierdzeniu, że Scrum u nich nie działa, więc teraz będą robić Kanbana. Zespół nadal nie miał jednego Product Backlogu i ciągle miał problem z niską jakością produktu (70% pracy zespołu to było naprawianie błędów). Będąc w tym stanie dojrzałości nie akceptował żadnych norm (stąd pewnie pomysł z Kanbanem, który moim zdaniem jest trudniejszy od Scruma). Mimo chaosu w zespole pozytywne było to, że udało się zachować pewne standardy w postaci retrospektywy (nie nazywanej tak, ale sprowadzającej się do rozmowy zespołu o tym, jak może usprawnić proces) oraz podsumowania pracy na quasi review (w końcu zespół nie funkcjonował w próżni i klient / pośrednik oczekiwał co pewien czas oddanych konkretnych funkcjonalności, czy też poprawionych błędów). Istotne dla tej fazy było również to, co wskazała Marta w odpowiedzi na pytanie jednego z uczestników spotkania: jak poradzili sobie z “asapami” i “fuckupami”. Innymi słowy, jak Owner i zespół radzili sobie z wrzutkami od klienta / pośrednika. Marta jako PO próbowała to w tym czasie ogarnąć. Backlog, który nie znajdował się fizycznie w jednym miejscu, i przyzwyczajenia zespołu na pewno w tym nie pomagały. Próba skanalizowania komunikacji była jedną z metod na uporządkowanie tego problemu. Jeszcze jednym istotnym wyróżnikiem tej fazy było naturalne znalezienie sobie przez zespół wspólnego wroga. Chcę powtórzyć tutaj za głosami, które padły z sali, że na pewno nie jest łatwą rolą bycie Scrum Masterem w takim zespole. Bo to na nim w większości przypadków koncentruje się cała złość zespołu znajdującego się w fazie stormingu. Ale jest w tym wszystkim co najmniej jeden pozytywny element – wspólny wróg jednoczy. I tak też stało się z omawianej drużynie.

W konsekwencji sytuacji zespół podzielił się na trzy mniejsze. Z 18 osób wyodrębniono trzy mniejsze zespoły, mniej więcej po 5-6 osób. Wszystkie pracowały nad jednym produktem, mając na uwadze, że gdzieś “wyżej” istnieje jeden Product Backlog i za wszystkim stoi pośrednik, oczekujący jednego i spójnego produktu. Przy czym pośrednika, czy też klienta nie interesowało, jak pracują – liczył się dostarczany produkt. Zaczęła się również pojawiać własna tożsamość trzech nowych zespołów, wyrażona choćby poprzez nadanie im nowych, własnych nazw. Jeden z zespołów nadał nawet nowe ksywki wszystkim członkom zespołu. Znaleźliśmy się więc w fazie określanej jako “norming”. Co się działo od strony produktu? Występujący zaczęli podpowiadać zespołowi nowe techniki doskonalące backlog, które znalazły uznanie. W konsekwencji użyli na przykład Story Mappingu, czy też zaczęli estymować zadania poprzez użycie rozmiarów koszulek (T-shirt size). Największą wartością, której musieli pilnować PO i SM w tym etapie dojrzewania, była autonomia. Zespół oczekiwał, że będzie mógł uczestniczyć w tworzeniu pewnych rozwiązań. Zespół potrzebował przestrzeni. Naczelne hasło “normingu” według prowadzących to “nie przeszkadzać”, co chyba dobrze podsumowuje tę fazę.

Na spotkaniu było obecnych bardzo dużo osób.

Na spotkaniu było obecnych bardzo wiele osób.

Ostatnią etap dojrzałości określa się jako “performing”. Charakteryzuje się ona zespołem, który ma własną inicjatywę, chce dostarczać wartościowe produkty, a relacje międzyludzkie są ustabilizowane i zespół wie, czego, od kogo może  oczekiwać. Elementami, które świadczyły o tym, że drużyna weszła w tę fazę, było na przykład samousprawnianie się. Objawiło się to propozycją wspólnych dla całego, dużego zespołu reguł code review. Powstał Scrum team, który nie tylko dobrze pracował, ale również zaczął efektywnie usprawniać się. Innym przykładem może być powstanie w końcu jednego backlogu! Może pomogła w tym znajomość priorytetów, które również ograniczyły liczbę wrzutek (na wyżej przytoczoną proporcję należy nałożyć jeszcze jedną – 30/70 na rzecz błędów na początku pracy prezenterów i 70/30 na rzecz rozwoju produktu teraz). Jak sobie radzić z takim zespołem jako SM? Co im zaproponować? Odpowiedzią może być podnoszenie im cały czas poprzeczki. Wytrącanie ich ze strefy komfortu. Te rzeczy powinny pchnąć zespół jeszcze dalej w ramach fazy “performingu”.

Na koniec warsztatu Lukasz i Marta zaprezentowali końcowe wnioski, podsumowujące całą prezentację i to, jak sobie radzić z zespołem:

  • stworzyć bezpieczne środowisko,
  • nie walczyć z zespołem – pewne zmiany muszą trwać,
  • dać przestrzeń zespołowi.

Cały proces zmiany, przejścia przez model Tuckmana trwał około 5 miesięcy. Długo, krótko? Jakie są wasze doświadczenia związane z zespołami?

Dodaj komentarz

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

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x