Podstawowe miary w Kanbanie

Podstawowe miary w KanbanieMetryki pomagają podejmować decyzje oraz zrozumieć faktyczny przepływ (flow) prac w zespole i organizacji. Są punktem odniesienia, kiedy chcemy sprawdzić, na ile eksperymenty w zespole, czy próby usprawnień, przekładają się na lepsze efekty. Lead Time, Cycle Time oraz Throughput to podstawowe miary w Kanbanie. Czym są i jak z nich korzystać tak, aby pomagały doskonalić sposób pracy.

Lead Time i Cycle Time

Zarówno Lead Time, jak i Cycle Time są miarami jednostki czasu, ale dotyczą innych aspektów procesu. Lead Time to średni czas mierzony od momentu powstania zadania do jego dostarczenia (delivery). Cycle Time to natomiast średni czas spędzony na wykonaniu zadania – rozpoczyna się w chwili jego podjęcia, a kończy, kiedy zadanie osiąga status “Done”. 

Przykład:

  • 10 sierpnia do Backloga zespołu trafia zadanie, dotyczące problemu z korzystaniem z usługi, za którą odpowiada ten zespół,
  • 16 sierpnia zespół rozpoczyna pracę nad zadaniem,
  • 18 sierpnia poprawka zostaje wdrożona na produkcję.

A jak wyglądają interesujące nas miary?

Cycle Time, czyli proces usuwania błędu – przeanalizowanie problemu, development, testy, code review oraz wdrożenie: 2 dni.

Lead Time, czyli faktyczny czas, jaki upłynął, od momentu, kiedy zadanie trafiło do backlogu, do wdrożenia poprawki: 8 dni.

Im mniejsza różnica pomiędzy tymi miarami, tym lepiej, ponieważ to oznacza krótszy czas oczekiwania przez klienta. W tym przypadku 6 dni, w czasie których zadanie oczekiwało w kolejce, to typowa strata (tzw. waste) z perspektywy lean management, z jakiego wywodzi się Kanban.

Jak widzicie, Lead Time skupia się na aspekcie doświadczenia klienta, a Cycle Time na możliwościach procesu.

Relację pomiędzy miarami wyraża tzw. Little’s law:

Lead Time = Cycle Time x WIP (Work In Progress)

Little’s Law, wywodzące się, podobnie jak Kanban, z przemysłu fabrycznego, sprawdza się w stabilnych systemach (funkcjonujących przez dłuższy czas w powtarzalny sposób). W kontekście pracy zespołu będziemy mieli z tym pewną trudność, ale załóżmy, że mój zespół od tygodni pracuje w podobnych warunkach – bez zmian osobowych, zajmując się podobnego typu zadaniami. Jeśli, jak w przykładzie wyżej, średni Cycle Time zadań wynosiłby 2 dni, Lead Time 8 dni, a WIP 4, to przy zwiększeniu ilości zadań realizowanych jednocześnie – z 4 do 6 nasz Lead Time zmienia się w czasie tak:

Lead Time = 2 x 4WIP = 8dni

Lead Time przy zwiększonym WIP = 2 x 6WIP = 12dni

Większa liczba zadań, nad którymi w danym czasie pracuje zespół (Work In Progress), wydłuża czas oczekiwania klienta. Biorąc pod uwagę, że w realnych warunkach pracy zwiększenie ilości zadań otwartych wydłuża jednocześnie ich Cycle Time, mielibyśmy do czynienia z poważnym spadkiem efektywności zespołu. 

Możecie spotkać się z innym rozumieniem Lead Time oraz Cycle Time od zaproponowanego przeze mnie w tym wpisie. Część osób zaczyna liczyć Lead Time od momentu podjęcia zadania, traktując je jako deklarację wykonania (na przykład od momentu przeniesienia zadania do kolumny “To do” na tablicy Kanbanowej). Zdarzyło mi się słyszeć argument, że sama obecność zadania w Backlogu niekoniecznie oznacza, że faktycznie zostanie wykonane. Może się to sprawdzać w przypadku backlogów produktowych, w których znajdują się również zadania-pomysły niezlecone bezpośrednio przez klienta zewnętrznego i nie do końca wiadomo, czy zostaną wykonane. Osobiście podpisuję się pod propozycją Davida Andersona (spopularyzował Kanbana w firmach technologicznych), który zachęca, aby w takiej sytuacji stworzyć „Wish listę”, a do backloga przenosić wyłącznie zadania, nad jakimi faktycznie chcemy pracować.

Również Cycle Time bywa definiowany inaczej – jako czas spędzony na wykonaniu pojedynczego kroku w procesie. W przypadku developmentu, moglibyśmy mówić np. o krokach: development, testy, review. Takie podejście jest wartościowe w sytuacji, kiedy będziemy chcieli przyjrzeć się poszczególnym krokom procesu – np. rozpoznać, ile czasu zadania oczekują na review (kolumna “Review” na tablicy Kanbanowej) albo są zblokowane przez zewnętrzne zależności (kolumna “Blocked”). Uważam, że w tym podejściu równie ważne jest, aby patrzeć na Cycle Time także całościowo – jako na sumę Cycle Time dla poszczególnych kroków, co jest spójne z podejściem opisanym przeze mnie.

Throughput

Dla odmiany miara Throughput jest ilościowa. Pokazuje, liczbę zadań zrealizowanych przez zespół w danym okresie.

Dzienny TP dla zespołu, który realizuje średnio 10 zadań w tygodniu (5 dni) będzie wynosił 2.

Ta miara mówi wprost o mocach przerobowych zespołu. Jeśli Throughput nie zmienia się w czasie, zespół jest przewidywalny, co wcale nie musi oznaczać, że osiągnął szczyt swoich możliwości. Dla zespołu, który chce usprawnić swój sposób pracy, celem jest zwiększenie Throughputu oraz zmniejszenie Cycle Time. Jaki okres czasu jest najlepszy w kontekście analizowania TP? – dzienny, tygodniowy, miesięczny? To zależy od kontekstu, specyfiki pracy, czy oczekiwań klientów. W przypadku zespołu z mojego przykładu, który jest w stanie zrealizować zadanie w 2 dni (Cycle Time), będzie mnie interesował dzienny i tygodniowy TP, ponieważ pokaże mi flow (przepływ) i dynamikę pracy. Relację pomiędzy Lead Time a Throughput wyraża inna wersja Little’s Law:

WIP = Lead Time x Throughput

Jaki jest jest zatem TP zespołu z mojego przykładu?

4WIP = 8 dni x TP

0,5 czyli 2,5 zadania per tydzień.

Pokazałam Little’s Law, korzystając z przykładowych danych, uważam natomiast, że największa wartość płynie z uświadomienia sobie bezpośrednich relacji pomiędzy miarami. Zarówno czas oczekiwania klienta (Lead Time), faktyczny czas spędzony na realizacji zadania (Cycle Time), jak ilość zadań dostarczanych przez zespół w określonym przedziale czasu (Throughput), są zależne od średniej ilości zadań, nad jakimi w danym czasie pracuje zespół (WIP – Work In Progress). Ta relacja wyraźnie pokazuje, że jeśli zależy nam na optymalizacji pracy zespołu, należy zwrócić szczególną uwagę na to, nad iloma zadaniami pracuje jednocześnie zespół. Jeśli interesuje Was, jak to zrobić, polecam mój wcześniejszy wpis, poświęcony tematowi limitowania pracy w toku.

Narzędziem, które pomaga w analizie wpływu WIP na efekty pracy zespołu jest Cumulative Flow Diagram – skumulowany wykres, pokazujący, jak z czasem zmienia się suma zadań, które zostały przeniesione przez poszczególne statusy tablicy Kanbanowej.

Wykres poniżej pokazuje, jak zwiększony WIP, zmniejszył ilość zadań zrealizowanych – Done.

Jeśli zainteresował Was temat interpretacji Cumulative Flow Diagram, koniecznie zajrzyjcie do artykułu Pawła Brodzińskiego. Paweł prezentuje w nim różne przykłady wykresów wraz z krótkim opisem, co można z nich wyczytać na temat pracy zespołu.

Metryki same w sobie nic nie wnoszą i niczego nie zmieniają. Dodatkowo, jeśli ich przygotowanie wymaga wysiłku i zaangażowania osób, można je sklasyfikować jako klasyczny waste – stratę czasu. Miary, wykresy, wizualizacja pracy to jedynie narzędzia, które pomagają nam zrozumieć, jak sposób naszej pracy przekłada się na efekty. Dopiero dyskutowanie o nich, interpretowanie, eksperymentowanie – podejmowanie konkretnych działań na ich podstawie, a następnie sprawdzanie, jak te działania wpływają na zmianę metryk w czasie, przynosi realną wartość. 

Jeśli do tej pory w Waszej codziennej pracy nie bazowaliście na miarach, zachęcam Was do spojrzenia na Waszą pracę właśnie z perspektywy danych. Być może liczby potwierdzą Wasze przeczucia, a może wniosą zupełnie nowy wymiar do dyskusji o tym, jak pracujecie i w jakich obszarach warto wprowadzić zmiany. Jeśli korzystacie z elektronicznych narzędzi typu Jira, sprawdźcie, jak Waszą pracę pokażą automatyczne raporty.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

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