System pracy ciągnionej (ang. pull system) jest cechą charakterystyczną jednej z naszych ulubionych metodyk zwinnych, czyli Kanbana. Czym charakteryzuje się ten system i dlaczego jest tak istotny z punktu widzenia samoorganizujących się Zespołów Deweloperskich?
Czym jest system pracy ciągnionej?
Definicja systemu pracy ciągnionej jest prostsza, niż nam się wydaje. Mówiąc wprost – jest to system, w którym działamy reaktywnie, w odpowiedzi na pewne sygnały, bądź bodźce. Brzmi prosto, ale na pewno nie zaszkodzi w tym miejscu „życiowy” przykład.
W sytuacji, gdy podczas jazdy samochodem zapali nam się kontrolka rezerwy paliwa czynnością, którą podejmie każdy z nas, będzie zjazd na najbliższą stację paliw i zatankowanie. Nasze działanie zdeterminowane jest sygnałem, który otrzymaliśmy – brakiem paliwa. Zignorowanie sygnału doprowadzi do łatwo przewidywalnej w tym przypadku sytuacji – nasz samochód po prostu zatrzyma się na drodze.
Działamy więc reaktywnie, w odpowiedzi na bodźce, a nie proaktywnie. Ten drugi sposób to np. zatankowanie samochodu do pełna przed wyruszeniem w podróż, chociaż mamy jeszcze 3/4 baku.
Choć system pracy ciągnionej to nie nowość, mało kto wykorzystuje jego zalety w pełni. W dzisiejszych firmach, nawet tych które szczycą się tworzeniem oprogramowania przy użyciu metodyk agile, w dalszym ciągu spotyka się zlecanie zadań do realizacji. Czy tak to powinno wyglądać?
Pull system, czyli co?
System pracy ciągnionej powinien być wykorzystywany codziennie. Jego zaletą jest m. in. ograniczenie kosztów przełączania się między zadaniami. Widziałem jednak sytuacje, w których system ten był teoretycznie wdrożony, a w praktyce – kompletnie niewykorzystywany. Nie trzeba mówić, że nie przynosiło to dobrych rezultatów.
System pracy ciągnionej oznacza kontrolę przepływu zasobów przez system. Celem pracy przy wykorzystaniu pracy ciągnionej jest zastąpienie jedynie zasobu, który został skonsumowany (np. paliwa) w optymalnym czasie. System nazywamy ciągnionym, ponieważ zasoby są wykorzystywane jedynie w przypadku, gdy są aktualnie niezbędne lub gdy zostały zamówione.
W tradycyjnym systemie pracy (ang. push systems) zapotrzebowanie na zasoby nie jest uwarunkowane ich niezbędnością w danej chwili. Zapasy robione są… na zapas. To z kolei może prowadzić do nagromadzenia się ich w jednym miejscu. Stąd już krótka droga do Muda, a więc marnotrawstw. A to nie przystoi w metodyce zwinnej, jaką jest Kanban.
Kluczowym elementem systemu pracy ciągnionej są sygnały. Ten, od którego zaczęliśmy dzisiejszy wpis to zapalenie się kontrolki rezerwy paliwa. Sygnały są informacją dla zaangażowanych w proces o konieczności podjęcia czynności, np. dostarczenia zasobu. W przypadku, gdy w trakcie realizacji wymagań z naszego Backlogu Produktu zidentyfikujemy nienormatywny Cycle Time, będzie on sygnałem do podjęcia działań, np. reorganizacji procesu czy zatrudnienia kolejnych osób.
Innym, typowym sygnałem będzie osiągnięcie lub (o zgrozo) przekroczenie limitu Work In Progress.
System pracy ciągnionej, a samoorganizacja
Jednym z często wymienianych wad zwinnych metodyk (np. Scruma) jest pozostawienie zbyt dużej autonomii poszczególnym zespołom. Owa samoorganizacja jest często solą w oku osób zarządzających projektami. Powyższy stan rzecz ma miejsce po części ze względu ma brak wiary w członków zespołu. Jest to także konsekwencja braku wiedzy w zakresie tego, jak ową samoorganizację zorganizować (patrz: prawdomówność, zaufanie, transparentność).
Jednym z pomysłów, o których pisaliśmy wielokrotnie jest priorytetyzacja Backlogu Produktu przez Product Ownera i pozostawienie zespołom wolnej ręki w temacie Planowania Sprintu. Inną jest zaprezentowanie korzyści płynących z sytemu pracy ciągnionej.
O tym, że system ten generuje wymierne korzyści nie muszę chyba nikogo przekonywać. Brak Muda, czyli waste’ów (marnotrawstw), skupienie się na bieżących priorytetach, brak kosztów przełączania pomiędzy realizowanymi zadaniami – to tylko niektóre z nich.
Wspomniany już Sprint Planning też jest reprezentantem tego podejścia. Bo przecież na sygnał końca Sprintu (lub jak kto woli – rozpoczęcia nowego), zaczynamy tworzyć nowy Sprint Backlog.
Benefity SPC
Zespół, który zna zasady działania systemu pracy ciągnionej nigdy nie będzie się nudził. Nie znajdzie się też w sytuacji, w której nie będzie miał co robić, bo przecież Scrum się nigdy nie kończy. Odpowiedzialni członkowie zespołu w sytuacji, w której ukończą bieżące User Story, wyciągną z backlogu kolejne. Taka sytuacja będzie miała miejsce do czasu, w którym nie skończy się nam backlog bądź Sprint.
Do realizacji prac zgodnie z ideą systemu pracy ciągnionej potrzebujemy jednak odpowiedzialnego zespołu, który zna założenia tego sposobu działania. Nie oszukujmy się i nie oczekujmy, że ludzie, którzy nie znają zasad pracy w tym systemie będą umieli wykorzystać go zgodnie z założeniami.
Nie próbujmy też wykorzystać systemu pracy ciągnionej jako kagańca narzuconego na zespół celem jego zdyscyplinowania. Pamiętajmy też, że potrzebujemy ludzi zmotywowanych, którzy chcą pracować i osiągać kolejne cele.
Czasami przejście na system pracy ciągnionej wymaga zmiany filozofii działania całej firmy. Ale jak pokazuje praktyka, jest to gra warta świeczki.
