W zespole scrumowym wszyscy, niejako solidarnie, s\u0105 odpowiedzialni za dostarczenie warto\u015bciowego i u\u017cytecznego przyrostu produktu. Czasem bywa tak, \u017ce efektywno\u015b\u0107 takiego zespo\u0142u z jakiego\u015b powodu spada. Zadajemy sobie pytanie, dlaczego tak si\u0119 dzieje. <\/p>\n\n\n\n
W\u00f3wczas mo\u017ce pojawi\u0107 si\u0119 pokusa \u201ezmierzenia\u201d wydajno\u015bci poszczeg\u00f3lnych cz\u0142onk\u00f3w zespo\u0142u, w celu zidentyfikowania tego, kt\u00f3ry jest \u201enajs\u0142abszym ogniwem\u201d. Czy aby na pewno ten prosty trik jest dobrym rozwi\u0105zaniem? Jakie niesie ryzyko? I w ko\u0144cu: jak inaczej podej\u015b\u0107 do tematu?<\/p>\n\n\n\n
Nie daje mi spokoju pewna rozmowa, kt\u00f3rej by\u0142em \u015bwiadkiem, dotycz\u0105ca identyfikowania s\u0142abszych ogniw w zespo\u0142ach zwinnych<\/strong> w oparciu o metryki. Jeden z rozm\u00f3wc\u00f3w z przekonaniem t\u0142umaczy\u0142, \u017ce najlepszym sposobem jest podzielenie pr\u0119dko\u015bci zespo\u0142u przez liczb\u0119 jego cz\u0142onk\u00f3w. Ten z najmniejsz\u0105 pr\u0119dko\u015bci\u0105 osobist\u0105 jest najs\u0142abszym ogniwem. Proste?<\/p>\n\n\n\n Pierwsze pytanie, kt\u00f3re si\u0119 nasuwa, to po co mieliby\u015bmy aktywnie poszukiwa\u0107 takiej osoby. My\u015bl\u0119, \u017ce mo\u017cemy \u015bmia\u0142o za\u0142o\u017cy\u0107, \u017ce chodzi nie tyle o aktywne poszukiwanie najs\u0142abszej osoby, co o zidentyfikowanie, czy w zespole wyst\u0119puje problem.<\/p>\n\n\n\n Wr\u00f3\u0107my zatem do opisanego na wst\u0119pie sposobu opartego na pr\u0119dko\u015bci zespo\u0142u<\/strong>. Zastanawia\u0142em si\u0119 nad tym i, przepraszam, ale ba\u0142bym si\u0119 opiera\u0107 np. na liczbie story point\u00f3w realizowanych przez poszczeg\u00f3lnych cz\u0142onk\u00f3w zespo\u0142u. \u017beby m\u00f3c stosowa\u0107 tak\u0105 miar\u0119 musia\u0142bym si\u0119 upewni\u0107, \u017ce poszczeg\u00f3lni ludzie pracuj\u0105 ka\u017cdy nad \u201eswoim\u201d elementem backlogu, czyli narzuci\u0142bym zespo\u0142owi deweloperskiemu spos\u00f3b pracy. Co wi\u0119cej, mia\u0142bym obawy, \u017ce taki spos\u00f3b pracy sta\u0142by w sprzeczno\u015bci z dobrymi praktykami in\u017cynierskimi \u2013 wykluczaj\u0105c, np. programowanie parami. <\/p>\n\n\n\n W do\u015bwiadczonym zwinnym zespole zrodzi\u0142oby to co najmniej podejrzenia, a pewnie nawet konsternacj\u0119, op\u00f3r czy wr\u0119cz bunt. W mniej do\u015bwiadczonym reakcja by\u0142aby pewnie mniej spektakularna. Tak czy inaczej mia\u0142bym do wyboru: ujawni\u0107 moje intencje lub ukry\u0107 je przed zespo\u0142em.<\/p>\n\n\n\n Za\u0142\u00f3\u017cmy, \u017ce by\u0142bym transparentny w tej kwestii i powiedzia\u0142 o moich intencjach wprost. Jakie by\u0142yby implikacje poza wspomnianym ju\u017c brakiem programowania parami? Moim zdaniem ryzykowaliby\u015bmy, \u017ce cz\u0142onkowie zespo\u0142u b\u0119d\u0105 nadmiernie skupia\u0107 si\u0119 nad realizacj\u0105 \u201eswoich\u201d zada\u0144, a nie b\u0119d\u0105 my\u015ble\u0107 o zrealizowaniu wsp\u00f3lnego dla nich celu sprintu. <\/p>\n\n\n\n Co wi\u0119cej, wiedz\u0105c, \u017ce b\u0119d\u0105 rozliczani z liczby dostarczonych przez siebie story point\u00f3w, mog\u0105 zacz\u0105\u0107 walczy\u0107 mi\u0119dzy sob\u0105 o zadania lub co gorsza, zamiast my\u015ble\u0107 o priorytetach, zacz\u0105\u0107 stosowa\u0107 swoje strategie (np.: \u201emo\u017ce zgarn\u0119 dla siebie wszystkie\u00bb jedynki\u00ab i \u00bbdw\u00f3jki\u00ab i wyci\u0105gn\u0119 z nich dobry wynik\u201d lub \u201ewezm\u0119 t\u0119 \u00bb\u00f3semk\u0119\u00ab i przez kilka dni b\u0119d\u0119 j\u0105 sobie spokojnie robi\u0142, potem jeszcze jaka\u015b ma\u0142a \u00bbdw\u00f3jeczka\u00ab i mog\u0119 by\u0107 spokojny\u201d).<\/p>\n\n\n\n Co w przypadku, kiedy wszystkie zadania w sprincie by\u0142yby ju\u017c \u201ezaj\u0119te\u201d? Bierzemy co\u015b nowego z backlogu produktu, \u017ceby \u201enabi\u0107\u201d sobie osobist\u0105 liczb\u0119 punkt\u00f3w, ignoruj\u0105c fakt, \u017ce w kontek\u015bcie realizacji celu sprintu jeste\u015bmy daleko w polu. \u015arednio, prawda?<\/p>\n\n\n\n Kolejne pytanie: jak wp\u0142yn\u0119\u0142oby to na jako\u015b\u0107? Czy nie by\u0142oby pokusy, \u017ceby odpu\u015bci\u0107 sobie chocia\u017c cz\u0119\u015b\u0107 test\u00f3w, aby szybko zamkn\u0105\u0107 zadanie i wzi\u0105\u0107 si\u0119 za nast\u0119pne? Albo poprosi\u0107 koleg\u0119 z zespo\u0142u, \u017ceby przymkn\u0105\u0142 oko i przepu\u015bci\u0142 pull requesta, bo \u201ejestem do ty\u0142u ze story pointami w tym sprincie\u201d? Jak w takiej sytuacji wygl\u0105da\u0142aby wzajemna pomoc przy realizacji zada\u0144? Pom\u00f3c koledze kosztem \u201eswojego wyniku\u201d?<\/p>\n\n\n\n Alternatywnie m\u00f3g\u0142bym nie informowa\u0107 zespo\u0142u, do czego s\u0105 mi potrzebne takie szczeg\u00f3\u0142owe metryki. W tej sytuacji obawia\u0142bym si\u0119, \u017ce pr\u0119dzej czy p\u00f3\u017aniej moje prawdziwe intencje wysz\u0142yby na jaw, a wtedy z du\u017cym prawdopodobie\u0144stwem ryzykowa\u0142bym utrat\u0119 zaufania zespo\u0142u. No i pojawi\u0142oby si\u0119 to ryzyko, o kt\u00f3rym napisa\u0142em wy\u017cej. <\/p>\n\n\n\n W efekcie, zar\u00f3wno w jednym i drugim przypadku nie do\u015b\u0107, \u017ce doprowadzi\u0142bym do regresu w zaufaniu i wzajemnych relacjach, to w kwestii wydajno\u015bci i efektywno\u015bci zespo\u0142u<\/strong>, odni\u00f3s\u0142 skutek odwrotny do zamierzonego. Bo o ile indywidualna wydajno\u015b\u0107, rozumiana jako ilo\u015b\u0107 pracy wykonanej w jednostce czasu przez ka\u017cdego cz\u0142onka zespo\u0142u, prawdopodobnie by wzros\u0142a, o tyle wydajno\u015b\u0107, a przede wszystkim efektywno\u015b\u0107 ca\u0142ego zespo\u0142u, z ca\u0142\u0105 z pewno\u015bci\u0105 by spad\u0142a.<\/p>\n\n\n\n Wracamy wi\u0119c do tytu\u0142owego pytania, kt\u00f3re chcia\u0142bym w tym miejscu jednak nieco przeformu\u0142owa\u0107: \u201eJak rozpozna\u0107 osob\u0119, kt\u00f3ra ma problem z dotrzymaniem kroku reszcie zespo\u0142u? I co z tym zrobi\u0107?\u201d. Moim zdaniem dotr\u0105 do nas sygna\u0142y p\u0142yn\u0105ce z samego zespo\u0142u. Pewnie nie od razu us\u0142yszymy o tym wprost \u2013 ludzie nie chc\u0105 \u201edonosi\u0107\u201d na kole\u017canki i koleg\u00f3w. Ale prawdopodobnie pojawi\u0105 si\u0119 komentarze w stylu: \u201eKto\u015b wie, nad czym w\u0142a\u015bciwie pracuje X?\u201d lub \u201eOch, nad tym zadaniem pracuje X, wi\u0119c nie wiem, czy uda si\u0119 to sko\u0144czy\u0107\u201d. Oczywi\u015bcie to samo w sobie jeszcze jednoznacznie o niczym nie \u015bwiadczy, ale na pewno jest sygna\u0142em alarmowym.<\/p>\n\n\n\n Tutaj z pomoc\u0105 mo\u017ce przyj\u015b\u0107 umiej\u0119tnie przeprowadzone planowanie sprintu i codzienny scrum<\/strong>. Dobrze, je\u015bli zesp\u00f3\u0142 w trakcie swojego planowania rozbija elementy backlogu na zadania nie wi\u0119ksze ni\u017c wymagaj\u0105ce jednego dnia pracy i deweloperzy kontynuuj\u0105 t\u0119 praktyk\u0119 przez ca\u0142y sprint zawsze, kiedy zauwa\u017caj\u0105 nowe zadania w obr\u0119bie elementu, nad kt\u00f3rym pracuj\u0105. Dzi\u0119ki temu w trakcie daily bardzo szybko dostrze\u017cemy, kto trzeci dzie\u0144 z rz\u0119du pracuje nad tym samym zadaniem. <\/p>\n\n\n\n Oczywi\u015bcie mo\u017ce pojawi\u0107 si\u0119 t\u0142umaczenie, \u017ce to jest trudne zadanie, trudniejsze ni\u017c zadania innych. Je\u015bli takie sytuacje b\u0119d\u0105 si\u0119 powtarza\u0142y, nie nale\u017cy ich ignorowa\u0107. Jak si\u0119 zachowa\u0107? Pr\u0119dzej czy p\u00f3\u017aniej kt\u00f3ra\u015b z kole\u017canek lub kt\u00f3ry\u015b z koleg\u00f3w zapyta: \u201eJak mog\u0119 Ci pom\u00f3c\u201d? Je\u015bli nie, to z pewno\u015bci\u0105 zapyta o to Scrum Master. Oczywi\u015bcie mo\u017ce pa\u015b\u0107 odpowied\u017a, \u017ce: \u201eNikt nie mo\u017ce mi pom\u00f3c\u201d, \u201eNad tym nie da si\u0119 pracowa\u0107 w dwie osoby\u201d, \u201eNie mam problemu, po prostu to jest du\u017ce zadanie\u201d. <\/p>\n\n\n\n Wtedy zdecydowanie nale\u017ca\u0142oby zapyta\u0107: \u201eSk\u0105d pewno\u015b\u0107, \u017ce nikt nie mo\u017ce pom\u00f3c?\u201d. Konsekwentne odmawianie przyjmowania pomocy przy jednoczesnym niewyrabianiu si\u0119 z zadaniami jest ju\u017c bardzo niepokoj\u0105cym sygna\u0142em. I pewnie wymaga rozmowy jeden-na-jeden. Pewnie nawet niejednej.<\/p>\n\n\n\n Widz\u0119 dwie mo\u017cliwo\u015bci przebiegu takiej rozmowy.\u00a0W pierwszym osoba przyznaje otwarcie, \u017ce sobie nie radzi, \u017ce ma braki w kompetencjach, \u017ce potrzebuje pomocy, \u017ce ma problemy osobiste, kt\u00f3re rzutuj\u0105 na jej prac\u0119 w ostatnim czasie itd. W\u00f3wczas mo\u017cemy si\u0119 wsp\u00f3lnie zastanowi\u0107, jak takiej osobie pom\u00f3c pracowa\u0107 bardziej efektywnie, zdefiniowa\u0107 plan naprawczy<\/strong>, um\u00f3wi\u0107 si\u0119, jak b\u0119dziemy monitorowa\u0107 post\u0119p itd. <\/p>\n\n\n\n Je\u015bli to nie przyniesie rezultat\u00f3w, w\u00f3wczas, jakkolwiek trudna decyzja by to nie by\u0142a, pewnie nale\u017ca\u0142oby si\u0119 wsp\u00f3lnie zastanowi\u0107 nad nowymi mo\u017cliwo\u015bciami, ale ju\u017c poza dotychczasowym zespo\u0142em. Istnieje r\u00f3wnie\u017c szansa, \u017ce taka osoba sama dojdzie do wniosku, \u017ce nie jest w stanie nad\u0105\u017cy\u0107 za reszt\u0105 i lepiej si\u0119 odnajdzie w innym zespole.<\/p>\n\n\n\n Druga mo\u017cliwo\u015b\u0107 zak\u0142ada, \u017ce taka osoba mo\u017ce te\u017c konsekwentnie sta\u0107 na stanowisku, \u017ce wszystko jest ok, po prostu zawsze zajmuje si\u0119 najtrudniejszymi zadaniami, w kt\u00f3rych nikt nie mo\u017ce jej pom\u00f3c, a my si\u0119 czepiamy. S\u0142owem \u2013 nie chce dostrzec problemu i nie widzi potrzeby zmiany<\/strong>. O ile nie jest to osoba kluczowa, postawi\u0142bym spraw\u0119 jasno \u2013 albo wdra\u017camy plan naprawczy, albo si\u0119 rozstajemy. Je\u015bli przyjmie w ko\u0144cu to do wiadomo\u015bci, zmieni swoje nastawienie i \u201edogoni\u201d zesp\u00f3\u0142 – wsp\u00f3\u0142pracujemy dalej. Je\u015bli nie, c\u00f3\u017c\u2026<\/p>\n\n\n\n Rola Scrum Mastera na pewno nie polega na zarz\u0105dzaniu lud\u017ami. Indywidualny coaching i wsp\u00f3lne zastanawianie si\u0119 nad tym, jak poprawi\u0107 sytuacj\u0119, z pewno\u015bci\u0105 nie s\u0105 niczym nadzwyczajnym. Pojawia si\u0119 jednak pytanie, czy Scrum Master mo\u017ce usun\u0105\u0107 kogo\u015b z zespo\u0142u. W poszukiwaniu odpowiedzi na nie zajrzyjmy do Scrum Guide\u2019a<\/strong><\/a>. <\/p>\n\n\n\n Jednym ze wskazanych element\u00f3w wchodz\u0105cych w zakres odpowiedzialno\u015bci Scrum Mastera jest sprawienie, aby przyczyny ograniczaj\u0105ce zosta\u0142y usuni\u0119te. Je\u015bli zatem przyczyn\u0105 potencjalnego ograniczania post\u0119pu jest zachowanie kt\u00f3rego\u015b z cz\u0142onk\u00f3w zespo\u0142u, to je\u015bli wszelkie pr\u00f3by wp\u0142yni\u0119cia na zmian\u0119 tego zachowania nie przynios\u0105 efektu, Scrum Master ma obowi\u0105zek podj\u0105\u0107 dalsze dzia\u0142ania. O<\/p>\n\n\n\n czywi\u015bcie bezpo\u015brednio nie mo\u017ce i nie powinien m\u00f3c nikogo usun\u0105\u0107 z zespo\u0142u \u2013 to jest rola managera. Jednak wobec wyczerpania innych mo\u017cliwo\u015bci i w porozumieniu z reszt\u0105 zespo\u0142u, powinien odby\u0107 powa\u017cn\u0105 rozmow\u0119 z w\u0142a\u015bciwym dla danej osoby managerem. Spowodowanie usuni\u0119cia kogokolwiek z zespo\u0142u, nigdy nie powinno by\u0107 domy\u015blnym dzia\u0142aniem. Nale\u017cy je traktowa\u0107 jako \u201eopcj\u0119 atomow\u0105\u201d.<\/p>\n\n\n\n ***<\/p>\n\n\n\n Je\u015bli interesuje Ci\u0119 tematyka scrum, zajrzyj koniecznie r\u00f3wnie\u017c do innych artyku\u0142\u00f3w naszych ekspert\u00f3w<\/a>. <\/p>\n\n\nIndywidualna pr\u0119dko\u015b\u0107 \u2013 czy to najlepszy spos\u00f3b na zidentyfikowanie najs\u0142abszego ogniwa?<\/strong><\/h2>\n\n\n\n
Jak zidentyfikowa\u0107 osob\u0119, kt\u00f3ra ma problem z dotrzymaniem kroku reszcie zespo\u0142u?<\/strong><\/h2>\n\n\n\n
Planowanie i codzienny scrum<\/strong><\/h3>\n\n\n\n
Dwa warianty rozmowy ze s\u0142abszym ogniwem<\/strong><\/h3>\n\n\n\n
Co wolno mi zrobi\u0107, czyli rola Scrum Mastera w zespole<\/strong><\/h2>\n\n\n\n