Niejednorodny zespół

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule - napisali niegdyś mądrzy ludzie i zespół w tej postaci jest super. Jednakże robiąc przegląd inwentarza, możesz dojść do wniosku, że stan rzeczy rzeczy w Twoim zespole oraz zasoby, którymi dysponujesz, odbiegają od tego docelowego obrazka. Co wtedy?

Co jest?

Może się dla przykładu okazać, że "dostałeś" pięciu programistów, trzech testerów, analityka oraz Scrum Mastera z nadania, który ostatnimi czasy poświęcał się wyłącznie zarządzaniu.

W takiej konstelacji możesz się spodziewać następujących objawów:

• Polaryzacja między testerami a programistami; nie piszę "wrogość", lecz właśnie polaryzacja my-wy: wy zrobiliście błąd, wy skopaliście testy, my coś zaimplementowaliśmy, itp.
• Programiści mają chroniczny opór przed testowaniem
• Testerzy biorą znikomy udział w planowaniu
• Analityk nie za bardzo może znaleźć swoje miejsce w zespole
• Pojawia się zastanawiająco dużo spadów z poprzednich sprintów

Może się okazać, że po przeprowadzeniu małego śledztwa, ma miejsce następujący związek przyczyn i skutków:

Jak mogłoby być?

Długoterminowym celem mogłoby być oczywiście doprowadzenie do sytuacji, w której każdy jest wspomnianym "developerem", ale o tym na początku lepiej nie mówić głośno:)

Co pomiędzy?

Sądzę, że w takiej sytuacji kluczowe jest, nie tyle męczyć ludzi, aby byli idealnym zespołem, co wydobyć tu i teraz to, co najlepsze. Bardzo dobrym początkiem będzie przeorganizowanie sposobu planowania. Otóż:

• Planujcie podgrupami dzielonymi względem testerów, np. tester+2*programista
• Każda grupa otrzymuje swoje US, które dzieli na zadania
• Analityk chodzi i doradza :)
• Wyodrębniajcie zadania: programistyczne, testerskie, analityczne
• Po zakończeniu dekomponowania grupa przedstawia swoje US, a reszta zadaje pytania kontrolne Czy uwzględniliście to, a to? i jeśli nie, to dodajemy kolejne zadania (uwaga celowo jest tu odwrócenie: grupa nie przedstawia swoich zadań, lecz odpowiada na pytania kontrolne zespołu, gdyż w przeciwnym razie zamęczycie się i zanudzicie

Pytania retrospekcyjne po wprowadzeniu w/w zmiany (po jednej bądź dwóch iteracjach):

• Jak oceniam współpracę między testerami a programistami?
• Czy wciąż mówimy o sobie my-wy?
• Czy będziemy mieli spady w najbliższej iteracji?
• Jak dużo zadań doszło w trakcie iteracji? Jakiego rodzaju były to zadania?

Kilka słów o roli analityka
Analityk bywa w Scrumie czasem zagubiony. W jaką rolę ma się wcielić Proxy Product Owner, Scrum Master, Product Owner? Jedną z powtarzanych przyczyn zmieszania analityka są te cholerne straty w projekcie. No bo jeśli jedyna wartością jest "działające oprogramowanie", reszta to strata, a jemu kazali pisać dokumentację, to ma poczucie, że wykonuje bezsensowną i bezwartościową pracę.

Myślę, że te "straty" wymagają małego komentarza. Analityku, jeśli w założeniach projektu stoi napisane, że ma być dokumentacja analityczna w projekcie, bo tak wymaga klient, ustawa czy ktokolwiek inny, to dokumentacja również jest wartością w projekcie i również dodaje punty do business value.

Przykładowe zadania, w których analityk może wspierać zespół:

• współpraca i mediacje:) z PO
• backlog grooming
• prowadzenie Product Canvas; ciekawe linki: tutaj, tutaj i tutaj.