Inspiracją do tej części skrzynki z narzędziami Project Managera była jedna z zasad Scaled Agile Framework (SAFe). Fundamentem każdej agile’owej ramy postępowania są wartości i zasady i to na nich budujemy zwinne zarządzanie produktem czy projektami. W tym numerze chciałabym skupić się na zagadnieniu związanym z podejmowaniem decyzji przez zespół i objaśnieniu, jak można tego nauczyć innych i jakie wypływają korzyści z decentralizacji tego procesu.
Jako SPC (certyfikowany konsultant SAFe) prowadzę szkolenia i wdrażam to podejście w swojej codziennej pracy. W trakcie warsztatów dla zespołów, liderów z zakresu SAFe duży nacisk kładzie się na zasady, wartości i pryncypia, które są podstawą dla zwinnego zarządzania. Najbardziej rozpowszechnionym i znanym dokumentem, który był pierwowzorem dla pozostałych sposobów pracy zwinnej i skupiał się na zasadach jest Agile Manifesto. W jedenastym punkcie tego manifestu czytamy, że: „najlepsza architektura, wymagania, projekty powstają przez samoorganizujące się zespoły”. To tu możemy między słowami zauważyć że stawiamy na zespół i podejmowane przez niego decyzje, które wpływają na zakres i jego realizację. Praktycy, którzy tworzyli SAFe i jego najlepsze praktyki zainspirowani również Agile Manifesto zapisali pośród 10 zasad jedną, która mówi: „decentralizuj proces podejmowania decyzji” (ang. Decentralize decision-making). To konkretna zasada, która w zasadzie jest łatwo zrozumiała, jednak jeśli zagłębimy się w nią bardziej od strony praktycznej, coraz częściej zauważam, jak trudno ją prawidłowo wdrożyć.
Rys. 1. 10 zasad SAFe.
Źródło: https://www.scaledagileframework.com/safe-lean-agile-principles/
Powyższe zasady mają wyznaczać nam kierunek naszej pracy, pokazują, na co należy zwrócić uwagę, po to, aby móc osiągać zamierzone cele i wyniki w naszej pracy. Każda z nich jest równie ważna i powinna być dla nas podstawą do rozmowy o konkretnych praktykach, jakie będą funkcjonowały w pracy naszego zespołu.
Bilans zysków i strat
Zanim przejdziemy do konkretnych praktyk i tego, jak zająć się prawidłowym decentralizowaniem podejmowania decyzji, musimy zdać sobie sprawę z ogromnych korzyści, jakie ono za sobą niesie.
Po pierwsze, pozwolenie na podejmowanie decyzji przez zespół wzmacnia jego samoorganizację. Zespół, który częściej samodzielnie podejmuje decyzje, naturalnie bierze na siebie większą odpowiedzialność, szybciej będzie pokonywał przeszkody, lepiej ze sobą współpracował, a tym samym szybciej dostarczał kolejne, gotowe elementy.
Po drugie, decentralizacja, zwłaszcza decyzji, które są częste i wymagają specyficznej wiedzy, którą posiadają osoby w zespole, będzie szybka i niejednokrotnie najlepsza. Decyzje podejmowane powinny być przez osoby mające odpowiednią wiedzę. Jeśli to one będą miały mandat do ich podejmowania, z dużym prawdopodobieństwem unikniemy wielu pomyłek i błędów związanych z jakością tworzonego rozwiązania. Im dłuższa kolejka osób zatwierdzających decyzje, tym dłuższy czas jej podjęcia, a tym samym samej realizacji, a dodatkowo wszelkie zmiany pomiędzy kolejnymi szczeblami mogą prowadzić do dodatkowych kosztów, a czasem i do niewłaściwych ustaleń podejmowanych przez osoby niezwiązane blisko z pracą zespołu.
Po trzecie, to oszczędność czasu poprzez szybkie reagowanie i działanie. Eliminacja dodatkowych osób lub poziomów w naszej strukturze projektu do podejmowania decyzji i pozwolenie na podejmowanie ich zespołowi zapewni nam ciągłość realizacji powierzonych zadań, brak przestojów i efektywne zarządzanie czasem projektu. Ponadto, zmniejszamy potencjalną frustrację, jaka może pojawić się, kiedy zespół musi czekać na ustalenia podjęte poza nim.
Na koniec, chciałabym również podkreślić jeszcze jedną równie istotną korzyść. Mianowicie, dzięki takiemu podejściu do podejmowania decyzji, mamy do czynienia z uczeniem się przez praktykę. Nawet jeśli podjęta przez zespół decyzja będzie nieodpowiednia, nauczy się on więcej, wyciągnie wnioski i następnym razem podejmując decyzje weźmie je pod uwagę. Jeśli decyzja będzie miała poważne konsekwencje, możemy być prawie pewni, że nigdy więcej podobny błąd nie zostanie popełniony.
Złoty środek
Podstawowym pytaniem, jakie będzie nam zadawał zespół, zwłaszcza na początku, będzie pytanie: czy decentralizujemy wszystko? Odpowiedź powinna brzmieć: niestety, ale nie. Nadal będą pojawiać się decyzje, których nasz zespół w projekcie nie powinien podejmować. I musimy transparentnie i dokładnie ustalić, kto i jakie decyzje może podejmować. Niestety z tym zazwyczaj mamy największe kłopoty, bo ciężko podać jednoznaczną odpowiedź i zanim nauczymy zespół tego, jakie decyzje może podejmować, możemy mimo wszystko borykać się z problemem, że albo nie robi tego w ogóle i czeka przynajmniej na odpowiedź ze strony kierownika projektu lub innych decydentów, którzy stoją ponad zespołem. Może zdarzyć się również, że zespół podejmuje większość decyzji samodzielnie, a nie zawsze powinien.
W tym drugim przypadku, uważam, że możemy sobie łatwiej poradzić wprowadzając chociażby regułę, aby zespół informował o swoich decyzjach Project Managera1 , lub inną osobę, która zarządza realizacją projektu/produktu. Regularne przeglądy i informacja zwrotna, które z faktycznie skonsultowane lub podjęte poza zespołem, da mu pełniejsze zrozumienie i z czasem nauczy, jak postępować w konkretnych sytuacjach.
O wiele trudniejsza jest sytuacja, zwłaszcza, jeśli jesteśmy kierownikiem projektu, gdy zespół nie chce podejmować niemalże żadnych decyzji. Przyczyn może być wiele, najczęściej zauważam jednak, że istnieje obawa przed konsekwencjami, jeśli decyzja będzie zła. Czasem mogą być to aspekty kulturowe (w niektórych kulturach uważa się, że decyzje powinny podejmować osoby na wyższych stanowiskach), często również przyzwyczajenie z poprzedniej pracy czy projektu. Aby na tym polu odnieść sukces i nauczyć zespół, aby nie bał się podejmować decyzje i brał za nie odpowiedzialność musimy ustalić pewne zasady po to, by łatwiej się nam współpracowało.
SAFe opisując dziewiątą zasadę, która mówi właśnie o tym, aby decentralizować podejmowanie decyzji, daje nam także pewne wytyczne odnośnie rodzajów decyzji, które mogą nam bardzo pomóc w rozmowie z zespołem i wyznaczaniem zasad. Poniżej prezentuję tabelę (Tabela 1.) z krótkim opisem, jakie zasady należy centralizować, a jakie „oddajemy” w ręce zespołu.
Tabela 1. może być dobrym punktem wyjściowym do decydowania o tym, co spoczywa na zespole. Dodatkowo możemy posiłkować się pewną kalkulacją rekomendowana przez Scaled Agile. Chodzi o to, aby za pomocą prostej formuły policzyć i zdecydować czy dane zagadnienie ma być omówione i podjęte centralnie czy nie. W formie tabeli wpisujemy różne decyzje, które będziemy podejmować w projekcie. Potem oceniamy:
- Czy jest to decyzja podejmowana często? Dla odpowiedzi TAK, dajemy 2 pkt, NIE – 0 pkt.
- Czy jest to decyzja krytyczna czasowo? Dla odpowiedzi TAK – 2 pkt, NIE – 0 pkt.
- Czy jest to decyzja krytyczna ekonomicznie (duża skala ekonomiczna)? Dla odpowiedzi TAK – 0 pkt.
Następnie sumujemy wszystkie punkty, jeśli wynik jest między 0 a 2 – decyzja powinna być scentralizowana, jeśli 4-6 pkt – decyzje decentralizujemy. To ćwiczenie nie zawsze będzie idealne, jednak może nam bardzo pomóc. Zwłaszcza, jeśli wcześniej przygotujemy listę konkretnych, realnych przykładów projektowych i pokażemy zespołowi, czego od niego oczekujemy. Istotnym aspektem jest również pokazanie członkom zespołu, że niezależnie od podejmowanych decyzji mogą liczyć na nasze wsparcie. Nie chcemy, aby w przypadku błędu bali się podejmowania kolejnych decyzji. Nasz styl zarządzania musi być autentyczny i musimy pamiętać o tym, żeby samemu trzymać się ustalonych reguł. Niezależnie od pełnionej roli powinniśmy być liderami, którzy stoją po stronie zespołu i wspierają go, nawet, jeśli zdarzy im się podjąć złą decyzję. Tylko wtedy będziemy w stanie doprowadzić do wyeliminowania ryzyka związanego z krótkotrwałą realizacją tej zasady.
A może poker?
Delegation poker to narzędzie z podejścia Management 3.0. Prosta gra z zestawem kart, które mogą posłużyć nam do ustalenia, o czym możemy samodzielnie decydować, na co mamy wpływ i jak duży. Mamy tu 7 kart, które reprezentują różne poziomy decydowania o wykonywanych zadaniach czy odpowiedzialności poszczególnych osób. Jest to ćwiczenie dla całego zespołu projektowego. Z jednej strony wpisujemy różne zadania, decyzje projektowe, a potem dyskutujemy, kto i za co jest odpowiedzialny, w jakim stopniu, zawsze w odniesieniu do pełnionej roli. Na kartach mamy hasła: Powiedz, Sprzedaj, Skonsultuj, Uzgodnij, Doradź, Dowiedz się, Zdeleguj. Za ich pomocą omawiamy z zespołem, kto i w jakim zakresie będzie miał kompetencje do podejmowania decyzji, a tym samym wprowadzimy od samego początku łatwiej zrozumiałe zasady i ramy do dalszej pracy. Zagrać możemy wielokrotnie, w zależności od potrzeby. Wyniki gry powinny zostać zapisane i być udostępnione w repozytorium zespołu, tam gdzie mamy inne nasze ustalenia co do współpracy. Jeśli brakuje nam na liście ważnych punktów, możemy w każdej chwili wrócić do listy i zapisywać nowe, kolejne aspekty wiążące się z podejmowanymi przez nas decyzjami.
Dbajmy o transparentność
Jeśli chcemy zapewnić dobrą komunikację pomiędzy zespołami a różnymi szczeblami zarządzającymi w zakresie decyzji, a dodatkowo oczekujemy, że nasze zespoły będą nas informować o swoich decyzjach, powinniśmy zawsze zacząć od siebie samych. Decyzje, które centralizujemy, i które podejmowane są przez management wyższego szczebla (na przykład poziom programu, portfela) muszą być również widoczne dla zespołu. Czasem po to, by po prostu poinformować o nich. Jednak chcemy zapewnić widoczność z uwagi na to, że zespół może posiadać dodatkowe informacje, które mogą być istotne dla podejmowanej decyzji i będzie chciał się nimi podzielić, co może wpłynąć korzystniej na ostateczny jej kształt. Zdarzyć się może także, że podjęta centralnie decyzja będzie wpływać na inne, którymi zajmuje się zespół. W swojej codziennej pracy staram się zapewnić widoczność i komunikować zespołom na bieżąco podejmowane decyzje. Jednak im więcej osób w projekcie, tym często trudniej nam pamiętać o wszystkich, których należy powiadomić albo o przygotowywaniu materiału, na bazie którego podejmiemy decyzje, albo o finalnym efekcie. Aby zmitygować takie ryzyka polecam proste repozytorium z listą decyzji, krótką informacją, czego dotyczy, rozważane scenariusze i opcje, kluczowe osoby oraz status.
Każda z nich pozwala na różne podejście do tematu, wszystko zależy od kontekstu, etapu w jakim jesteśmy z naszym zespołem i od tego, co chcemy osiągnąć. Każdy z elementów możemy podzielić na 4 etapy: zastanowienie się nad zagadnieniem, spisanie przemyśleń, głosowanie i dyskusję. Aplikacja posiada również wbudowany zegar, który możemy sami ustawić tak, by odmierzał nam czas, jaki pozostał do zakończenia danej części. Jeśli zespół ma taką potrzebę, możemy oczywiście kontynuować po upływie czasu, jeśli jesteśmy gotowi możemy przejść do kolejnego etapu. Głosowanie jest ultra proste: najpierw decydujemy, ile głosów ma każdy członek zespołu (w standardzie ustawione jest pięć), następnie oddajemy głosy, a potem możemy przejść do kolejnej części, czyli dyskusji. Ograniczenie czasowe, tzw. time-box jest ważnym czynnikiem i warto z tej opcji korzystać w trakcie każdego etapu, to pozwala nam kontrolować czas i istnieje dużo większe prawdopodobieństwo, że spotkanie osiągnie swój zamierzony cel, jakim powinna być lista usprawnień lub zagadnień do poprawy.
Prosty i przejrzysty interfejs, kilka bardzo przydatnych funkcjonalności to duże zalety tej aplikacji. Niestety, aby w pełni i regularnie z niej korzystać z naszym zespołem, mając również pewność co do bezpieczeństwa informacji, jakimi się dzielimy, trzeba wykupić płatny dostęp. Koszt to 49 USD za każdy miesiąc aktywnego użytkowania aplikacji per tzw. „pokój”. Pokój tworzymy pod nasz zespół lub projekt i tam zbieramy podsumowania. Oznacza to, że jeśli mamy więcej niż jeden zespół, potrzebujemy zwiększyć naszą subskrypcję. Jednak jeśli z jakiegoś powodu aplikacji nie używamy w danym miesiącu, jego właściciele nic nam nie naliczą.
Rys. 3. Przykładowa tablica dla decyzji, które muszą zostać podjęte poza zespołem projektowym, lub skonsultowane z innymi kluczowymi
interesariuszami.
Źródło: Opracowanie własne.
Zmień kurs
Umożliwiajmy zespołom podejmowanie własnych decyzji, ponieważ to one mają najlepszą wiedzę, często są najbliżej wykonywanych zadań i mogą szybko reagować. Jeśli nie zaufamy ludziom, wówczas nie zaufamy i ich decyzjom, a takim podejściem utrudniamy sobie realizację i wydajne postępy w pracy. Warto pracować nad zespołem, jeśli ma opór przed podejmowaniem decyzji, bo to docelowo przyspieszy pracę, wyeliminuje częściowo tzw. „wąskie gardła” wśród osób, na których „wiszą” decyzje do podjęcia. Chcemy zachęcać ludzi do współpracy i działania, wspierać ich w tym procesie po to, by osiągnąć zamierzony cel z sukcesem, a bez zaangażowanego zespołu to się nie uda. A jeśli nadal nie jesteście przekonani do decentralizacji podejmowania decyzji przez zespół zachęcam do zapoznania się z prawdziwą historią amerykańskiego kapitana Davida Marqueta, który swoje doświadczenia w zarządzaniu opisał w książce Zmień kurs (ang. Turn the ship around). Z niej dowiecie się więcej o korzyściach z tego płynących, pracy jaką trzeba wykonać by dojść do momentu, w którym zespół nie boi się podejmowania decyzji i brania za nie odpowiedzialności i dlaczego dzięki takiemu podejściu osiągniecie dużo więcej.
1 W SAFe nie ma roli Project Managera. Stosując SAFe o decyzjach poinformowani mogą być Scrum Master, Product Management i/lub Release Train Engineer.
[ENG] Leader, Agile ways of working enthusiast. Has over 10 years experience with multicultural teams. Support teams achieving their goals, delivering projects and solutions that are focused on meeting clients needs. People doing the work are priority number one for her and she does her best motivating and empowering them. PMP® & SAFe SPC® certified, trainer and designer of interactive workshop. In her free time, passionate of active forms of leisure, crime stories, baking and cooking.
[PL] Liderka, pasjonatka zwinnej pracy projektowej. Posiada ponad 10-letnie doświadczenie w pracy w zespołach wielokulturowych. Wspiera zespoły w osiąganiu celi i dostarczaniu projektów lub rozwiązań, które spełniają oczekiwania klienta. Wierzy, że w pracy na pierwszym miejscu są ludzie i to ich wspiera w dotarciu do celu. Projektuje gry i interaktywne warsztaty szkoleniowe. Akredytowany trener PMP® oraz SAFe SPC®. W wolnym czasie fanka aktywnego wypoczynku, kryminałów, pieczenia i gotowania.