Kiedy robienie mniej znaczy więcej – o limitowaniu pracy w toku

Limitowanie pracy w toku (ang. limit work in progress, limit WIP) traktuję tutaj jako szerokie zagadnienie – ideę i jedną z zasad pracy Kanbanem, z której może korzystać każdy. To więcej niż limity na tablicy. To podejście do sposobu pracy, priorytetyzacji zadań, współpracy w zespole. Odpowiednio stosowane skraca czas realizowania zadań i poprawia jakość pracy. Można mówić o jego dwóch wymiarach – osobistym oraz zespołowym i to nie tylko w odniesieniu do zespołów Kanbanowych.

Limitowanie pracy per osoba

Dawid Anderson definiuje limity jako pojemność (ang. capacity) systemu. Posłużę się przykładem z życia, żeby to wyjaśnić. Jeśli założymy, że szatnia w restauracji jest systemem, goście, którzy chcą z niej skorzystać, są pracą w toku. Łatwo określić pojemność systemu przez ilość wydawanych numerków – fizycznych miejsc na odzież. W przypadku pracy intelektualnej capacity to możliwości wytwórcze pojedynczej osoby albo zespołu. Dlatego warto odpowiedzieć sobie szczerze na pytania: Ile zadań jestem w stanie realizować jednocześnie? Przełączenie się pomiędzy iloma tematami daje mi większą wartość niż zajęcie się nimi po kolei? Dla naszego mózgu każda zmiana kontekstu potrzebuje czasu na ponowne przypomnienie sobie związanych z nim zależności. Wyobraź sobie, że piszesz ważnego maila i nagle dzwoni telefon. Na chwilę odrywasz się od pisania, wracasz i co robisz? Czytasz kilka ostatnich zdań, żeby odzyskać kontekst, przełączyć się na tryb pisania. Dlatego tak efektywna, zarówno w pracy indywidualnej, jak grupowej jest technika Pomodoro, w której określasz cykl – np. 25 min. na realizację konkretnego zadania, a po tym czasie robisz krótką przerwę. W czasie pracy nie pozwalasz, by cokolwiek oderwało cię od tego, czym aktualnie się zajmujesz.

Podczas szkoleń z Kanbana proponuję proste ćwiczenie, które w niespełna 3 minuty pokazuje, że częste przełączanie się pomiędzy kontekstami jest marnotrawstwem czasu. Proszę uczestników o wypełnienie dwóch analogicznych tabel, które powinny zawierać cyfry arabskie od 1-12, miesiące, cyfry rzymskie i litery alfabetu. Trywialne zadanie. W pierwszym kroku uczestnicy wypełniają tabelę poziomo, wpisując kolejno – 2, luty, II, B; 3, marzec… W drugim – pionowo. Za każdym razem zapisują czas wypełnienia całej tabeli. Różnice w osiągniętych wynikach potrafią być miażdżące. Podsumowaniem ćwiczenia zawsze jest ciekawa dyskusja poparta przykładami z życia. Poprzedza ją chwila ciszy i wymiana znaczących uśmiechów, a następnie komentarze typu – no tak, oczywiste. Co ciekawe, nawet podczas wykonywania tak prostego zadania, konieczność przełączania się pomiędzy kontekstami (cyfry, litery, miesiące) zwiększa ryzyko błędu. Tabele wypełniane poziomo bywają pokreślone, bo tuż po wpisaniu miesiąca, który następuje po “czerwcu”, trzeba było sobie przypomnieć literę po “f”.



tabela

Jest jeszcze jeden, praktyczny aspekt tego zagadnienia. Nawet jeśli uznać, że przełączanie kontekstu nic nas nie kosztuje, czas zainwestowany w robienie kilku zadań jednocześnie, często może zostać wykorzystany na pełną realizację minimum jednego z nich. To z kolei powoduje szybsze wywiązywanie się ze zobowiązań, większą elastyczność w zarządzaniu czasem i… co równie ważne, daje satysfakcję i pozytywną energię do realizacji kolejnych zadań.

Niezależnie od tego, czym się zajmujecie, zachęcam Was do eksperymentu z limitowaniem pracy w toku. Jak zacząć? Może od rygorystycznego limitu – realizuję maksymalnie 2 zadania jednocześnie. A może od sprawdzenia, jak to wygląda w tej chwili – wypisania wszystkich trwających zadań i na ich podstawie zdecydowania, od jakiego limitu rozpocząć. Tym, których zaciekawił temat, proponuję zgłębienie idei Personal Kanban.

Limitowanie pracy w zespole

A jak to wygląda na poziomie pracy zespołowej? Zaryzykuję stwierdzenie, że limitowanie pracy nie jest domeną większości zespołów. Intuicyjnie każdy z nas skupia uwagę na swoim kawałku pracy, działamy w tzw. systemie push – każdy robi tyle, ile tylko może, nie zważając na to, czy osoba, której przekazujemy zadanie, faktycznie jest w stanie je przejąć. Łatwo wtedy o pośpiech, a co za tym idzie słabą jakość, frustrację, nieporozumienia i wzajemne pretensje. Przy takim układzie efekty pracy całego zespołu bywają różne.

wip-1-agile247pl-1200

Inne podejście to postrzeganie całego procesu, w którym pracujemy, jako całość i dążenie do tego, żeby zadania płynnie przepływały przez wszystkie etapy ich realizacji. To działanie zgodne z system pull – osoba, która właśnie ukończyła pracę, daje znak, że jest gotowa przejąć kolejne zadanie. Tutaj liczy się zarówno efekt końcowy, czyli wartość, jaką dostarcza cały zespół, jak i komfort pracy wszystkich zaangażowanych osób. Osiągnięcie takiego modelu nie jest łatwe.

wip-2-agile247pl-1200

Weźmy jako przykład Sprint Review zespołów scrumowych, podczas których zespół prezentuje efekty pracy sprintu. Na takich spotkaniach zdarza się słyszeć, że część zadań została rozpoczęta, ale nie udało się ich zakończyć. Co takiego sprawia, że członkowie zespołu zamiast skupić się na realizacji wspólnymi siłami kilku czy nawet jednego z nich, zabierają się za nowe tematy? Być może silosy kompetencyjne, które powodują, że trudno pracować razem nad jednym zadaniem, ambicja zrobienia wszystkiego za wszelką cenę, brak przekonania, że dostarczenie jednego, gotowego rozwiązania jest bardziej wartościowe niż “rozgrzebanie” kilku, a może po prostu siła przyzwyczajenia i wybieranie zadań do realizacji spośród tych jeszcze nietkniętych? Niezależnie od przyczyn, warto zastanowić się, jak pracować efektywniej jako zespół.

Trochę przerysowana tablica 3 osobowego zespołu (2 dev + tester), który koncentruje się na realizacji, a nie kończeniu zadań, mogłaby wyglądać, jak ta poniżej. Sporo się dzieje, wszyscy są “zarobieni”, ale niewiele z tego wynika.

Niezależnie od powodów i wybranej metodyki, limitowanie pracy w toku w zespole można rozpocząć od stosowania dwóch prostych, wzajemnie uzupełniających się zasad:

  • Zacznij kończyć, przestań zaczynać.

Skup się na kończeniu swoich zadań/zadania, zanim zabierzesz się za kolejne. A jeśli już skończysz, to, co zacząłeś, sprawdź, co możesz zrobić, żeby przyspieszyć realizację trwających zadań, nad którymi pracują inni.

  • Patrz na tablicę od prawej do lewej.

Najprostszy sposób na wyłapanie zadań, do pracy nad którymi warto się przyłączyć, to sprawdzanie tablicy od prawej strony. Nie jest to oczywiste, bo po zamknięciu zadania, intuicyjnie spoglądamy na te jeszcze nietknięte z backloga. Racjonalne stosowanie tych dwóch zasad sprawia, że zespół szybciej dostarcza gotowe rozwiązania. Dodatkowo zmienia sposób rozmowy i współpracy, wspiera wymianę kompetencji, a w konsekwencji wzmacnia zespołowość.

Załóżmy jednak, że mój przykładowy zespół (2 dev + tester) zdecydował się na krok dalej i wprowadził limity na etapach pracy – średnio 2 zadania na osobę.

Co to  zmienia w sposobie jego działania? Jeśli na którymś z etapów limit zostanie osiągnięty, nie można zabrać się za kolejne zadanie, póki nie zostanie zwolnione na nie “miejsce”. Teoretycznie może się zdarzyć, że któryś z developerów albo tester nie będą mieli pracy – dopadnie ich tzw. slack time. Strata czasu? Nie, pod warunkiem, że czas oczekiwania zostanie spędzony na pożytecznym temacie – pomocy innej osobie z zespołu, automatyzacji części swojej pracy, poszukiwaniu nowych rozwiązań technologicznych albo po prostu analizie tego, w jaki sposób funkcjonuje zespół i wynajdowaniu miejsc wartych usprawnienia.

Limitowanie pracy w toku w zespole scrumowym pozwala efektywniej wykorzystać czas sprintu. Limity i sposób współpracy w zespołach kanbanowych będą natomiast zależeć od tego, czy mamy do czynienia z regularnym zespołem, czy grupą niezależnych specjalistów skupionych wokół realizacji jednego celu. Ważne, by prowadziły do coraz płynniejszego przepływu prac pomiędzy osobami i szybszego dostarczania klientowi tego, co stanowi dla niego największą wartość. A z jakimi limitami zacząć pracować? Paweł Brodziński proponuje, żeby rozpoczynać projekty z limitami, które na oko wydają się rozsądne – np. 1 zadanie na osobę plus jedno dodatkowe dla większej elastyczności, a z czasem dostosowywać je do realnych potrzeb zespołu. Podczas szkolenia z Davidem Andersonem, na pytanie jednego z uczestników, jak dostosować limity w projekcie, który trwa, albo zespole, który pracuje już od jakiegoś czasu, zasugerował, żeby zacząć z tym, co jest – dostosować limit do aktualnej pracy zespołu. W kolejnych krokach analizować pracę i stopniowo zmniejszać limity, doprowadzając do bardziej dynamicznego i regularnego procesu.

Limitowanie pracy w toku to nie tylko limity wypisane na tablicy. Widziałam zespoły “Kanbanowe”, które stosowały limity na tablicy, ale nie ograniczały pracy w toku. Kiedy bliżej się im przyjrzeć, okazywało się, że tablica wygląda modelowo, a na boku pęczniała lista zadań realizowanych w szarej strefie. To efekt siły przyzwyczajenia i buntu wobec robienia rzeczy uważanych za bezsensowne. Nic w tym dziwnego. Nawet jeśli taki zespół pracuje z czasem efektywniej, nasuwa się pytanie, czy można nazwać to sukcesem. Moim zdaniem nie, bo to zmiana zbudowana na słabych fundamentach. Dlatego szczerze odradzam wprowadzanie limitów jako mechaniki pracy bez głębszego przedyskutowania z zespołem szerszego kontekstu, z czego wynikają i po co są. Jako rozwinięcie tematu polecam artykuł Håkan Forssa dotyczący etapów wprowadzania Kanbana do organizacji oraz materiały dostępne na stronie Limited WIP Society.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x