Odcinek 70. Jak ugryźć limity pracy w toku?
Limitowanie pracy w toku to praktyka, która definiuje czym jest Kanban i czym są systemy pull. Z jednej strony czujemy, że jest to coś, co może nam pomóc, ale z drugiej jest to nieintuicyjne i może rodzić opór lub strach. Jak zatem „ugryźć” podejście do limitowania pracy w toku tak, by sobie nie zaszkodzić?
Zacznij od praktyki 1. – Wizualizacja
Zanim podam kilka praktycznych wskazówek na temat tego, jak możemy podejść do kwestii limitowania pracy w toku, cofnę się o jedną praktykę wstecz, a więc powiem: „Zacznij od wizualizacji”.
Rzetelna wizualizacja pracy, czyli pokazanie, na jakich krokach (aktywnych i pasywnych) praca kolejkuje się lub starzeje może być swoistym lustrem, które spowoduje że zespół, interesariusze czy menedżerowie będą bardziej otwarci na dyskusję o limitowaniu pracy w toku. Może się tak stać między innymi dlatego, że zobaczymy, iż tej pracy jest po prostu dużo, zobaczymy, iż rzeczy, które są komunikowane jako pilne, w rzeczywistości (bez żadnych konsekwencji!) wcale nie poruszają się w naszym systemie.
Idąc dalej warto zastanowić się nad tym, jaki rodzaj limitowania pracy w toku może nam najbardziej pomóc jako pierwszy krok w stronę ogarnięcia przepływu pracy.
Limit? Jaki limit?
Bardzo często pierwszym i niestety jedynym sposobem limitowania pracy w toku jakie podpowiadają nam narzędzia jest limitowanie zadań na kolumny. Na przykład powiedzenie, że nie możemy mieć w toku więcej niż 5 zadań we developmencie, 2 w testowaniu lub oczekiwaniu na testy. To budzi bardzo często silne obawy o to, że w konsekwencji natychmiast się zatrzymamy, nie będziemy mogli robić tego, w czym jesteśmy ekspertami, albo że zacznie nas się zmuszać do pracy w innych obszarach lub technologii.
W takiej sytuacji warto zastanowić się, czy nie powinniśmy skorzystać z pomocy w postaci wizualizacji i odpowiedzieć sobie na pytanie:
Po ile zadań w stopniach w krokach aktywnych czy pasywnych mamy do siebie przypisanych?
Świadomość tego, że mamy na swoim koncie 3, 4 lub więcej zadań, a w rzeczywistości nad nimi nie pracujemy może być pierwszym krokiem obniżającym opór wokół limitowania pracy w toku, który doprowadzi do tego, że umówimy się, iż po prostu są to za duże liczby. Z jednej strony to oszukiwanie siebie – ponieważ nie pracujemy nad tymi zadaniami oraz oszukiwanie innych – ponieważ tablica czy system nie odzwierciedlają właściwie rzeczywistości.
Ile na kolumnę – ale czy na pewno tylko na jedną?
Kolejnym etapem, w którym możemy pomyśleć o limitowaniu pracy w toku jest limitowanie jej w kolumnach. Tu warto zastanowić się nad tym jak dane osoby, które pracują nad zadaniami w danej kolumnie obecnie kontrybuują do zadań w innych kolumnach. Złotym przykładem jest tutaj zaangażowanie deweloperów w proces przeglądu kodu lub innej akceptacji pracy innych kolegów i koleżanek. Jeśli tak jest, to być może nie powinniśmy limitować tylko i wyłącznie jednej kolumny, ale kilka z nich biorąc pod uwagę to, ile mamy osób pracujących w tych wybranych kolumnach.
Tu często widzę, że popadamy w pułapkę i nie bierzemy zdroworozsądkowo liczby osób, które pracują nad danymi aktywnościami do ustalenia pierwotnych limitów pracy w toku.
Przykładem jest taka sytuacja:
Jeśli mamy 4 deweloperów w zespole, to uznajemy że 4 zadania w fazie development to dobry pomysł.
Okazuje się, że jednak w tym samym czasie zapominamy, iż ktoś z tej wspomnianej czwórki powinien być również odpowiedzialny za code review pracy kolegów i koleżanek. Jeśli tak, to oznacza, że przesadziliśmy z liczbą zadań na aktywny Development i trzeba wprowadzić limit na:
– kolumnę zadań oczekujących na code review,
– kolumnę aktywnego przegląd kodu.
Zamiast pozwalać na 4 zadania w developmencie i code review, co uzasadniałoby wielozadaniowość, to lepiej podzielić ten limit odpowiednio np. na 3 i 1.
A co jeśli robimy więcej niż 1 produkt?
Nadal bardzo często pada evergreenowe pytanie: „Kiedy Scrum, a kiedy Kanban?”. Pomijając, że pokazuje ono dosyć płytkie rozumienie tego, czym jest Kanban, to warto zastanowić się nad tym, czy nasz zespół realizuje naprawdę jeden produkt lub jeden strumień pracy, czy może ma ich więcej?
Mówię o tym, ponieważ są to zdroworozsądkowe założenia, by Scrum jako podejście mógł zadziałać. Jeśli nasz zespół realizuje rozwój 2 produktów lub równolegle obsługuje 2 strumienie pracy usługowej, to prawdopodobnie ważniejszym niż próba stworzenia fikcyjnego celu sprintu będzie właściwe zbalansowanie pracy pomiędzy tymi strumieniami czy produktami.
Oczywiście łatwo powiedzieć – tu powinny być 2 zespoły i może będą, ale nie zapominajmy o kanbanowej zasadzie:
Zacznij od tego, co robisz obecnie.
Tu na pewno warto zacząć śledzić pracę z tych 2 strumieni lub produktów w 2 wierszach i wprowadzić limitowanie pracy w toku na owe wiersze stosując odpowiednio limity maksymalne jak i minimalne upewniając się, że nie zaniedbujemy jednego ze strumieni pracy względem drugiego.
A co jeśli robimy wszystko na raz?
Jeśli wizualizacja przepływu pracy pokazuje, że mamy w toku wiele różnych kontekstów – na przykład wiele rozgrzebanych naraz funkcjonalności, zapytań czy epików, to warto zastanowić się nad tym, do ilu różnego rodzaju kontekstów na naszej tablicy powinniśmy je limitować.
Nawet praca nad jednym produktem czy celem możne nie gwarantować, że nie umknie nam fakt, że nasza tablica to tak naprawdę zbiór zadań należących do bardzo wielu różnych kontekstów, którymi próbujemy żonglować. Warto zastanowić się tutaj, iloma wysokopoziomowymi elementami wartości powinniśmy się w dalej chwili zajmować.
A kiedy czas na zmianę?
Niezależnie od tego, od którego ze sposobów na limitowanie pracy w toku rozpoczniecie swoją przygodę, warto postawić sobie od razu pytania:
Jakie wydarzenia krótkie lub długoterminowe powinny powodować, że zmieniamy wartości lub typy tych limitów?
Bardzo często widzę, że doszukujemy się tutaj potężnych wydarzeń w stylu odejście kogoś z zespołu albo jego stałe powiększenie. Super, ale nawet drobne rzeczy takie jak kilka dni urlopu albo zaangażowanie w gaszenie pożaru w innym projekcie są rzeczami, które już powinny skłonić nas do zrewidowania wartości i typów limitów pracy w toku.
Czy to już wszystko?
Pamiętajmy, że Kanban to właściwie zawsze „work in progres”, to zawsze praca nieskończona i również to, że koniecznie powinniśmy dokonywać rewizji naszych limitów pracy w toku – ich wartości i typów. Nie oznacza to wcale, że robimy coś źle. Oznacza to tylko, że dokonujemy inspekcji i adaptacji (jak powiedzieliby nasi koledzy i koleżanki Scrumowcy) lub że wprowadzamy pętlę zwrotną, która powoduje, że polityki naszego systemu są adekwatne do zastanej rzeczywistości.
Jestem ciekaw, jakie Ty masz przygody z limitowaniem pracy w toku, jakiego sposobu lub sposobów próbowaliście i jakie dało to skutki. Koniecznie daj znać w komentarzach lub na mediach społecznościowych.