Fluid Circle

Helping teams be happy and effective

Dzień 12 – Jeden za wszystkich, wszyscy za jednego

Ten artykuł jest częścią cyklu 30 Dni Scrum.

Pamiętasz drużynę A? W każdym odcinku nasi bohaterowie odnoszą sukces dzięki twórczemu połączeniu unikalnych talentów całego zespołu. Hannibal ustala ogólną strategię, Murdock pilotuje samoloty i śmigłowce by drużyna dotarła do swojego celu, Buźka swoim czarem zyskuje niezbędną pomoc od napotkanych osób a B.A. Baracus dostarcza siłę uderzeniową za pomocą własnych mięśni oraz broni improwizowanej z aktualnie dostępnych materiałów.

Dobre zespoły Scrum działają podobnie.

Tak jak pisaliśmy już pierwszego dnia, najważniejszym czynnikiem podnoszacym efektywność zespołu jest motywacja. Aby stworzyć środowisko jej sprzyjające oraz usunąć przeszkody spowalniające zmotywowany zespół Scrum mówi, że powinien on być samoorganizujący oraz interdyscyplinarny, a wszyscy członkowie takiego zespołu powinni być współodpowiedzialni za osiągane wyniki.

Nie zawsze jest jednak jasne, jak te zasady powinny przekładać się na codzienną praktykę. Dlatego dzisiaj przyjrzymy się kilku dodatkowym zasadom i konkretnym metodom pomagającym zbliżyć zespół do hiperproduktywności.

Dojrzałe, wysoce efektywne zespoły pracują razem bardziej niż równolegle. Nie oznacza to, że wszystko zawsze robione jest jedną wielką grupą, ale takie zespoły na pewno kładą większy nacisk na maksymalne wykorzystanie synergii między talentami poszczególnych członków, niż na podział pracy zgodny z ich specjalizacjami.

Cały zespół jest “właścicielem” całego rozwiązania (collective code ownership) – nikt nie powinien mieć wyłączności na wprowadzanie zmian w danym module, nie ma też miejsca na to, żeby członek zespołu całkowicie ignorował jeden z obszarów prac tylko dlatego, że “to nie moja działka“.

Dobrym zwyczajem wspierającym wspólną własność rozwiązania jest regularny przegląd tworzonego kodu (code review) przez innego członka zespołu. Odbywa się to nie w atmosferze kontroli pracy autora danego fragmentu, co raczej w intencji zapewnienia wysokiej jakości i czytelności kodu oraz rozpowszechniania wiedzy o systemie.

Jeszcze lepsze efekty niż code review może przynieść praca w parach (pair programming), która polega na tym, że dane zadanie wykonują dwie osoby pracujące jednocześnie przy jednym komputerze. Jest to dość trudna technika, lecz jeśli przyjmie się w zespole, pozwala znacznie zacieśnić współpracę, podnieść jakość produkowanego kodu, a także błyskawicznie rozpowszechnić w całym zespole najlepsze praktyki techniczne i wiedzę o tworzonym systemie. Naiwnie patrząc programowanie w parach podwaja pracochłonność bieżacych zadań, lecz ta inwestycja często zwraca się z nawiązką poprzez zmniejszenie liczby błędów do naprawienia później i ułatwienie naprawianie tych błędów, które mimo wszystko wystąpią.

Kolejną zaawansowaną techniką jest swarming, czyli równoczesna praca wielu członków zespołu nad jednym problemem. Swarming przydaje się przy usuwaniu wąskich gardeł w procesie. Przypuśćmy, że w zespole mamy dwóch testerów, którzy testują każdą nową funkcjonalność. Jeśli gotowe do testowania funkcjonalności nawarstwiają się i ta dwójka nie nadąża z ich przepychaniem można podjąć decyzję o chwilowym zatrzymaniu dalszego programowania i skupieniu się całego zespołu nad testowaniem oczekujących funkcji. Przy okazji warto popracować nad zautomatyzowaniem części testów lub innymi sposobami na ułatwienie dalszej pracy testerów. Po odblokowaniu zatoru zespół może spokojnie powrócić do dalszych prac bez obaw, że ich wysiłki są marnowane przez blokadę w innej części procesu wytwórczego.

Swarming może być też wykorzystany jako ćwiczenie pozwalające ulepszyć sposób współpracy zespołu. W takim przypadku możemy na jeden lub dwa sprinty założyć, że cały zespół pracuje nad jedną historyjką, aż zostanie ona w 100% zakończona i dopiero wtedy zabiera się za następną. Taka organizacja pracy rzadko jest dobrym pomysłem na stałe, ale stosowana chwilowo może pomóc przebić się przez bariery ograniczające efektywność zespołu.

Na jakość współpracy mogą mieć wpływ nawet pozornie drobne szczegóły organizacji pracy, takie jak np. moment przypisywania zadań do osób. Jak pisaliśmy wcześniej, lepiej gdy dzieje się to just-in-time, czyli wtedy gdy zespół jest gotowy rozpocząć pracę nad tym zadaniem, a nie np. przy planowaniu sprintu.

Oprócz tego ważne jest, żeby rozpisać pracę w sprincie na odpowiednio małe zadania. Zadania te nie powinny być prawie nigdy dłuższe niż jeden dzień. Dzięki temu na każdym standupie można od razu wykryć ew. problemy i opóźnienia. Zbyt długie zadania są wylęgarnią nieudanych sprintów. Jeśli zespół regularnie dzieli pracę na wielodniowe zadania to traci wgląd w postępy i ogranicza możliwość wzajemnej pomocy oraz stałego doskonalenia.

Jak wyglądają idealni członkowie interdyscyplinarnego zespołu?

Interdyscyplinarność nie oznacza pełnej wymienialności. Wręcz przeciwnie – właściwa różnorodność zespołu bardzo dobrze wpływa na jego skuteczność.  Z drugiej strony wąskie specjalizacje połączone z przyzwoleniem na zamykanie się specjalistów w swoim obszarze to prosta droga do niskiej efektywności.

Idealny członek zespołu Scrum ma profil kompetencji w kształcie litery T, czyli jest generalizującym specjalistą: jest bardzo dobry w swojej głównej dziedzinie, ale posiada też i stale doskonali umiejętności z kilku okolicznych obszarów. Programista świetnie koduje skomplikowane algorytmy, ale umie też odnaleźć się w bazie danych, przeprowadzić testy różnych typów a nawet, o zgrozo, napisać kawałek dokumentacji.

W ten sposób kompetencje całego zespołu powinny układać się podobnie jak puzle pokrywające cały zakres niezbędnych umiejętności – z główną cześcią własnego obrazka, ale też wypustkami pozwalającymi zaangażować się w inne rodzaje pracy.

Pytania do Was:

  1. Jak moglibyście wzmocnić współpracę Waszego zespołu?

Ćwiczenie dla Was:

  1. Stwórzcie w swoim zespole macierz kompetencji, która pozwoli Wam lepiej zrozumieć Wasze indywidualne i grupowe możliwości.
  2. Narysujcie wspólnie koło pomocy, które pomoże Wam wspierać się nawzajem. Opis ćwiczenia znajdziecie w skądinąd świetnej (wolnodostępnej) książce Doktryna Jakości Andrzeja Blikle, na stronie 230.

Jako Fluid Circle na codzień pomagamy zespołom zwiększać swoją efektywność i jednocześnie czerpać więcej satysfakcji z pracy. Jeśli chciałbyś, żebyśmy pomogli także Twojemu zespołowi zastosować opisane w tym cyklu zasady to chętnie z Tobą porozmawiamy!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Information

This entry was posted on 2013-01-31 by in Artykuły and tagged .