Pierwszą część opowieści o ograniczeniu prac w oku zakończyłem pytaniem: jak określić poziom CONWIP (Constant WIP) dla całego procesu, opisanego na tablicy Kanban, obejmującego kilka faz? Teraz czas na odpowiedzi.
Jak określić poziom CONWIP
CONWIP można określić - na tablicy Kanban, jak pokazuje rysunek obok - na przykład biorąc za podstawę liczbę członków zespołu i zwiększając ją – na początek - o 50%. Zobaczyć jakie są efekty tego podejścia: czy to raczej członkowie zespołu czekają na zadania, czy może zadania czekają na członków zespołu, i odpowiednio modyfikować poziom CONWIP.
Inna wskazówka dotycząca poziomu CONWIP mówi, że może on wynosić od 50 – 200% liczby członków zespołu.
Poziom CONWIP zależy przede wszystkim od przyjętego celu. Chcemy zwiększyć współpracę, promować pracę parami i wymianę wiedzy? To wprowadźmy bardziej restrykcyjny – czyli mniejszy – CONWIP. Nasze cele są nieco inne? To i poziom CONWIP będzie inny.
W tym kontekście CONWIP można też uzupełnić limitem WIP dla wybranych faz procesu lub nawet dla faz i wierszy tablicy Kanban, czyli dla członka zespołu.
W takiej sytuacji rodzi się praktyczne pytanie: który WIP limit ma priorytet: CONWIP, czy limit dla fazy procesu. Inaczej mówiąc: który limit nie może (lub nie powinien być naruszony), a który może i dlaczego?
Znalezienie odpowiedzi na to pytanie pozostawię czytelnikowi, jako swego rodzaju „rozkosze łamania głowy”.
Jednostki dla limitów WIP
Inny istotny aspekt kontekstu ograniczania prac w toku dotyczy jednostek w jakich mierzymy te limity: czy są to po prostu „sztuki” zadań, czy coś innego, na przykład story pointy lub inna jednostka pracochłonności prac.
„Sztuki” zadań są OK, gdy zadania są generalnie podobnej wielkości. Lecz, gdy ich wielkość różni się warto jako jednostki użyć pracochłonności wyrażonej np. w punktach.
Weźmy przykład symulacji.
Jak w prosty sposób można poznać, zrozumieć i przećwiczyć powyższe podejścia do ograniczania poziomu prac w toku oraz stosowane jednostki dla limitów WIP?
Odpowiedź jest prosta: biorąc udział w grze symulacyjnej TeamFlow, a precyzyjniej mówiąc w rożnych wariantach tej gry.
Symulacja TeamFlow Foundation lub Plus realizowana jest w kontekście zespołu cross-funkcjonalnego, czyli takiego, którego członkowie mają kompetencje pozwalające na realizację obu faz procesu. W tym więc kontekście stosowana metoda ograniczania prac w toku to CONWIP, ewentualnie uzupełniona o limit prac w toku na poszczególne fazy lub wybraną fazę. W tych wariantach symulacji zadania trwają jeden dzień, więc jednostką stosowaną do określania poziomu limitu WIP są po prostu „sztuki” zadań.
Symulacja TeamFlow Professional, nieco bardziej złożona niż warianty Foundation lub Plus, realizowana jest w kontekście procesu obejmującego dwie specjalistyczne fazy, a więc i zespołu składającego się z dwóch podzespołów specjalistów pracujących w fazach: projektowanie i wytwarzanie. Oznacza to, że członkowie zespołu – na początku - mają tylko kompetencje pozwalające na realizację konkretnej, jednej fazy procesu. W tym więc kontekście konieczna jest identyfikacja ograniczenia, którym jest jedna z dwóch faz. Oraz określenie limitu prac w toku dla fazy będącej ograniczeniem, a następnie określenie limitu WIP drugiej fazy, czyli jej podporządkowanie (mówiąc językiem TOC) ograniczeniu. W tej symulacji stosowana metoda ograniczania prac w toku to limit prac w toku na poszczególne fazy procesu. W tym wariancie symulacji pracochłonność zadań w poszczególnych fazach jest różna, dla niektórych zadań nawet bardzo różna. Dlatego też jednostką stosowaną do określania poziomu limitu WIP są punkty, na które „przeliczana” jest ich pracochłonność.
Podsumowanie
Przedstawiłem w tym tekście podejście do ograniczania prac w toku na poziomie zespołu dla dwóch kontekstów: zespołu cross-funkcjonalnego i procesu bez ograniczenia oraz procesu w którym występują fazy oraz ograniczenie, a zespół stanowią pod-zespoły specjalistów. I pewnie zastanawiacie się: co dalej? Czy może ograniczenie poziomu prac w toku można przenieść na poziom projektu i/lub portfela projektów?
Odpowiem: Wasze intuicje są bardzo celne. Faktycznie ograniczenie poziomu prac w toku można stosować także na poziomie projektu i/lub portfela projektów. Jak? To – jak mawiał R. Kipling „jest zupełnie odrębna historia”, którą opowiem w odrębnym tekście.