Czy kiedykolwiek widziałeś zespół Scrumowy, który z dumą prezentuje swoją tablicę Kanban z dziesiątkami kolumn i karteczkami wędrującymi od osoby do osoby? Ja widziałem. I za każdym razem czuję, jakbym obserwował powolną katastrofę – coś, co nazywam „Kanbanosis Acute”. To jak oglądanie kogoś, kto próbuje jeździć rowerem, jednocześnie grając na akordeonie – teoretycznie możliwe, ale po co się tak męczyć?
Tech Lead: „Obawiam się, że masz Kanbanosis Acute – ostrą odmianę kanbanozy.”
Junior Dev: „Czy to poważne?”
Tech Lead: „Zacząłeś organizować swoje testy jednostkowe, zamówienia kawy i emocje w kolumny Do Zrobienia, W Trakcie i Zrobione.”
Łączenie Kanbana ze Scrumem to jeden z tych pomysłów, które na pierwszy rzut oka wydają się sensowne. W końcu oba podejścia należą do rodziny Agile, prawda? Problem w tym, że często prowadzi to do więcej zamieszania niż korzyści, a w skrajnych przypadkach może być jednym z powodów upadku zespołów Scrumowych i odwrotu od Agile w organizacjach.
Dlaczego Kanban i Scrum to toksyczne małżeństwo?
Scrum ze swojego założenia został stworzony do dostarczania wartości przy rozwiązywaniu skomplikowanych i złożonych problemów. Kanban na odwrót – do prostych i powtarzalnych zadań.
Sprint vs Flow – fundamentalny konflikt
Scrum opiera się na sprintach, które z założenia zaczynają się „na czysto” (żadna praca nie jest w toku) i kończą się „na czysto” (wszystko zaplanowane jest wykonane). To jak przygotowywanie posiłków na cały tydzień w niedzielę – czysta lodówka na początku, pełna pojemników z jedzeniem na koniec.
Tymczasem Kanban to ciągły przepływ, gdzie zadania płyną przez system jak woda przez rurę. Kiedy próbujemy wtłoczyć flow Kanbana w ramy sprintów, tracimy główną zaletę Kanbana – możliwość mierzenia stałości przepływu. To jak próba mierzenia przepływu rzeki, ale tylko w określonych tygodniach roku – dane będą niekompletne i mało użyteczne.
Stabilizacja flow kosztem inspekcji i adaptacji
Chęć ustabilizowania przepływu w Kanbanie często prowadzi zespoły do wydłużania sprintów. „Hej, może zróbmy trzytygodniowe sprinty zamiast dwutygodniowych, żeby lepiej zarządzać flow?” – słyszałem to wielokrotnie. Problem w tym, że dłuższe sprinty oznaczają rzadsze okazje do inspekcji i adaptacji – fundamentalnych elementów Scruma.
To jak rzadsze wizyty u lekarza – możesz się czuć lepiej, bo rzadziej słyszysz złe wieści, ale nie oznacza to, że jesteś zdrowszy.
Zespół jako jednostka vs indywidualne kolumny
W Scrumie zespół powinien być traktowany jako jedna osoba ze wspólną odpowiedzialnością. Wszyscy razem wygrywają lub przegrywają. Tymczasem Kanban, szczególnie w tradycyjnym wydaniu, zachęca do tworzenia kolumn odpowiadających różnym etapom pracy, często przypisanym do konkretnych osób lub ról.
„Analiza”, „Rozwój”, „Testy”, „Wdrożenie” – każda kolumna to potencjalne silos, a zadania są przekazywane między nimi jak gorący kartofel. Handover pracy w kontekście jednego zespołu po prostu nie ma sensu – to jak podawanie sobie piłki między lewą a prawą ręką.
Specjalizacja vs cross-funkcjonalność
Budowanie kolumn i przypisywanie do nich osób utrudnia współdziałanie całego zespołu. Gdy mamy kolumnę „Testy” przypisaną do testerów, programiści naturalnie skupiają się tylko na kolumnie „Rozwój”. To prowadzi do specjalizacji, która jest przeciwieństwem cross-funkcjonalności, do której dążymy w Scrumie.
To jak mieć w domu osobę odpowiedzialną wyłącznie za odkurzanie, a inną tylko za mycie naczyń. Może i są ekspertami w swoich wąskich dziedzinach, ale co się stanie, gdy jedna z nich zachoruje?
Najczęstsze błędy przy stosowaniu Kanbana w Scrumie:
Zbyt wiele kolumn
Najprostszy i najczęstszy błąd: tworzenie zbyt wielu kolumn. Widziałem tablice z kolumnami takimi jak „Do zrobienia”, „Analiza”, „Projektowanie”, „Rozwój”, „Code Review”, „Testy”, „Dokumentacja”, „Wdrożenie”, „Zrobione”. To nie tablica Kanban, to mapa metra!
W większości przypadków wystarczą trzy kolumny: „Do zrobienia”, „W trakcie”, „Zrobione”. Wszystko ponad to często wprowadza sztuczne podziały i zachęca do przekazywania pracy zamiast współpracy.
Obsesja na punkcie mierników przepływu
Kanban oferuje wiele mierników: lead time, cycle time, throughput… Zespoły często skupiają się na tych miernikach kosztem tego, co naprawdę ważne – dostarczania wartości[3].
„Nasz cycle time spadł o 15%!” – świetnie, ale czy klienci są zadowoleni z produktu? Czy rozwiązujemy właściwe problemy? Mierniki są jak termometr – przydatne do diagnozy, ale same w sobie nie leczą choroby.
Push zamiast pull
W prawdziwym Kanbanie zadania są „ciągnięte” (pull) przez system, a nie „pchane” (push). Jednak w praktyce często widzę, jak programiści kończą swoje zadanie i natychmiast przesuwają je do kolumny „Testy”, nawet jeśli testerzy są już przeciążeni pracą.
To jak wrzucanie kolejnych naczyń do zlewu, mimo że jest już pełny – zamiast pomóc w zmywaniu. Prawdziwy Kanban wymaga dyscypliny i szacunku dla limitów pracy w toku (WIP), które często są ignorowane.
Kiedy nie stosować Kanbana
Zadania skomplikowane
Kanban świetnie sprawdza się w przewidywalnych, powtarzalnych procesach. Pisanie oprogramowania rzadko takie jest. Każde zadanie może napotkać nieoczekiwane problemy, wymagać głębszego zrozumienia lub zmiany podejścia w trakcie realizacji.
To jak stosowanie przepisu kulinarnego do eksperymentowania z nowymi potrawami – możesz mieć listę składników i kroków, ale prawdziwa magia dzieje się, gdy odchodzisz od przepisu i improwizujesz.
Zadania wymagające współpracy wielu specjalności
Jeśli twój zespół nie składa się wyłącznie z „pełnych stacków” (100% fullstack-QA-SEC-OPS), Kanban może prowadzić do silosów i opóźnień w handoverach. Współczesne wytwarzanie oprogramowania wymaga ścisłej współpracy między różnymi specjalnościami, a nie sekwencyjnego przekazywania pracy.
Realizacja celów zamiast zadań
User Stories, Epics i Features to nie są zadania, to cele użytkownika. Kanban jest świetny do zarządzania zadaniami, ale nie celami. Kiedy próbujemy wtłoczyć cele użytkownika w ramy Kanbana, często tracimy z oczu prawdziwy cel – dostarczanie wartości.
Kiedy warto stosować Kanban
Powtarzalne zadania
Kanban narodził się w fabrykach Toyoty, gdzie procesy są powtarzalne i przewidywalne. Świetnie sprawdza się w obsłudze serwisowej, produkcji przemysłowej czy innych scenariuszach, gdzie zadania są podobne i dobrze zrozumiane.
Proste zadania w dużej ilości
Jeśli masz do wykonania setki prostych, podobnych zadań (jak obracanie monety czy składanie pudełek 😉 ), Kanban może pomóc w zarządzaniu przepływem i identyfikacji wąskich gardeł.
Zadania wykonywalne przez każdego członka zespołu
Kanban działa najlepiej, gdy każde zadanie może być podjęte przez dowolną osobę w zespole. W przeciwnym razie powstają wąskie gardła i zadania czekają na konkretne osoby, co niweluje korzyści z płynnego przepływu.
Suma zgodności z powyższymi kryteriami
Kanban warto stosować tylko wtedy, gdy 100% wykonywanych zadań spełnia powyższe kryteria. W przeciwnym razie ryzykujemy stworzenie systemu, który działa dobrze dla części pracy, ale utrudnia realizację pozostałej.
Dodatkowe powody, by unikać Kanbana w Scrumie
Rozmycie odpowiedzialności zespołowej
Kanban może prowadzić do myślenia „to nie moje zadanie”, gdzie każdy odpowiada tylko za swoją kolumnę. To podważa fundamentalną zasadę Scruma o wspólnej odpowiedzialności zespołu za dostarczenie wartości.
Utrata przejrzystości sprintów
Sprinty w Scrumie dają jasną ramę czasową i zakres pracy, co ułatwia planowanie i zarządzanie oczekiwaniami. Dbanie o flow powoduje przenoszenie pomiędzy sprintami i nakładanie koncowych etapów na początek kolejnego sprintu. To z kolei rozwala przewidywalność zespołu i może powoli degradować zaufanie biznesu do developmentu.
Jak uniknąć Kanbanosis Acute?
Najlepiej… nie wprowadzaj Kanbana. a jeśli już musisz używać elementów Kanbana w Scrumie, oto kilka wskazówek:
- Utrzymuj prostotę tablicy – trzy kolumny to często wszystko, czego potrzebujesz.
- Zachowaj współpracę zespołową – unikaj przypisywania kolumn do konkretnych osób.
- Szanuj limity WIP – to fundamentalna zasada Kanbana, bez której traci on sens.
- Nie rezygnuj z ceremonii Scruma – Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective są nadal kluczowe.
- Pamiętaj o celu – dostarczanie wartości jest ważniejsze niż piękne wykresy przepływu.
Podsumowanie
Jestem wielkim fanem Kanbana – naprawdę! To potężne narzędzie, które zrewolucjonizowało produkcję przemysłową i może być niezwykle skuteczne w odpowiednich kontekstach. Jednak przy wytwarzaniu oprogramowania w podejściu Agile, gdzie wymagana jest współpraca, a nie handover, Kanban często wprowadza więcej problemów niż rozwiązań.
Zamiast ślepo łączyć Kanban ze Scrumem, zastanów się, co naprawdę chcesz osiągnąć. Jeśli twoim celem jest lepsza wizualizacja pracy, może wystarczy prosta tablica z trzema kolumnami. Jeśli chcesz poprawić przepływ, może warto skupić się na zmniejszeniu wielkości User Stories i lepszej współpracy zespołowej.
Pamiętaj, że metodyki są narzędziami, a nie religią. Używaj ich mądrze, dostosowując do swoich potrzeb, ale nie zapominaj o fundamentalnych zasadach, które stoją za nimi. W przypadku Scruma są to przejrzystość, inspekcja i adaptacja. W przypadku Kanbana – wizualizacja, ograniczenie pracy w toku i zarządzanie przepływem.
I jeśli kiedykolwiek zauważysz u siebie lub swojego zespołu objawy Kanbanosis Acute – nadmierne mnożenie kolumn, obsesję na punkcie przepływu kosztem wartości czy przekazywanie zadań zamiast współpracy – wiedz, że jest na to lekarstwo. Czasami najlepszym rozwiązaniem jest powrót do podstaw i przypomnienie sobie, po co właściwie stosujemy te metodyki.
Bo ostatecznie nie chodzi o to, czy używasz Kanbana, Scruma czy jakiejkolwiek innej metodyki. Chodzi o to, czy skutecznie dostarczasz wartość swoim klientom. A to wymaga współpracy, adaptacji i ciągłego uczenia się – niezależnie od tego, jak nazywasz swój proces.