Scrum vs. System Kanban

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 przejście do Systemu Kanban 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 sprintu, skoro powoduje, że często nie można zacząć realizacji żadnego nowego wymagania, bo zostało za mało czasu na jego skończenie w sprincie.

Którą metodę wybrać?

Zawsze odpowiadam, że Scrum nastawiony jest na maksymalizację empiryzmu, podczas gdy System 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. System Kanban może być efektywniejszy wtedy, gdy dość dobrze znamy cele i metodę, jaką chcemy je osiągnąć i chcemy to zrobić jak najszybciej. W szczególności System Kanban idealnie 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 procesu 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 System Kanban będzie równie kosztowny i powolny, ponieważ to, co Scrum formalizuje jako zdarzenia opisane w metodzie, w Systemie Kanban trzeba zorganizować w adekwatnej (choć nieopisanej metodą) formie. Co więcej, System Kanban wymagał będzie większej dojrzałości od organizacji i zespołów developerskich, 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. System 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 to 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ń”? System 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). Aby usprawnić przepływ wymagań przez proces developmentu zespół i tak zacznie dzielić je na mniejsze elementy dające się szybciej realizować.

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 cierpliwie na początek następnego sprintu, o tyle w Systemie Kanban czeka się na zwolnienie limitu (a więc na skończenie jakiegoś innego zadania). 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 Systemie Kanban 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 są źle wyestymowane (więc można je jeszcze raz przeszacować), że dałoby się je zrobić gdyby efektywniej działały procedury buildu i integracji (więc można je zoptymalizować) etc. W praktyce naprawdę dojrzały zespół dojdzie do momentu, gdzie „wyciągnięcie” granic sprintu 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 System Kanban? Jakiej metody używacie i co zdeterminowało jej wybór?