Autonomia zespołów agile’owych w organizacjach.
Mam przyjemność ugościć miejsca na moim blogu na artykuł praktyka SAFe – Tomasza Czechowskiego, fana skalowania i budowania zwinności w organizacjach, który na co dzień pełni rolę dumnego ojca i skromnego Release Train Engineer’a (skromność jest chyba naturalną cechą w tym zawodzie). Tomek dzieli się swoimi spostrzeżeniami odnośnie autonomii zespołów zwinnych. Krótko i konkretnie, bez zadęcia i tonu wykładowcy, za to szczerze, od siebie i prosto z agile’owego pola walki.
Zapraszam do lektury.
„Autonomia zespołów agile’owych w organizacjach”, Tomasz Czechowski
Głównym czynnikiem, który decyduje o osiągnięciu mistrzostwa w jakiejś dziedzinie nie są wrodzone zdolności, ale zaangażowanie w rozwój. Najlepiej celowe. Tak twierdzi Robert Sternberg, wybitny psycholog, autor trójczynnikowej koncepcji inteligencji. Według niego nie zawsze Ci, którzy na początku byli najinteligentniejsi, okazują się najinteligentniejsi na końcu. Celowe zaangażowanie w rozwój jest wspierane przez nastawienie rozwojowe, według którego sprawność intelektualną osoby lub zespołu można rozwijać przez pracę i zastosowanie właściwej strategii.
Zespoły software’owe w organizacji mogą mieć różne poziomy autonomii, tworząc jeden większy produkt. Ta autonomia jest rozumiana jako zdolność do samoorganizacji i podejmowania najlepszych decyzji w drodze do osiągnięcia celu (inkrementu działającego oprogramowania, implementacji nowej funkcjonalności, czy naprawy wąskich gardeł w rozwoju produktu). Autonomią może też być zdolność do wpływania lub budowania roadmapy i definiowania feature’ów. Z drugiej strony, przykładem niskiej autonomii jest rodzaj pracy zespołu, który jest kontrolowany przez bardziej doświadczony management lub reprezentantów właściciela firmy (osoby posiadające budżet projektowy), a decyzje projektowe są narzucane z góry poprzez przełożonych bez wcześniejszej konsultacji. Obydwa podejścia mogą mieć mniejsze lub większe nasilenie i występować w różnych cyklach życia projektów i dojrzałości zespołów.
Scaled Agile Framework (SAFe) podkreśla ważność autonomii jednostek i zespołów jako jedno z podstawowych narzędzi do wspierania i motywowania pracowników organizacji opartej na wiedzy. Mówi o tym zasada nr 8 Unlock the intrinsic motivation of knowledge workers, czyli wyzwól wewnętrzną motywację wykwalifikowanych pracowników. SAFe, cytując książkę Daniela Pinka „Drive”, mówi, że pracownicy, w szczególności w organizacjach opartych o wiedzę, mają potrzebę autonomii do wyznaczania własnego kierunku i samoorganizacji. Dawanie ludziom coraz większej autonomii do działań, które powinny współgrać z wysokopoziomowym celem organizacji, oraz wyznaczanie wymagań projektowych z minimalną listą ograniczeń jest ważną odpowiedzialnością liderów organizacji.
Nie jest jednak prawdą, że zespoły w imię autonomii same wyznaczają kierunek swojej pracy, podpierając się priorytetami wyznaczonymi przez Product Ownera. Takie autonomiczne zespoły realizują funkcjonalności zgodne z Roadmapą produktu, którą z dużą starannością przygotowuje zespół produktowy (Product Management i Product Ownerzy). Za ostateczną priorytetyzację funkcjonalności w skalowalnej zwinnej organizacji powinna odpowiadać jedna osoba — Product Manager lub Product Owner. Zespoły planują swoje zadania i historyjki, natomiast Product Manager lub Product Owner specyfikuje Epiki i Ficzery. Pokazuje to poniższy wykres.
Źródło: https://docs.microsoft.com/en-us/azure/devops/learn/agile/scale-agile-large-teams
Wyznaczenie i respektowanie linii autonomii wzmacnia dojrzewanie zespołów, ich motywację oraz zacieśnia współpracę z zespołem Product Management. Jednak zmiana w drugą stronę, czyli niepewna lub zmienna linia autonomii może spowodować niższe morale i obniżoną satysfakcję zespołów oraz może prowadzić do utraty bardziej doświadczonych inżynierów.
Kontrowersyjny jest również temat planowania roadmapy — jeśli zespoły planują pracę w sprintach podczas PI Planningu (na 5 – 6 sprintów), to jak może wyglądać ustalenie roadmapy w czasie? Niestety SAFe niewiele mówi na ten temat, gdyż budowanie nowych hipotez biznesowych odbywa się na bieżąco, sprint po sprincie, natomiast ich weryfikacja jest podczas demo oraz release’ach dla klientów. Jednak co w sytuacji zamawiania kilku większych funkcjonalności — ich dokładne oszacowanie w czasie nie jest możliwe lub jest bardzo kosztowne, więc praktyka z dużych i średnich organizacji pokazuje, że dostarczanie takich funkcjonalności można określać w sposób bardzo przybliżony, np. w kwartałach, czy półroczach. Pokazuje to poniższy wykres- odpowiedzialność za zakres i zgrubny czas realizacji.
Źródło: https://docs.microsoft.com/en-us/azure/devops/learn/agile/scale-agile-large-teams
Powyższa wizualizacja planowania ma swoje odzwierciedlenie w SAFe — zespoły co sprint (2 – 3 tygodnie) robią backlog refinement, zespoły w porozumieniu z managementem robią planowanie inkrementu (2 – 3 miesiące), Product Management buduje krótko i długoterminowe plany produktu (0.5 – 1.5 roku).
Elementem spajającym taką współpracę jest zaufanie pomiędzy zespołami, a managementem. Management wyznacza plany dla zespołów i ufa, że zespoły będą je realizować, a zespoły implementują plany zgodnie z wyznaczonymi priorytetami. Bez zaufania nie będzie funkcjonować wyznaczona granica autonomii, która służy do wzrostu organizacji, zespołów i jednostek.
Co na to Scrum… (Tomek Włodarek z #AgileRebels) tylko zespół określa, ile jest w stanie dostarczyć pracy. Nikt, oprócz zespołu, nie powinien określać, ile funkcjonalności zespół jest w stanie dostarczyć. To dopiero mocno wyznaczona linia autonomii, którą znajdziemy w Scrum Guide.
Obserwując i współpracując z kilkoma organizacjami, widziałem różne poziomy autonomii (rozumianej jako niezależność i decyzyjność) zespołów software’owych (wliczając Product Ownera) i ta autonomia nie zawsze zależała od dojrzałości zespołów, ale od całej kultury organizacji. Niektóre zespoły uznawane były za mocne i posiadały sporą autonomię, pokazaną przez zaufanie zarządu, oraz wpływ na kierunek rozwijania produktu, ale widziałem też zespoły z niską i modyfikowaną autonomią. Takie zespoły niestety nie miały wspieranej postawy rozwojowej, o której pisałem w pierwszym akapicie. Brak ustalenia linii autonomii lub brak odpowiedniej współpracy z zespołem powoduje podtrzymywanie niedojrzałości zespołu oraz potrzebę ręcznego sterowania. Takie sterowanie generuje więcej pracy po stronie managementu, który czasami ma w tym swój interes i czuje się bardziej potrzebny… a na pewno przydaje się podczas kryzysów projektowych.
Wyznaczcie linię autonomii zespołom, jeśli chcecie żeby były zmotywowane i wspierajcie ich proces dojrzewania. Dzięki temu będzie więcej wolnego czasu dla zarządu, aby się zrelaksował i skorzystał z przerwy w pracy 🙂
Tomasz Czechowski, RTE
