Paweł Słowikowski – praktycznie – Samoorganizacja, zwinność i turkus

Zajęta osoba w biurze robiąca wiele rzeczy na raz Bycie zajętym może zaspokajać wiele potrzeb. Po pierwsze, daje poczucie bezpieczeństwa - jeśli pokazujemy, że “coś robimy”, to jest mniejsza szansa, że ktoś będzie miał do nas jakieś uwagi czy zastrzeżenia. Po drugie, może sprawiać, że czujemy się ważni, potrzebni. Kolejne spotkanie, kolejna osoba potrzebuje pomocy - bierzemy wszystko na siebie i czujemy się jak superbohater! Po trzecie wreszcie, na tle całej organizacji, te zespoły i działy, które pokazują najwięcej “robionych” rzeczy oraz najśmielsze plany, dostają najczęściej największą uwagę, finansowanie i wpływy.

W poniższym wpisie postaram się rozwinąć temat kultu zajętości w organizacjach - skąd się wziął, czemu jest to problem oraz jak go diagnozować i leczyć.

Jeśli wolisz wersję mówioną, to możesz posłuchać podcastu Agile po przejściach, gdzie wraz z Tomkiem Feliksikiem rozwijamy ten temat w trzech częściach:

Część 1 - o tym, czemu zbyt duża ilość pracy w toku to problem
Część 2 - o tym, jak diagnozować problem
Część 3 - o tym, jak temu zaradzić

Gdzie tu jest problem?

Zacznijmy od mniej oczywistej rzeczy. Czemu zbyt mała ilość WIP (work in progress - pracy w toku) może być szkodliwa dla organizacji? I kiedy w ogóle możemy o tym mówić? Na przykład wtedy, kiedy jest zbyt mało zleceń. Łatwo to zobrazować w firmie typu software house, kiedy ludzie siedzą na tzw. ławeczce - bez projektu klienckiego. Firma wtedy cierpi z powodu niewykorzystanych możliwości oraz potencjalnie - strat finansowych. Z mojego doświadczenia wynika, że najczęściej dochodzi do takiej sytuacji z przyczyn zewnętrznych (takich jak brak zleceń), a rzadziej z przyczyn wewnętrznych (zbyt agresywnie ustawione limity WIP). O ile na to drugie możemy zareagować dosyć szybko (np. sprawdzając spadek przepustowości systemu i zwiększając WIP limit), to na to drugie wpływa wiele czynników, których często nie kontrolujemy.

Znacznie częściej jednak zdarza się, że organizacje mają zbyt dużo rozpoczętej pracy.

Oto tylko niektóre konsekwencje takiej sytuacji:

Ciężej jest zobaczyć wartość tego, co dostarczamy, bo wydłuża się pętla sprzężenia zwrotnego (rzadziej dostarczamy rzeczy).
Ciężej jest mierzyć przepływ i zidentyfikować wąskie gardła. Można to porównać do sytuacji, kiedy poziom wody w rzece jest duży i nie widać niebezpiecznych kamieni na dnie.
Powstaje więcej zależności, bo otwierając nową pracę zwiększamy ryzyko tego, że ktoś nie jest gotowy z czymś, co jest potrzebne do jej ukończenia.
Pojawia się potrzeba tworzenia dodatkowych ról, których zadaniem jest koordynowanie zależności i statusów otwartej pracy.
Wzrost zatrudnienia (a w związku z tym też kosztów), bo zamiast ograniczyć WIP, zarządcy próbują zwiększyć przepustowość przez dodanie rąk do pracy. A to najczęściej kończy się otwieraniem jeszcze większej ilości pracy.

Dlaczego generujemy tyle pracy w toku?

Jak już wspomniałem we wstępie, przyczyn generowania pracy w toku może być wiele. Często sami sobie generujemy więcej pracy, bo dzięki temu czujemy się bezpieczni - łatwo udowodnić sobie i innym, że jesteśmy potrzebni, bo mamy tak wiele spraw na głowie i w tak wiele tematów jesteśmy zaangażowani. Dodatkowym czynnikiem może być też niechęć (wspierana często przez brak bezpieczeństwa psychologicznego) do odmawiania i kolejkowania rzeczy. Łatwiej jest nam odroczyć nieprzyjemną sytuację na później, niż zmierzyć się z zawiedzionymi oczekiwaniami drugiej osoby już teraz. Mechanizmy te obserwowałem zarówno na poziomie zespołu (developerzy biorący kolejne zadanie od szefa, bo ‘szefowi się nie odmawia’) jak i na poziomie zarządzania portfolio - na przykład w jednej z firm management nie był w stanie ustawić strategii priorytetyzacji swoich klientów, bo kiedy tylko jeden z nich spadał ‘niżej’, od razu sprawa była eskalowana do CEO firmy i nagle okazywało się, że można rozpocząć kolejną porcję pracy, a zaparkować poprzednią.

Oprócz czynników ludzkich występują też czynniki systemowe. Jednym z takich czynników jest próba balansowania podaży i popytu na usługi w organizacji. W pierwszym wpisie z cyklu wspomniałem o mechanizmie rozrostu struktury. Jest on powiązany z nadmierną ilością pracy w toku - razem tworzą pętlę, z której ciężko jest się wydostać.

Innym czynnikiem wpływającym na wzrost pracy w toku jest brak zorganizowania się wokół przepływu wartości. Kiedy mamy strukturę, która dzieli firmę na działy, a zespoły skupia wokół komponentów (lub funkcji: np. developerzy danej technologii, zespół testerów, admini, etc.), w naturalny sposób tworzą się zależności - praca będzie rozdzielana tak, aby nikt się nie nudził (bo przecież ‘nie płacimy im za bezczynność’). A wtedy często pojawia się pokusa ‘dokończenia swojej części’ i wzięcia kolejnej porcji pracy. Developerzy dostarczą kod do repozytorium, a tam będzie już sobie czekał na testy, akceptację działu prawnego i feedback od użytkowników. W tym czasie zespół rozpocznie już pracę nad kolejną porcją wymagań.

Ostatnim przykładem systemowego czynnika prowadzącego do wzrostu pracy w toku może być techniczne ograniczenie w zdolności do szybkiego dostarczania małych porcji produktu. Proces testowania i wdrażania na przykład może nie być zautomatyzowany, a przez to czasochłonny, kosztowny i bolesny (praca po godzinach, walka z błędami, etc.). Zespoły będą wtedy dążyły do równoległego otwierania dużej ilości pracy i kumulowania jej w duże paczki, które później będzie można wielkim wysiłkiem wdrożyć.

Jak zdiagnozować to, że robimy zbyt wiele rzeczy na raz?

Polecam zwrócić uwagę na następujące symptomy:

Wydłużające się kolejki, a szczególnie obecna i zapełniająca się kolumna ‘on hold’ (lub ‘blocked’). Otwartą pracę w poszczególnych stanach można wizualizować w np. w Jirze przy pomocy filtrów 2-wymiarowych (status vs. typ zadania) oraz Cumulative Flow Diagram.
Wydłuża się czas potrzebny na dostarczenie czegoś end-2-end. Można tutaj zmierzyć lead time większych inicjatyw (będzie rósł). Może się zdarzyć, że lokalnie ten czas nie będzie rósł (bo zespoły mogą mieć Definition of Done ograniczone do ‘nasza część zrobiona’), a dopiero całość funkcjonalności będzie opóźniona. Większy WIP będzie generował więcej zależności, stąd na całość poczekamy dłużej.
Starzejący się WIP, starzejący się backlog. Więcej WIP generuje więcej zależności, w związku z tym praca częściej będzie odkładana ‘na półkę’ (bo oczekuje na kogoś innego). Będzie to widać np. na wykresie ‘Average Age’ w Jira Dashboard.
Coraz więcej spotkań koordynacyjnych. Znowu wracamy tutaj do zwiększającej się liczby zależności oraz potrzeby monitorowania zablokowanych zadań.
- W związku z tym będzie dało się zauważyć nowe role koordynujące proces delivery (delivery lead, program manager/coordinator, etc.)
Bardzo ciężko uzyskać w organizacji odpowiedź na pytanie ‘co jest teraz tą jedną najważniejszą rzeczą, którą chcemy zrobić?’ Duża ilość otwartej pracy utrudnia alignment i priorytetyzację.
Przewidywalność realizacji celów spada, a często także wydłuża się time-box, na który planujemy (np. kwartał/PI staje się nowym ‘sprintem’). Zamiast prowadzić mały strumień pracy i robić rzeczy po kolei (i dostawać często feeback), organizacja próbuje włożyć wiele rzeczy na raz do ‘worka’ jakim jest kwartał czy Program Increment.

Jak rozwiązywać ten problem?

“Podstawowy problem z limitowaniem jest taki, że o ile większość z nas rozumie (nawet podświadomie), że za mało to szkoda niewykorzystanych możliwości, a za dużo to będzie długo, to prawdziwą trudnością jest odpowiedzieć na pytanie ‘ile to optymalnie?’”
- Tomek Feliksik

Skłaniam się ku poglądowi, że nie ma jednej słusznej odpowiedzi na to jaka powinna być ilość pracy w toku. Rozwiązaniem jakie proponuję, to stworzenie funkcji celu (co optymalizujemy) i takie sterowanie elementami systemu (np. WIP limitów), aby iteracyjnie szukać naszego maksimum.

Pierwszym krokiem do poprawienia sytuacji jest zwiększenie transparencji realizowanej pracy. W przypadku ‘zapchanych’ organizacji często mamy sytuację, że zmierzenie ilości pracy w toku może nie pokazać na początku problemu, bo duża część pracy nie jest nigdzie zmapowana, lub jest zmapowana w różnych narzędziach (bez integracji między nimi). Kilka pomysłów jak poradzić sobie z tą sytuacją opisałem w poprzednim wpisie.

Jak już mamy zmapowaną pracę, możemy zacząć ją mierzyć. Tutaj warto skupić się na trendach (zmianie w czasie), a nie na pojedynczych snapshotach. A jak już masz dane, to pokazuj, edukuj, twórz przestrzeń do dyskusji o zagrożeniach związanych ze stanem obecnym. Sprawdzaj jednocześnie postępy, kiedy coś zmieniasz w systemie (np. jak wprowadzenie limitu pracy w toku wpływa na lead time).

Rzeczy, które warto mierzyć, kiedy walczymy ze zbyt dużą ilością pracy w toku:

Wykres pracy w toku zmieniający się w czasie (WIP run chart). Będzie pokazywał efekty wprowadzania limitów.
Wiek pracy w toku (WIP Age) i gdzie praca się starzeje. Dobry ‘leading indicator’, który pokazuje potencjalne wąskie gardła wcześniej, niż analiza cycle time.
Cycle time/Lead time - czas przejścia zadań przez system. Zmniejszanie ilości pracy w toku powinno zmniejszać ten wskaźnik.
Długość kolejek, czyli ilość pracy w danym statusie (i jej zmiana w czasie). Pokazuje potencjalne wąskie gardła - szczególnie w połączeniu z kolumnami buforowymi (np. ‘ready for testing’).

Pomocne praktyki zmniejszania WIP na poziomie zespołu

Wypracowywanie celu sprintu i skupienie komunikacji wokół (re)planowania działań mających przybliżyć zespół do jego realizacji (na przykład na daily).
Analiza sprint backlog lub tablicy kanbanowej od prawej do lewej (od rzeczy, które są bliżej ‘done’) aby stworzyć nawyk dokańczania zadań
Pytania do zespołu: “jak inaczej możemy się podzielić pracą, aby domknąć tematy?”, “co jeszcze możemy zrobić, aby zwiększyć szansę na dostarczenie celu?”
Zachęcanie do eksperymentów z pracą w parach (także poza swoją specjalizacją). Tutaj polecam książkę Joy, Inc. o powstaniu firmy Menlo i jak można na pracy w parach oprzeć całą kulturę organizacji.
Stopniowe rozszerzanie DoD aby wykrywać i rozwiązywać problemy z szybkim wdrażaniem małych porcji produktu.
No i oczywiście: świadome i poprawne wdrażanie metody Kanban (czyli łącznie z trudną sztuką wprowadzania limitów WIP) i podejścia ‘stop starting, start finishing’.

Przykład zmniejszania WIP na poziomie organizacji

Wizualizacja przepływu wartości od samego źródła (upstream kanban) aby stworzyć wspólny lejek dla inicjatyw firmowych.
Kiedy już mamy wizualizację, możemy tym zarządzać i wdrożyć mechanizmy filtrowania i odrzucania inicjatyw w lejku - np. na podstawie kryteriów takich jak orientacyjna wielkość, zgodność z długofalową strategią, szansa na rozwój, etc. Widziałem takie mechanizmy zaimplementowane na poziomie zarządu firmy, gdzie filtrowano inicjatywy, które później rozbijano na mniejsze części w dalszych strumieniach (zorientowanych wokół produktów i/lub usług). Działa dobrze wtedy, kiedy strategia i plany firmy są jasno określone.
Mierzenie i pokazywanie wąskich gardeł w systemie. Może być tak, że praca jednego zespołu (np. takiego wdrażającego produkt na produkcję) może generować duży WIP w innych zespołach, które robią ‘na zapas’ i wrzucają na koniec zlecenia wdrożenia do tego jednego zespołu. Zwizualizowanie i zmierzenie tego problemu jest pierwszym krokiem do wprowadzenia zmiany w systemie - na przykład rozproszenia praw (i umiejętności) do wdrażania produktu po innych zespołach.
Wprowadzenie systemu, gdzie aby rozpocząć nową pracę (na poziomie między zespołowym) trzeba najpierw upewnić się, że zasoby i zespoły, od których będziemy zależni, faktycznie mogą się taką pracą zająć. Tutaj ponownie przyda się stworzenie jednego lejka inicjatyw, aby uświadomić interesariuszy, że ich zlecenie może wpłynąć na inne, już toczące się projekty.
Dostarczanie potrzebnych informacji zespołom, interesariuszom i zarządcom aby mogła zaistnieć samoregulacja (pętla sprzężenia zwrotnego) - patrz punkt “rzeczy, które warto mierzyć”.

Na koniec chciałem dodać, że temat ograniczania pracy w toku jest, moim zdaniem, jednym z najważniejszych, a jednocześnie - jednym z najbardziej skomplikowanych w pracy z organizacją. Kult zajętości nie łatwo wyplenić - a do tego to, co uda nam się osiągnąć na poziomie zespołu, nie zawsze przełoży się na zyski w szerszym przepływie. Jest to jednak (dla mnie) ciekawe, fascynujące zagadnienie, które daje bardzo duże efekty w udrażnianiu przepływu w firmie. Moim zdaniem, gra warta świeczki!