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 maksymalizację empiryzmu, podczas gdy Kanban skupiony jest przede wszystkim na optymalizacji przepływu wymagań przez proces developmentu. Scrum jest dobrym wyborem, gdy szukamy najlepszego rozwiązania problemów biznesowych i końcowy rezultat jest mało precyzyjnie określony. Kanban może być efektywniejszy wtedy, gdy dość dobrze znamy cele i sposób, w jaki chcemy je osiągnąć, a chcemy 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 i proces jego wytwarzania w taki sposób, by najczęściej jak to możliwe dokonywać oceny tego, jakie skutki przyniosły poczynione zmiany i decyzje. 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. W systemie Kanban podobny efekt można uzyskać na wiele sposobów, na przykład oceniając rozwiązanie dla każdego wymagania zaraz po jego zrealizowaniu.

Jeśli zechcemy zachować empiryzm na tym samym poziomie, wtedy Scrum i Kanban będzie równie kosztowny i powolny, ponieważ to, co Scrum formalizuje jako zdarzenia opisane w metodzie, w 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 planując Sprint, szacuje się, 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 zadania są „wciągane” do procesu przez cały czas, ale tylko do momentu wysycenia się możliwości Zespołu do ich realizowania. Jeśli wprowadzone zostaną realistyczne limity wymagań, nad którymi Zespół pracuje jednocześnie, efektywność 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 oprogramowania charakteryzował się będzie niskim empiryzmem lub w ogóle przestanie być empiryczny.

Co więcej, skoro system Kanban opiera się na idei limitowania ilości pracy wykonywanej przez Zespół równolegle, 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 uciekał.

Te same problemy, różne objawy

Co ciekawe, w systemie Kanban problem „nie mogę zacząć kolejnego zadania” objawia się nieco inaczej. O ile w Scrumie czekamy wtedy cierpliwie na początek następnego Sprintu, o tyle w Kanbanie czeka się na skończenie jakiegoś innego zadania (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ównoległej pracy.

Warto w takim przypadku zadać sobie pytanie: z czego wynika ta niemożność zaczęcia czegokolwiek późno w czasie Sprintu? 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ły procedury budowania i integracji (więc można je zoptymalizować) etc. 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 per-Sprint 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, w który praca jest wciągana (ang. pull) dopiero wtedy, gdy istnieją realne możliwości jej realizacji. 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 (a tak naprawdę frameworku, czyli ram procesowych) opartego o podejście zwinne.

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.