Przypuśćmy, że ten sam zysk netto można osiągnąć na wiele alternatywnych sposobów. Czy w takim razie ma znaczenie, czy robimy to poprzez rozwiązania spięte hasłem agile? Ma. I o tym będzie w dzisiejszym odcinku.
Centralne zarządzanie
W najbardziej modelowym przypadku w dużej organizacji struktura zarządzania wygląda jak na poniższym obrazku.
Na bezimienną masę specjalistów zostaje nałożona siatka zarządzająca w postaci funkcjonariuszy organizacji. Ich zadaniem jest takie sterowanie specjalistami, aby wykręcić kupony dla udziałowców i/lub dywidendę dla akcjonariuszy.
W teorii za priorytety, czyli za to nad czym owi specjaliści aktualnie pracują, odpowiada Strategia . W zależności od inwencji jest to dokument tekstowy, prezentacja albo OBRAZEK, KTÓRY WYJAŚNIA WSZYSTKO.
Jednak w praktyce stosujemy najczęściej dwie techniki ustalania priorytetów:
- kto głośniej i częściej krzyczy - wiadomo, że o swoje trzeba dbać i swój budżet trzeba wychodzić
- skarżenie do mamy albo taty - potocznie nazywane eskalacjami
Na koniec i tak przychodzi prezes, daje wszystkim łbach i ostatecznie ustala, co będzie się działo.
Jest tak, gdyż prezes ma swoje cele do osiągnięcia. Dzieli je na kawałki i przydziela cele roczne dyrektorom pionów (powiedzmy, że do niego raportują), ci zaś swoje cele rozdzielają na dyrektorów departamentów itd. w dół. Koniec końców, pakiet celów rocznych całej organizacji rzeźbią specjaliści.
Nie mam nic przeciwko celom rocznym, bo to dobre narzędzie pomagające w skupieniu się. Sęk w tym, jak to jest ustawione.
Wspomniana wyżej siatka zarządzania organizacją rozdziela cele w swoim gronie, a za pomocą podległej im masy ludzkiej w postaci specjalistów dąży do ich osiągnięcia.
Dodatkowo od osiągnięcia celów zależą premie, a niekiedy być albo nie być w organizacji. Więc im bliżej ocen rocznych, tym więcej spięcia w kręgosłupie i niżej.
Z związku z powyższym pojawia się bardzo duża pokusa na silną kontrolę i mikrozarządzanie.
Co agile zmienia?
Moim zdaniem istotne są tu przede wszystkim dwa wątki, na których chciałbym się dalej skupić.
Po pierwsze najwięcej kłopotów pojawia się w tematach, które we frameworkach adżajlowych nie są wytłuszczone grubą czcioną, lecz przewijają się niejako między wierszami. Chciałbym je tutaj naświetlić.
Po drugie niektóre z pojęć przypisywanych adżajlowi np. samoorganizacja, czy to okropne słowo "kroskompetencyjność" są moim zdaniem rozumiane opatrznie. To również chciałbym naprostować.
Samoorganizacja nie samowolka
Jako nastolatek w wakacje dorabiałem zbierając wiśnie w podgrójeckich sadach. Była to wspaniała fucha na świeżym powietrzu z nielimitowanym czasem pracy, czyli od 6 do 20.
W pierwszych dniach wiśniobrania dobieraliśmy się w małe grupy i każda z nich obejmowała jakąś część sadu. Szybko się okazywało, że aby zarobić jakieś sensowne, na tamte czasy, pieniądze trzeba zebrać 180-220kg wiśni dziennie. I ta wartość stawała się niepisaną normą dla grupy rwaczy.
Zdarzało się często, że ktoś z pracowników nie mógł wyrobić normy albo rwał niedokładnie i zostawiał owoce na drzewach. Taki delikwent dostawał jedno ostrzeżenie i w przypadku braku poprawy, był grzecznie proszony o odłączenie się od grupy i bumelowania na innych drzewach.
I to była, proszę Państwa, SAMOORGANIZACJA. Nasza grupa miała cel w postaci norm dziennych, które wprost przekładały się na gotówkę - 30gr./kg.
Jasne, nie namawiam tu do wywalania z zespołów. Mam jedynie wrażenie, że samoorganizacja bywa przez zespoły rozumiana jako totalna samowolka.
Jesteśmy samoorganizującym się zespołem, więc spieprzaj, dziadu i proszę nam się nie wtrącać w nasze sprawy.
No, nie! Ktoś tu przecież finansuje ten zespół i ma wszelkie prawo zapytać: "jak i na co zostały wydane moje pieniądze?". Ma również prawo powiedzieć: "nie jestem zadowolony z waszej pracy".
Bardzo łatwo przełknąć powyższe uprawnienia, jeżeli tylko sobie przypomnisz, co mówiłeś do ekip, które wykańczały twoje mieszanie albo budowały twój dom. Wszystko to, co usłyszały ekipy remontowo/budowlane, mogą - co do przekazu - usłyszeć również zespoły deweloperskie.
Cechą samoorganizacji jest to, że zespół sam dobiera środki do osiągnięcia celu, a nie to, że robi, co chce.
Dekompozycja problemu
Moim zdaniem najważniejszym punktem w procesach zwinnych jest koncentracja na celach biznesowych. Np. w Scrumie są to cele sprintu. Zaryzykuję stwierdzenie, że umiejętność pracy na celach sprintu (biznesowych, nie paczce zadań do zrobienia) jest probierzem zwinności całej organizacji.
Poklastrowanie organizacji na zespołu scrumowe, z których każdy regularnie dostarcza porcję pożądanych (czyli wartościowych) funkcjonalności jest niczym innym jak dekompozycją złożonego problemu biznesowego na mniejsze podproblemy również biznesowe. Trochę jak microservices, lecz w odniesieniu do organizacji.
I teraz uwaga, bo Conway's Law wystrzela nas po pyskach.
IT bez Biznesu
Może się zdarzyć, że dekompozycja dotyczy architektury oprogramowania. Delivery dziarsko wyżywa się na Spring Boot, CQRS i #abraKadabra, natomiast Biznes idzie własną drogą.
Jedną z największych pułapek w naszej branży jest to, że wszystko da się zakodować. Potrzebny nowy klient poczty? Kodzimy! Potrzebny nowy kompilator? Kodzimy! To tylko kwestia czasu i pieniędzy. W takim przypadku IT będzie próbowało rozwiązywać problemy biznesowe na sposób techniczny.
Przykład: Wielki Rafaktor
Najbardziej typowym przykładem rozwiązywania problemów biznesowych na sposób techniczny jest WIELKI REFAKTOR, czyli przepisywanie systemu do nowej architektury lub technologii.
Nawet jeśli przepisywanie ma swój początek w uwarunkowaniach biznesowych, to jest marszem ku klęsce z jednego powodu - przepisujemy 1:1, czyli wszystko. Tak zrobią developerzy, gdy otrzymają zadanie refaktoringu systemu.
Tym czasem takie przedsięwzięcie powinno być poprzedzone analizą biznesu odnośnie do dochodowości funkcjonalności. Przepisujemy tylko to, co się opłaca. Reszcie klientów wypowiadamy umowy. Takie życie.
Jeszcze raz, dla podkreślenia wagi - refaktoring bez przecięcia z analizą biznesową jest rozwiązywaniem problemów biznesowych na sposób techniczny. W każdym przypadku to przyczyna nieszczęść.
Biznes i IT idą zawsze w parze
Dekompozycja, o której mowa powinna dotyczyć zarówno biznesu/produktu jaki technikaliów/kodu tak, aby każdy team mógł pracować nad (w miarę) niezależnym kawałkiem kodu i (w miarę) niezależnym kawałkiem biznesu.
W ten sposób duży temat biznesowy został zdekomponowany na, powiedzmy kilkanaście (w miarę) niezależnych zespołów.
Co w takim układzie oznacza niepowodzenie sprintu jednego czy dwóch zespołów?
Nie pokuszę się o stwierdzenie, że "niewiele". Jednak łatwiej jest zarządzić takim zdarzeniem i ma ono (w miarę) ograniczony wpływ na pozostałą część organizacji. Mówię tu zarówno o biznesie jak i o architekturze (pamiętamy, że dekompozycji uległy solidarnie obie te rzeczy).
Z drugiej strony, co oznacza niepowodzenie zespołu w organizacji, w którym IT i Biznes żyją każde swoim życiem? Cóż, w pierwszej kolejności eskalacje, w drugiej zebrania, w trzeciej szafoty.
Tak, tak, proszę Państwa, procesy adaptacyjne poprawiają BHP w organizacji.
Spychanie decyzyjności
W organizacji jak z początkowego obrazka, tłum specjalistów nadzorowany jest przez siatkę zarządczą managerów różnego szczebla.
W procesach adaptacyjnych chcemy "team empowerment". Umożliwiamy podejmowanie decyzji na możliwie najniższych szczeblach organizacji. O nadmiernej kontroli przeczytasz w artykule Blady strach padł na managerów.
Początkowo taka utrata kontroli brzmi przerażająco. Nie jest to jednak utrata, lecz zamiana. Zamieniamy część kontroli na przejrzystość. O tym w kolejnym punkcie.
Przepływ informacji zarządczej
Mam swoją definicję tzw. zwinnej organizacji. To taka, w której osiągnięto szybki i sprawny przepływ informacji zarządczej (zgodniej ze stanem faktycznym i upiększanej) w górę, w dół i na boki. Pomaga to w sprawnym zarządzaniu priorytetami.
Tymczasem organizacje cierpią na dwie choroby:
- arbuzowe statusy - projekty mają dwa statusy: zielony - to jest wszystko super oraz arbuzowy - to jest z wierzchu zielono, ale w środku czerwono. Czyli brak przejrzystości
- kiszenie informacji - informacje kiszone są na mailach aż do samego deadline, a potem jest bieganina i znów eskalacje i skarżenie do mamy albo taty. Czyli paraliż decyzyjny.
Pełnokompetentność
Jak ładnie powiedział ostatnio pewien developer: "zespół jest organizmem, a nie mechanizmem".
Zwinność chce od zespołu, aby potrafił samodzielnie osiągać swoje cele, czyli aby był pełnokompetentny. Niekoniecznie pojedynczy człowiek ma taki być, ale zespół już tak.
Żeby brali odpowiedzialność
Za każdym razem, gdy rozmawiam z managerami i pytam, czego chcą od pracowników, powtarzają tę samą frazę: "żeby brali odpowiedzialność".
Po wnikliwszym drążeniu okazuje się zazwyczaj, że nie chodzi o odpowiedzialność za pracę. Chodzi przede wszystkim o odpowiedzialność za efekty tej pracy i za relację z klientami.
Żeby pojawiło się to poczucie odpowiedzialności potrzebna jest autonomia, wspomniana wyżej decyzyjność i wpływ na to, co robię. Tak to się nawzajem napędza.
Poza zespołami
Zgłaszają się do mnie klienci, którzy pracują w procesach zwinnych od dłuższego czasu i twierdzą, że to wciąż nie to.
Jestem absolutnie przekonany, że kwestie zwinności w pojedynczych zespołach mamy już - jako branża - wystarczająco dobrze rozpracowane. Jeśli pytasz jakie podejście należy wdrożyć dla tego, czy innego zespołu, bez wahania odpowiadam: whatever works for the team!
Tak bardzo skupiliśmy się na wnikaniu w różnorakie dysfunkcje zespołów, że straciliśmy z oczu perspektywę organizacji. Ze względu na wyżej opisaną dekompozycje celów biznesowych to, że w jednym czy w dwóch zespołach źle się dzieje, najczęściej nie jest aż tak wielkim problemem w kontekście całości. O wiele większym problemem jest to, co się dzieje między zespołami.
To poza zespołami rozgrywa się polityka, eskalacje, wojna o zasoby i przestoje. Procesy zwinne mają na to swój pomysł. Kładą nacisk na:
- samoorganizację,
- dekompozycję celów przez wszystkie warstwy organizacji
- przenoszenie decyzyjności na możliwie najniższy poziom hierarchii
- pełnokompetentność zespołów
- poczucie odpowiedzialności i właścicielstwa
- sprawny przepływ informacji zarządczej
Gorąco wierzę, iż wystarczająco klarownie uargumentowałem, że trajby i tablica w Jirze nie wystarczą 😛
