Było już o introwertykach, a dziś nadszedł czas na indywidualistów. Zapraszamy do cyklu „ból głowy Scrum Mastera”.
„Dajcie mi pracować!”
W tekście pod tytułem „Zostawcie programistów w spokoju!” wspominałem o niechęci niektórych osób do wpisania ich pracy w jakąkolwiek ramę. Przecież wystarczy tylko „klepać kod”, a robota w końcu zostanie zrobiona, produkt ukończony, a klient zadowolony, nieprawdaż?
Wszyscy wiemy, że tak nie jest. Rzeczy, które robimy, muszą spełniać pewne wymagania. Nie potrafimy wcielić się w rolę naszego użytkownika bądź klienta. Dlatego tak potrzebne jest spojrzenie z boku, maksymalizowanie dostarczanej wartości (w kontekście chociażby kolejności elementów w Backlogu Produktu) oraz organizowanie pracy tak, abyśmy nie marnowali czasu na rzeczy zbędne (patrz: pragmatyzm).
Rzucenie się na „Hurra!” na pracę jeszcze żadnemu produktowi nie wyszło na dobre. Zainteresowanych moimi argumentami odsyłam do wspomnianego tekstu. Dzisiaj bowiem zajmiemy się zupełnie innym tematem. Chodzi o osoby, które współpracować z zespołem po prostu nie potrafią. Część argumentów się powtórzy, ale inne będą dla nas zupełnie nowe.
„Nie będę marnował czasu na retro!”
Sprint Retrospective jest spotkaniem, któremu najczęściej „obrywa się” w pierwszej kolejności. Jedni nie chcą chodzić na „sesję narzekania”. Inni zaś uważają, że to czyste marnowanie czasu. Oczywiście dobry Scrum Master będzie w stanie tak pracować z zespołem, aby ten widział dla siebie korzyść z retro. A skoro na nim skorzysta, to będzie też ochoczo w nim uczestniczył.
Gorzej, jeżeli zostanie nam jedna osoba, która woli ten czas spędzić przy komputerze i za nic nie uda jej się zaciągnąć na spotkanie.
Takie osoby często mają też problem z Daily Scrum. I chociaż trwa on maksymalnie 15 minut, to i te z pozoru niewinne (a bardzo korzystne) wydarzenie Scrum miewa swoich przeciwników. Znajdziemy ich najczęściej wśród ludzi, którzy chcą pracować „po swojemu”, mieć „swoje” zadania i robić „swoją” robotę. I to najlepiej bez oglądania się na innych.
Po takich oczekiwaniach widzimy, że dana osoba może nie być graczem zespołowym. Co gorsza, może być wojującym indywidualistą.
„Poradzę sobie sam!”
Nawet najlepszy ekspert i profesjonalista ma limit tego, co jest w stanie osiągnąć samodzielnie. Czasami chodzi o kwestie umiejętności, a najczęściej – o czas, który mamy przecież ograniczony do jednego Sprintu. Żeby w jednym Sprincie wytworzyć jakąś realną wartość dla klienta, bardzo często kilka osób musi połączyć siły.
Jak wspominaliśmy przy okazji znęcania się nad wielkością zespołu, idealna wynosi „około 5 osób”. Nie na darmo mówimy, że „co dwie głowy, to nie jedna” – każda nowa osoba w zespole to nowe spojrzenie na sytuację, dodatkowa wiedza i umiejętności oraz oczywiście kolejne ręce do pracy. Jednak w okolicy piątej bądź szóstej nowej osoby każdy kolejny członek zespołu powoli przestaje powiększać jego efektywność.
Im większy zespół, tym bardziej powiększa się liczba kanałów komunikacji, a także rozprasza odpowiedzialność. Nie zmienia to jednak faktu, że od jednej, aż do tych „około pięciu osób” produktywność zespołu jako całości ma szansę być większa niż suma produktywności poszczególnych jego członków. Szczególnie jeżeli dobrze podzielą się oni zadaniami.
Nie ma siły, nasz „ekspert indywidualista” choćby zjadł tysiąc kotletów, to nie będzie tak efektywny jak pięcioosobowy zespół. Co prawda może narzekać, że „pięć takich osób jak on pracowałoby wydajniej”, ale ludzie są różni i trudno nam będzie znaleźć klony takiej osoby.
Praktyka pokazuje, że pięć osób pracujących razem ma dużą szansę na uzyskanie lepszych efektów, niż pięciu indywidualistów. No chyba, że efekty liczymy tylko i wyłącznie liczbą napisanych linii kodu. Ale nie taki jest cel zwinności, ani nie to jest podstawową miarą postępu.
„Inni mi tylko przeszkadzają!”
Scrum w swoim założeniu opiera się o pracę w grupach. Scrum Team jest samoorganizujący się i kross-funkcjonalny. Nie wyróżniamy w nim podgrup, ani tym bardziej indywidualistów. Osoba, która przejawia tendencje do robienia „swojej pracy po swojemu” przede wszystkim jest kiepskim pracownikiem.
Wynikać to może z nieznajomości zasad i/lub korzyści płynących z pracy w grupach. Temat na pewno warto zbadać na Sprint Retrospective. A jeżeli zespół nie będzie w stanie rozwiązać go samodzielnie, to Scrum Master powinien „scoachować” takiego indywidualistę i pokazać mu wspomniane zalety i przekonać go chociażby do spróbowania.
Warto też – indywidualnie bądź grupowo – odnaleźć prawdziwy powód, dla którego ta osoba woli pracować sama, a nie nad wspólnymi wyzwaniami. Na pewno część osób „po prostu tak ma”, a część nigdy nie pracowała w środowisku wpierającym pracę zespołową. Przez budowę naszego tribe’u, zwiększanie odpowiedzialności i okazywanie zaufania jesteśmy w stanie niektóre osoby zachęcić do tej formy pracy.
Natomiast jeżeli to nie działa, ani nie działają rozmowy wychowawcze i prośby pozostałych członków zespołu, to niestety czasami trzeba takiej osobie znaleźć inne, indywidualne zajęcie. Tu różnimy się od wielu osób, które chcą głaskać wszystkich po głowie i „starać się zrozumieć indywidualne potrzeby”. Idea jest piękna, ale każda organizacja ma swój cel, a każdy zespół – pracę do wykonania. Jeżeli postawa jednej osoby negatywnie wpływa na rezultaty osiągane przez całą grupę, to nie możemy takiej sytuacji tolerować w nieskończoność.
Nie mówimy tu przy tym, żeby taką osobę bezwzględnie zwolnić. Możemy natomiast poszukać jej samodzielnego stanowiska bądź zadań niezależnych od innych osób. Jeżeli jest to ekspert, skorzystajmy z jego doświadczeń, ale w taki sposób, aby nie szkodził on na wyniki reszty zespołu.
A jeśli nie jesteśmy w stanie znaleźć dla niego takiego stanowiska, to cóż… Nie każdy musi pracować w zespole, ani tym bardziej – w Zespole Scrumowym.
