Synergia to inaczej współdziałanie. Synergicznie działamy nie tylko w grupach społecznych, biznesie, ekonomii czy innych dziedzinach życia. Pojęcie synergii jest coraz chętniej stosowane także w branży IT, a szczególnie w zwinnym modelu współpracy. Jak tworzy się synergia w zespołach i jakie są zagrożenia dla niej? Jak synergiczne i efektywnie pracować w Zespole Developerskim? Na te i inne pytania postaram się odpowiedzieć w dzisiejszym artykule.

Siła synergii

Wyobraźmy sobie, że mamy do zrealizowania pilny projekt budowy aplikacji. Klient w komunikacji coraz częściej używa terminów „deadline” i „ASAP”. W jaki sposób przyspieszyć realizację projektu? Wydaje się, że odpowiedź jest oczywista: „Zatrudnić więcej programistów”. W synergicznym działaniu jednak nie liczba osób jest ważna, lecz sposób, w jaki współpracują. Dzięki współdziałaniu wkład poszczególnych członków zespołu, w tym wypadku developerów, jest wzmacniany przez jednoczesne uczestnictwo innych. Na tym polega magia synergii.

W tym artykule chciałbym skupić się na zjawisku synergii w Scrumie, a konkretnie w Zespole Developerskim. Przedstawię zachowania i praktyki, które pozytywnie wpływają na współpracę pomiędzy developerami.

Synergia a Scrum Guide

Scrum Guide tylko raz używa słowa synergia, opisując działanie frameworka Scrum:

„Zespoły Developerskie są ustanowione i uprawnione przez organizację do samodzielnego organizowania własnej pracy i zarządzania nią. Synergia będąca rezultatem takiego postępowania zwiększa ogólną wydajność i efektywność Zespołu Developerskiego.” Pracując jako Scrum Master, jestem jednak głęboko przekonany, iż to właśnie synergia określana jako „współdziałanie różnych czynników, skuteczniejsze niż suma ich oddzielnych działań” jest kluczem do sukcesu podczas prac nad wytwarzaniem oprogramowania. Bo przecież aby powstała dobrze działająca aplikacja, potrzeba współpracy nie tylko pomiędzy członkami Zespołu Developerskiego. Ważne jest także współdziałanie tego zespołu z pozostałymi członkami Zespołu Scrumowego, przedstawicielami biznesu czy klientami.

Cechy Zespołu Developerskiego

Scrum Guide wyróżnia następujące cechy, którymi powinien charakteryzować się Zespół Developerski:

  • Jest samoorganizujący się. Oznacza to, że nikt nie wskazuje Zespołowi Developerskiemu, w jaki sposób ma przekształcić elementy Backlogu w Przyrost (ang. Increment). Od tej zasady nie ma wyjątków. Wszelkie próby organizacji pracy przez Scrum Masterów, Project Managerów czy kogokolwiek innego będą powodowały pojawianie się nieprawidłowości w funkcjonowaniu Zespołu Developerskiego.
  • Jest międzyfunkcjonalny. Zespół Developerski posiada wśród członków wszelkie umiejętności i wiedzę, dzięki którym jest w stanie samodzielnie, bez pomocy innych osób, wytworzyć Przyrost, czyli de facto wykonać zaplanowaną pracę.
  • Nie wyróżnia nazw ról. Z tego względu, że zespół posiada wszystkie kompetencje niezbędne do dostarczenia zadeklarowanego Przyrostu, Scrum nie określa konkretnych ról dla osób tworzących zespół. Każdy członek Zespołu Developerskiego jest Developerem – nawet jeśli oficjalnie jego rolą jest testowanie, projektowanie, UX etc. W Zespole Developerskim każdy członek jest tak samo ważny i tak samo przyczynia się do dostarczenia wysokiej jakości produktu.
  • Nie wyróżnia podzespołów. Zespół Developerski funkcjonuje jako całość, a jego członkowie wspólnie planują i weryfikują swoją pracę. Tworzenie oddzielnych zespołów, np. do testowania, implementacji czy projektowania, nie sprzyja pracy zespołowej i może powodować powstawanie tzw. silosów, czyli osobnych grup lub działów, które zamykają się na inne zespoły i wspólną pracę.
  • Odpowiedzialność za wykonaną pracę spoczywa na całym Zespole Developerskim, nawet jeśli poszczególne osoby były odpowiedzialne za wykonanie konkretnych zadań. W żadnym wypadku Zespół Developerski jako całość nie może uchylić się od odpowiedzialności za pracę, jaką wykonał.

Wielkość Zespołu Developerskiego

Według Scrum Guide’a Zespół Developerski nie powinien być mniejszy niż 3 osoby i większy niż 9 osób. Jak czytamy: „Zespół Developerski powinien być na tyle mały, by pozostał zwinnym, i jednocześnie wystarczająco liczny, żeby mógł wykonać znaczącą pracę w ramach Sprintu”. Wytłumaczenie takich proporcji jest bardzo proste. Zespół składający się z mniej niż 3 osób będzie napotykać problemy braku wystarczających kompetencji i umiejętności, aby ukończyć zaplanowaną pracę. Z kolei w zespołach powyżej 9 osób nakłady związane z koordynacją pracy mogą okazać się zbyt duże. Ten, kto kiedykolwiek organizował spotkanie dla grupy większej niż 10 osób (na którym każda osoba mogła się wypowiedzieć), doskonale zrozumie, co mam na myśli.

Jaka zatem jest optymalna wielkość Zespołu Developerskiego? Ciekawym i jednocześnie humorystycznym sposobem na określanie liczebności zespołów jest „Two pizza rule”. Zgodnie z nią w zespole może być tyle osób, ile jesteśmy w stanie… wykarmić dwiema pizzami. Jeśli jednak odłożymy żarty na bok, okazuje się, że zasada dwóch pizz doskonale sprawdza się także podczas tworzenia Zespołów Developerskich. Biorąc pod uwagę równowagę między kompetencjami a koordynacją – nie mogą być ani za duże, ani za małe. Spójrzmy, w jaki sposób synergiczne działanie jest odzwierciedlone w codziennej organizacji pracy Zespołów Scrumowych.

Synergia zespołu podczas codziennej pracy

Reguły gry  Scruma (za „Przewodnikiem po Scrumie”: The Rules of the Game) zostały ustanowione w taki sposób, aby Zespół Developerski podczas codziennej pracy maksymalizował swój potencjał i wykorzystywał potencjał synergii. Daily Scrum jest to codzienne spotkanie, na którym zespół planuje pracę na kolejne 24 h oraz dokonuje inspekcji pracy, która została już wykonana. Taka codzienna ocena skończonej pracy, rozmowa o napotkanych przeszkodach i otwartość w kontekście potencjalnych problemów sprawia, że zespół tworzy jeden organizm dzięki synergii, która go scala.

Nie inaczej jest podczas Przeglądu Sprintu oraz Retrospektywy Sprintu, które służą inspekcji Przyrostu (czyli sprawdzeniu, czy prognozowana wartość została dostarczona) oraz działań Zespołu Scrumowego. Dzięki informacjom zwrotnym przekazywanym przez Product Ownera, interesariuszy czy samych developerów Zespół Developerski może dokonać usprawnień, zmodyfikować swoją rutynową pracę lub znacząco zreorganizować proces wytwórczy oprogramowania. Wszystkie te czynności, a także spotkania mają de facto wspólny mianownik – jest nim pobudzenie lub usprawnienie synergii pracy i współpracy.

Tworzenie się synergii w Zespole Developerskim

Pamiętajmy, że stworzenie zgranego zespołu, który zna swoje mocne i słabe strony, jest otwarty na współpracę, pewny swoich możliwości i przede wszystkim samowystarczalny i samoorganizujący się – wymaga poświęcenia czasu i ogromnej pracy. Wiele mówi się o tym, że to Scrum Master jest odpowiedzialny za tworzenie dobrych zespołów. To prawda, jednym z moich obowiązków jest ustawiczne wspieranie i coaching developerów. Pamiętajmy jednakże, że zaangażowanie Zespołu Developerskiego, Product Ownera, a także otoczenia biznesowego czy innych członków organizacji jest konieczne, aby praca Scrum Mastera nie poszła na marne i przyniosła owocne efekty. Innymi słowy, ważne, aby zarówno członkowie Zespołu Scrumowego, jak i osoby spoza niego czuły odpowiedzialność za budowanie atmosfery zaufania, zaangażowania i współpracy.

Zagrożenia dla synergii w Zespole Developerskim

Moją rolą jako Scrum Mastera jest przyglądanie się pracy zespołów i wychwytywanie wszelkich nieprawidłowości. Pierwszym poważnym błędem zagrażającym synergii jest stosowanie tzw. micromanagementu, czyli ingerowanie w samoorganizację zespołu. Klient lub Product Owner sugeruje, jakie zadanie powinno być wykonane priorytetowo poza Sprintem? Konkretne zadania są przydzielane określonym osobom? Product Owner dopomina się paczki funkcjonalności przed końcem Sprintu? To poważne błędy, które mogą też świadczyć o braku zaufania w zespole.

Innym błędem są podziały – grupy i podgrupy nie sprzyjają przejrzystości. Jeżeli członkowie zespołu sami zgłoszą się do Scrum Mastera czy Agile Coacha z takim problemem, to już połowa sukcesu. Jeśli jednak brakuje świadomości na temat rodzących się podziałów, czujne oko Scrum Mastera powinno wychwycić nieprawidłowości. Taką jest również celowe dzielenie zespołów, np. na podzespoły zajmujące się wyłącznie testowaniem. Nawet jeśli będą one uczestniczyć w jednym Przeglądzie Sprintu i Retrospektywie Sprintu, w moim odczuciu nie stanowią już jednego Zespołu Developerskiego.

Czytaj także: Konflikt w zespole

Podsumowanie

Współdziałanie w Zespole Developerskim, oparte na komunikacji, zaufaniu i braku podziałów, przyniesie najlepsze efekty i pozwoli wykorzystać pełen potencjał technik zwinnych. Rolą Scrum Mastera jest upewnić się, że Zespół Developerski działa synergicznie i nie ma zagrożeń dla współdziałania, takich jak micromanagement czy rodzące się podziały. Ważne też, aby wszystkie osoby pracujące w modelu zwinnym pamiętały o wartościach, jakimi są zaangażowanie, skupienie, otwartość, szacunek i odwaga. Tworzą one najlepsze podłoże do budowania działających synergicznie zespołów.

 

Autorem wpisu jest:
Łukasz Tudzierz

Scrum Master w JCommerce, realizuje projekt dla brytyjskiego klienta. Wierzy w empiryzm i iterację. Uczy Zespoły Scrumowe samodzielności i odpowiedzialności. Po godzinach taternik i wspinacz, autor portalu Tuudi.net.

Dodaj komentarz

Komentarze:

Skontaktuj się z nami

Chcesz dowiedzieć się więcej o naszych usługach? Napisz do nas – odpowiemy na każdą wiadomość.

Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma, w celach handlowych.
Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma, w celach marketingowych.
Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma w celach rekrutacyjnych.
Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma na potrzeby przyszłych rekrutacji.
W związku z obowiązującymi przepisami dotyczącymi ochrony danych osobowych tj. Ustawą o ochronie danych osobowych z dnia 10 maja 2018 roku, jak również treścią Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (RODO), informujemy, że: 1. Administratorem danych osobowych jest JCommerce Sp. z o.o. z siedzibą w Katowicach, ul. Ściegiennego 3, 40-114 Katowice (KRS: 00007393418).
2. Powyższe dane osobowe przetwarzane będą przez JCommerce Sp. z o.o. – w zależności od udzielonych przez Panią/Pana zgód (podstawa prawna przetwarzania: art. 6 ust. 1 pkt a) RODO):
• w celach handlowych,
• w celach marketingowych,
• w celach rekrutacyjnych;
• w celach przyszłych rekrutacji.
3. Podanie powyższych danych osobowych nie jest wymogiem ustawowym, umownym lub warunkiem zawarcia umowy. Nie jest Pan/Pani zobowiązany/a do podania powyższych danych osobowych, jednak brak ich podania uniemożliwi realizacje ww. celu.
4. Posiada Pan/ Pani prawo dostępu do treści swoich danych, w tym otrzymania ich kopii i ich sprostowania, usunięcia, ograniczenia przetwarzania, prawo do przenoszenia danych, prawo do sprzeciwu wobec przetwarzania, prawo do cofnięcia zgody w dowolnym momencie, jeśli została udzielona. Wycofanie zgody nie wpływa jednak na zgodność z prawem przetwarzania, którego dokonano na podstawie zgody przed jej wycofaniem; oświadczenie o cofnięciu zgody na przetwarzanie danych osobowych należy złożyć w siedzibie JCommerce Sp. z o.o. lub przesłać na adres mailowy zgody@jcommerce.pl. Cofnięcie zgody na przetwarzanie danych osobowych skutkuje brakiem możliwości realizacji ww. celów przetwarzania;
5. Dane osobowe są udostępniane przez JCommerce Sp. z o.o. upoważnionym pracownikom i osobom współpracującym z JCommerce Sp. z o.o. na podstawie umów cywilnoprawnych, przez których realizowany jest cel przetwarzania;
6. Wszelkie pytania dotyczące ochrony danych osobowych oraz realizacje przysługujących praw, prosimy kierować na adres odo@jcommerce.pl;
7. W zależności od udzielonej zgody, dane osobowe będą przetwarzane przez czas niezbędny do realizacji ww. celów przetwarzania. W przypadku wniesienia sprzeciwu, JCommerce Sp. z o.o. przestanie przetwarzać Pani/Pana dane w ww. celu, chyba że będzie w stanie wykazać, że w stosunku do tych danych istnieją ważne prawnie uzasadnione podstawy, które są nadrzędne wobec Pana/Pani interesów, praw i wolności, lub niezbędne do ewentualnego ustalenia, dochodzenia lub obrony roszczeń;
8. Nie przekazujemy Pani/Pana danych poza teren Europejskiego Obszaru Gospodarczego oraz do organizacji międzynarodowych.
9. Pani/Pana dane osobowe nie podlegają zautomatyzowanemu podejmowaniu decyzji, w tym profilowaniu.
10. Ma Pani/Pan prawo wniesienia skargi do organu nadzorczego gdy uzna Pan/Pani, iż przetwarzanie ww. danych osobowych narusza przepisy ogólnego rozporządzenia o ochronie danych osobowych z dnia 27 kwietnia 2016 r.