Stała długość Sprintu w Scrumie i związany z tym cykl spotkań często postrzegany jest przez Zespoły jako narzut procesowy, spowalniający lub ograniczający możliwości Zespołu. Zdarzało mi się słyszeć sugestię, że migracja do Kanbana pozwoli zrobić więcej w tym samym czasie, bo nie będzie trzeba przerywać pracy tylko po to, by podsumować kończący się Sprint i zaplanować kolejny. Zdarzało mi się też dostawać zapytanie, czy aby rozsądne jest restrykcyjne podejście do granic Sprintów, skoro powoduje, że często nie można zacząć realizacji żadnego nowego wymagania, jeśli zostało za mało czasu na jego skończenie w bieżącej iteracji.

Którą metodę wybrać?

Zawsze odpowiadam, że Scrum nastawiony jest na wykorzystanie empiryzmu, podczas gdy Kanban skupiony jest na optymalizacji przepływu wymagań przez proces. Scrum jest dobrym wyborem, gdy szukamy najlepszego rozwiązania problemów biznesowych i końcowy rezultat jest mało precyzyjnie określony. Kanban nałożony na jakiś autorski proces (różny od Scruma) może być faktycznie efektywniejszy, pod warunkiem, że dobrze znamy cele i sposób, w jaki chcemy je osiągnąć i staramy się to zrobić jak najszybciej. W szczególności Kanban dużo lepiej niż Scrum nadaje się do realizacji ściśle zdefiniowanych wymagań, na które mamy mały lub ograniczony wpływ, na przykład do prac utrzymaniowych i rozwiązywania błędów.

Zapewnianie empiryzmu

Podejście empiryczne, o którym piszę, to rozwój produktu w taki sposób, by najczęściej jak to możliwe dokonywać oceny tego, jakie skutki przyniosły poczynione w nim zmiany. W istocie każdy Sprint w Scrumie jest eksperymentem: realizujemy wymagania będące zapisem hipotezy o sensowności i opłacalności konkretnego rozwiązania (zmiany, nowej funkcjonalności etc.), a następnie dokonujemy oceny tego, co udało się osiągnąć i planujemy kolejny Sprint-eksperyment.

Oczywiście przy pewnym wysiłku i dużej dozie dyscypliny podobny efekt można uzyskać na wiele sposobów, na przykład oceniając rozwiązanie dla każdego wymagania zaraz po jego zrealizowaniu. Sprinty (iteracyjna praca) nie są bezwzględnym warunkiem odniesienia sukcesu, ale pozwalają redukować ryzyko brnięcia zbyt długo w złą stronę.

Jeśli zechcemy użyć empiryzmu do rozwoju produktu, posługując się do tego Kanbanem w połączeniu z jakimś samodzielnie zdefiniowanym procesem, wymagać to będzie wysiłku porównywalnego ze Scrumem, a może okazać się trudniejsze. To, co Scrum formalizuje jako zdarzenia opisane w metodzie, w tak zastosowanym Kanbanie trzeba zorganizować w adekwatnej, samodzielnie zdefiniowanej formie. Co więcej, Kanban wymagał będzie większej dojrzałości od organizacji i Developerów, ponieważ nie wymusza kadencyjności działań, przez co empiryzm zależy mocniej od determinacji i konsekwencji zaangażowanych osób.

Mit: stała długość Sprintu ogranicza produktywność

Wróćmy zatem do problemu niemożności zaczęcia prac nad wymaganiem tuż przed końcem Sprintu. Kanban pozornie jest odpowiedzią na to „ograniczenie Scruma”, bo pozwala planować w systemie ciągłym i realizować zadania dowolnie długo. Ta swoboda jest jednak pozorna i wynika najczęściej z niezrozumienia tego, jak system Kanban działa.

O ile w Scrumie szacuje się w trakcie Planowania Sprintu, co jest możliwe do osiągnięcia przed jego końcem (i wiadomo dokładnie, ile czasu na tę iterację przeznaczamy), o tyle w systemie Kanban rzeczy do zrobienia są wciągane do procesu przez cały czas, ale tylko do momentu wysycenia możliwości Zespołu, aby je realizować. Jeśli wprowadzone zostaną realistyczne limity ilości takiej równolegle wykonywanej pracy, efektywność Zespołu okaże się taka sama, jak w Scrumie. Inaczej mówiąc, w tym samym czasie wcale nie uda się zrobić więcej.

A co począć, jeśli krótki Sprint uniemożliwia zrealizowanie naprawdę dużych wymagań? Kanban pozwala, przynajmniej teoretycznie, na realizację dowolnie rozbudowanych wymagań przez nieograniczony czas. Należy jednak pamiętać, że taki proces wytwarzania produktów charakteryzował się będzie niskim empiryzmem lub w ogóle przestanie być empiryczny (bo za rzadko dokonywać się będzie w nim sprawdzenia efektów podejmowanych działań).

Co więcej, skoro system Kanban opiera się na idei limitowania ilości pracy wykonywanej przez Zespół jednocześnie, długotrwała realizacja jednego wymagania ograniczy produktywność Zespołu (o ile przyjęte limity będą przestrzegane)., bo w nieskończoność będą realizowane te wymagania, nad którymi prace już się rozpoczęły, bez możliwości podjęcia kolejnych. Aby usprawnić przepływ wymagań przez proces developmentu, Zespół i tak zacznie dzielić je na mniejsze elementy dające się szybciej realizować. I, przede wszystkim, zacznie je szybciej kończyć, zapewne w czasie co najwyżej tak długim, jak Sprinty, od których przecież uciekał. A to oznacza, że równie dobrze mógłby tych Sprintów nadal używać.

Te same problemy, różne objawy

Co ciekawe, mimo braku Sprintów, w systemie Kanban również zdarzyć się może, że ze względu na obowiązujące zasady nie można od razu rozpocząć pracy nad kolejnym problemem. O ile w Scrumie czekamy wtedy cierpliwie na początek następnego Sprintu, o tyle w Kanbanie czeka się na skończenie jakiegoś innego wymagania (bo Kanban nie pozwala zacząć dowolnej ich ilości). Czasem mniej to doskwiera, bo występuje w losowych momentach (a w Scrumie z reguły pod koniec Sprintu), natomiast skala problemu w tym samym Zespole będzie taka sama niezależnie od metody. Co więcej, Scrum uczyni ten problem dobrze widocznym, podczas gdy w Kanbanie można źle zdefiniować limity i długo nie mieć świadomości, że Zespół dławi się nadmiarem równolegle wykonywanej pracy.

Warto w takim przypadku zadać sobie pytanie: z czego wynika ta niemożność zaczęcia czegokolwiek późno w czasie Sprintu? Czy na pewno powodem jest „ograniczająca koncepcja pracy w iteracjach”? Cóż, nie. Rychło okaże się, że wymagania są za duże (więc można je podzielić), że dałoby się je zrobić, gdyby efektywniej działał development (więc można go udoskonalić) itd. W praktyce naprawdę dojrzały Zespół dojdzie do momentu, gdzie usunięcie granic Sprintów i przejście ze Scruma na system Kanban może odbyć się niezauważalnie, bo jedyną zmianą będzie odejście od planowania Sprintów na ich początku na rzecz planowania just-in-time.

A wy wolicie Scruma czy Kanban? Jakiej metody używacie i co zdeterminowało jej wybór?

Czym jest system Kanban?

Po ponad sześciu latach od opublikowania tego artykułu, podczas porządkowania od strony językowej i formatowania starszych tekstów, zorientowałem się, że określenie system Kanban może być niezrozumiałe. Jaki znów system? Kanban, po prostu! No, niezupełnie.

Wystarczy sięgnąć po Kanban Guide, aby dowiedzieć się, że Kanban jest strategią optymalizacji przepływu wartości poprzez proces jej wytwarzania, opartą o wizualny system typu pull (tu już pojawia się słówko system). Strategia ta obejmuje trzy praktyki:

  • definiowanie i wizualizację workflowu,
  • aktywne zarządzanie jednostkami pracy w toku,
  • udoskonalanie workflowu.

I to właśnie implementacja powyższych praktyk kanbanowych nosi nazwę systemu Kabnan. Systemu typu pull, jak już pisałem wcześniej, czyli takiego, do którego praca jest wciągana (ang. pull) dopiero wtedy, gdy istnieją realne możliwości jej rozpoczęcia. Kanban jest więc w istocie strategią działania, ale nie konkretnym procesem, w którym strategia ta jest używana. Systemem Kanban jest dopiero taki konkretny proces.

Nadal jest to niejasne? To może łatwiej będzie użyć analogii do Agile i Scruma: Agile to podejście, a Scrum użyty w konkretnym Zespole jest systemem Agile, czyli implementacją procesu empirycznego w tym Zespole.

Tę językową konfuzję podnosi dodatkowo fakt, że większość osób, w tym i ja, posługuje się nazwą Kanban zarówno wtedy, gdy mówi o samym podejściu, jak i jej implementacji w konkretnym procesie. Dlatego uznałem za zasadne wyjaśnienie, do czego odnosi się tytuł artykułu i wspomniany kilkakrotnie system.

A jako ciekawostkę dodam na koniec, że Scrum, który jest systemem Agile, może też być jednocześnie systemem Kanban, jeśli Zespół Scrum wdroży w swojej pracy praktyki kanbanowe i użyje ich do optymalizacji przepływu.