Najsłabsze ogniwo w zespole scrumowym

W zespole scrumowym wszyscy, niejako solidarnie, są odpowiedzialni za dostarczenie wartościowego i użytecznego przyrostu produktu. Czasem bywa tak, że efektywność takiego zespołu z jakiegoś powodu spada. Zadajemy sobie pytanie, dlaczego tak się dzieje.

Wówczas może pojawić się pokusa „zmierzenia” wydajności poszczególnych członków zespołu, w celu zidentyfikowania tego, który jest „najsłabszym ogniwem”. Czy aby na pewno ten prosty trik jest dobrym rozwiązaniem? Jakie niesie ryzyko? I w końcu: jak inaczej podejść do tematu?

Nie daje mi spokoju pewna rozmowa, której byłem świadkiem, dotycząca identyfikowania słabszych ogniw w zespołach zwinnych w oparciu o metryki. Jeden z rozmówców z przekonaniem tłumaczył, że najlepszym sposobem jest podzielenie prędkości zespołu przez liczbę jego członków. Ten z najmniejszą prędkością osobistą jest najsłabszym ogniwem. Proste?

Pierwsze pytanie, które się nasuwa, to po co mielibyśmy aktywnie poszukiwać takiej osoby. Myślę, że możemy śmiało założyć, że chodzi nie tyle o aktywne poszukiwanie najsłabszej osoby, co o zidentyfikowanie, czy w zespole występuje problem.

Indywidualna prędkość – czy to najlepszy sposób na zidentyfikowanie najsłabszego ogniwa?

Wróćmy zatem do opisanego na wstępie sposobu opartego na prędkości zespołu. Zastanawiałem się nad tym i, przepraszam, ale bałbym się opierać np. na liczbie story pointów realizowanych przez poszczególnych członków zespołu. Żeby móc stosować taką miarę musiałbym się upewnić, że poszczególni ludzie pracują każdy nad „swoim” elementem backlogu, czyli narzuciłbym zespołowi deweloperskiemu sposób pracy. Co więcej, miałbym obawy, że taki sposób pracy stałby w sprzeczności z dobrymi praktykami inżynierskimi – wykluczając, np. programowanie parami.

W doświadczonym zwinnym zespole zrodziłoby to co najmniej podejrzenia, a pewnie nawet konsternację, opór czy wręcz bunt. W mniej doświadczonym reakcja byłaby pewnie mniej spektakularna. Tak czy inaczej miałbym do wyboru: ujawnić moje intencje lub ukryć je przed zespołem.

Załóżmy, że byłbym transparentny w tej kwestii i powiedział o moich intencjach wprost. Jakie byłyby implikacje poza wspomnianym już brakiem programowania parami? Moim zdaniem ryzykowalibyśmy, że członkowie zespołu będą nadmiernie skupiać się nad realizacją „swoich” zadań, a nie będą myśleć o zrealizowaniu wspólnego dla nich celu sprintu.

Co więcej, wiedząc, że będą rozliczani z liczby dostarczonych przez siebie story pointów, mogą zacząć walczyć między sobą o zadania lub co gorsza, zamiast myśleć o priorytetach, zacząć stosować swoje strategie (np.: „może zgarnę dla siebie wszystkie» jedynki« i »dwójki« i wyciągnę z nich dobry wynik” lub „wezmę tę »ósemkę« i przez kilka dni będę ją sobie spokojnie robił, potem jeszcze jakaś mała »dwójeczka« i mogę być spokojny”).

Co w przypadku, kiedy wszystkie zadania w sprincie byłyby już „zajęte”? Bierzemy coś nowego z backlogu produktu, żeby „nabić” sobie osobistą liczbę punktów, ignorując fakt, że w kontekście realizacji celu sprintu jesteśmy daleko w polu. Średnio, prawda?

Kolejne pytanie: jak wpłynęłoby to na jakość? Czy nie byłoby pokusy, żeby odpuścić sobie chociaż część testów, aby szybko zamknąć zadanie i wziąć się za następne? Albo poprosić kolegę z zespołu, żeby przymknął oko i przepuścił pull requesta, bo „jestem do tyłu ze story pointami w tym sprincie”? Jak w takiej sytuacji wyglądałaby wzajemna pomoc przy realizacji zadań? Pomóc koledze kosztem „swojego wyniku”?

Alternatywnie mógłbym nie informować zespołu, do czego są mi potrzebne takie szczegółowe metryki. W tej sytuacji obawiałbym się, że prędzej czy później moje prawdziwe intencje wyszłyby na jaw, a wtedy z dużym prawdopodobieństwem ryzykowałbym utratę zaufania zespołu. No i pojawiłoby się to ryzyko, o którym napisałem wyżej.

W efekcie, zarówno w jednym i drugim przypadku nie dość, że doprowadziłbym do regresu w zaufaniu i wzajemnych relacjach, to w kwestii wydajności i efektywności zespołu, odniósł skutek odwrotny do zamierzonego. Bo o ile indywidualna wydajność, rozumiana jako ilość pracy wykonanej w jednostce czasu przez każdego członka zespołu, prawdopodobnie by wzrosła, o tyle wydajność, a przede wszystkim efektywność całego zespołu, z całą z pewnością by spadła.

Jak zidentyfikować osobę, która ma problem z dotrzymaniem kroku reszcie zespołu?

Wracamy więc do tytułowego pytania, które chciałbym w tym miejscu jednak nieco przeformułować: „Jak rozpoznać osobę, która ma problem z dotrzymaniem kroku reszcie zespołu? I co z tym zrobić?”. Moim zdaniem dotrą do nas sygnały płynące z samego zespołu. Pewnie nie od razu usłyszymy o tym wprost – ludzie nie chcą „donosić” na koleżanki i kolegów. Ale prawdopodobnie pojawią się komentarze w stylu: „Ktoś wie, nad czym właściwie pracuje X?” lub „Och, nad tym zadaniem pracuje X, więc nie wiem, czy uda się to skończyć”. Oczywiście to samo w sobie jeszcze jednoznacznie o niczym nie świadczy, ale na pewno jest sygnałem alarmowym.

Planowanie i codzienny scrum

Tutaj z pomocą może przyjść umiejętnie przeprowadzone planowanie sprintu i codzienny scrum. Dobrze, jeśli zespół w trakcie swojego planowania rozbija elementy backlogu na zadania nie większe niż wymagające jednego dnia pracy i deweloperzy kontynuują tę praktykę przez cały sprint zawsze, kiedy zauważają nowe zadania w obrębie elementu, nad którym pracują. Dzięki temu w trakcie daily bardzo szybko dostrzeżemy, kto trzeci dzień z rzędu pracuje nad tym samym zadaniem.

Oczywiście może pojawić się tłumaczenie, że to jest trudne zadanie, trudniejsze niż zadania innych. Jeśli takie sytuacje będą się powtarzały, nie należy ich ignorować. Jak się zachować? Prędzej czy później któraś z koleżanek lub któryś z kolegów zapyta: „Jak mogę Ci pomóc”? Jeśli nie, to z pewnością zapyta o to Scrum Master. Oczywiście może paść odpowiedź, że: „Nikt nie może mi pomóc”, „Nad tym nie da się pracować w dwie osoby”, „Nie mam problemu, po prostu to jest duże zadanie”.

Wtedy zdecydowanie należałoby zapytać: „Skąd pewność, że nikt nie może pomóc?”. Konsekwentne odmawianie przyjmowania pomocy przy jednoczesnym niewyrabianiu się z zadaniami jest już bardzo niepokojącym sygnałem. I pewnie wymaga rozmowy jeden-na-jeden. Pewnie nawet niejednej.

Dwa warianty rozmowy ze słabszym ogniwem

Widzę dwie możliwości przebiegu takiej rozmowy. W pierwszym osoba przyznaje otwarcie, że sobie nie radzi, że ma braki w kompetencjach, że potrzebuje pomocy, że ma problemy osobiste, które rzutują na jej pracę w ostatnim czasie itd. Wówczas możemy się wspólnie zastanowić, jak takiej osobie pomóc pracować bardziej efektywnie, zdefiniować plan naprawczy, umówić się, jak będziemy monitorować postęp itd.

Jeśli to nie przyniesie rezultatów, wówczas, jakkolwiek trudna decyzja by to nie była, pewnie należałoby się wspólnie zastanowić nad nowymi możliwościami, ale już poza dotychczasowym zespołem. Istnieje również szansa, że taka osoba sama dojdzie do wniosku, że nie jest w stanie nadążyć za resztą i lepiej się odnajdzie w innym zespole.

Druga możliwość zakłada, że taka osoba może też konsekwentnie stać na stanowisku, że wszystko jest ok, po prostu zawsze zajmuje się najtrudniejszymi zadaniami, w których nikt nie może jej pomóc, a my się czepiamy. Słowem – nie chce dostrzec problemu i nie widzi potrzeby zmiany. O ile nie jest to osoba kluczowa, postawiłbym sprawę jasno – albo wdrażamy plan naprawczy, albo się rozstajemy. Jeśli przyjmie w końcu to do wiadomości, zmieni swoje nastawienie i „dogoni” zespół – współpracujemy dalej. Jeśli nie, cóż…

Co wolno mi zrobić, czyli rola Scrum Mastera w zespole

Rola Scrum Mastera na pewno nie polega na zarządzaniu ludźmi. Indywidualny coaching i wspólne zastanawianie się nad tym, jak poprawić sytuację, z pewnością nie są niczym nadzwyczajnym. Pojawia się jednak pytanie, czy Scrum Master może usunąć kogoś z zespołu. W poszukiwaniu odpowiedzi na nie zajrzyjmy do Scrum Guide’a.

Jednym ze wskazanych elementów wchodzących w zakres odpowiedzialności Scrum Mastera jest sprawienie, aby przyczyny ograniczające zostały usunięte. Jeśli zatem przyczyną potencjalnego ograniczania postępu jest zachowanie któregoś z członków zespołu, to jeśli wszelkie próby wpłynięcia na zmianę tego zachowania nie przyniosą efektu, Scrum Master ma obowiązek podjąć dalsze działania. O

czywiście bezpośrednio nie może i nie powinien móc nikogo usunąć z zespołu – to jest rola managera. Jednak wobec wyczerpania innych możliwości i w porozumieniu z resztą zespołu, powinien odbyć poważną rozmowę z właściwym dla danej osoby managerem. Spowodowanie usunięcia kogokolwiek z zespołu, nigdy nie powinno być domyślnym działaniem. Należy je traktować jako „opcję atomową”.

***

Jeśli interesuje Cię tematyka scrum, zajrzyj koniecznie również do innych artykułów naszych ekspertów.