Czym jest Scrum - uczciwie
Scrum to framework dla pracy, która wymaga regularnego inspect & adapt - regularnego zatrzymania, oceny i korekty kursu.
Sprint ma start i koniec. Są bounded iterations - zamknięte pętle uczenia. Sprint Backlog to zobowiązanie na ten sprint: to robimy, tego nie bierzemy. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective - każde z tych wydarzeń ma cel i strukturę.
Dlaczego zamknięte iteracje mają sens? Bo zmuszają do priorytyzacji. Nie wszystko może być "w sprincie." Trzeba wybrać. I ten wybór - co jest ważne teraz, a co poczeka - jest podstawową pracą decyzyjną w Scrumie.
Sprint zaczyna się czysto. Sprint kończy się z czymś, co można pokazać i ocenić. Potem retro: co poszło dobrze, co nie, co robimy inaczej. I znowu.
Scrum nie pyta "co jest w kolejce?" Scrum pyta "co wybieramy na ten ograniczony czas, żeby dostarczyć wartość - i czego się z tego nauczymy?"
Oba frameworki są dobre. Dla różnych pytań.
Cztery miejsca kolizji
Kiedy Kanban board pojawia się w projekcie scrumowym, nie jest to po prostu "dodatkowe narzędzie." To jest zmiana pytania, które zadaje sobie zespół. I ta zmiana ma konkretne, przewidywalne skutki.
Kolizja pierwsza: czysty start/koniec vs. ciągły przepływ.
Sprint zaczyna się czysto i kończy czysto. Kanban nie ma "zamknięcia" - wszystko jest w ruchu, wszystko jest "in progress" na jakimś etapie.
Jeśli masz Kanban board w projekcie scrumowym, sprint nigdy nie jest naprawdę "skończony". Karteczki zawsze są w jakiejś kolumnie - "In Review", "Waiting for QA", "Waiting for Deploy." Co to znaczy? Że Sprint Review odbywa się na tle "pracy w toku" - i nikt dokładnie nie wie, co jest done, a co jest "prawie done."
"Prawie done" to nie done. W Scrumie.
Kolizja druga: silosy kolumn vs. cross-funkcjonalność.
Pięć kolumn: "Design", "Backend", "Frontend", "QA", "Deploy." Wygląda przejrzyście. Ale co ta tablica naprawdę wizualizuje? Handover. Karteczka wędruje od specjalisty do specjalisty jak w taśmie produkcyjnej.
Scrum zakłada, że Deweloperzy pracują razem - nie że przekazują sobie zadanie jak pałeczkę w sztafecie. Cross-funkcjonalność oznacza, że problemy rozwiązuje się wspólnie, nie sekwencyjnie. Tablica z kolumnami per specjalizacja wizualizuje - i wzmacnia - dokładnie to, czego Scrum chce unikać.
Widziałem zespół, który przez rok miał "Problem with collaboration between frontend and backend" na każdym retro. Kiedy usunęliśmy kolumny per rola - zniknął.
Kolizja trzecia: przedłużanie sprintów "bo jest w toku."
"Nie możemy zamknąć sprintu, bo to jest jeszcze w kolumnie Testing." "Przesuniemy sprint o trzy dni, żeby to skończyć."
Sprint, który się "nie kończy" to nie jest sprint. To jest projekt waterfall z kolorową tablicą.
Scrum nie istnieje bez zamkniętej pętli. Inspect & adapt wymaga momentu zatrzymania - nie ciągłego ruchu. Jeśli tablica Kanban daje argument do niezamykania sprintu, tablica Kanban niszczy jedną z podstawowych wartości frameworku.
Kolizja czwarta: WIP bez limitu niszczy focus sprintu.
Kanban ma limity WIP - i to jest jedna z jego mądrych zasad. Ogranicz liczbę pracy w toku, bo multitasking jest iluzją.
Ale kiedy Kanban board jest wizualizacją a nie prawdziwym systemem - WIP limits nie istnieją. Każdy ma pięć karteczek "in progress" jednocześnie. Kolumny są pełne. Nikt nie kończy, wszyscy są zajęci.
"Jesteśmy zajęci" i "dostarczamy wartość" to nie jest to samo zdanie.
Kiedy Kanban w software development ma sens
Nie mówię, że Kanban nie działa w IT. Mówię, że nie działa w tym samym projekcie co Scrum - bo odpowiadają na różne pytania.
Kiedy Kanban jest właściwym wyborem w software development?
- Maintenance teams - praca polega na ciągłym napływie małych, różnorodnych zadań. Bugfix, mała zmiana konfiguracji, aktualizacja zależności. Czas reakcji ważniejszy niż iteracja.
- Support i operations - incydenty, requesty, patche. Priorytet to czas od zgłoszenia do rozwiązania.
- Infrastruktura i DevOps - ciągły przepływ zmian, brak cykli product discovery.
- Projekty po launch - produkt żyje, ale nie ewoluuje intensywnie. Utrzymanie, drobne ulepszenia, monitoring.
W tych kontekstach Kanban jest dokładnie tym, czego potrzebujesz. I właśnie dlatego warto go znać i szanować - a nie używać go wszędzie jako "przejrzystego narzędzia wizualizacji."
Co z tą tablicą z piętnastoma kolumnami
Tech Lead przez chwilę patrzył na tablicę. Policzył kolumny milcząc.
"Właściwie nie wiem, po co mamy pięć kolumn między 'in progress' a 'done'."
To jest dobry punkt startowy.
Pytania do zadania na najbliższym retro:
- Po co mamy tę tablicę? Co decydujemy na jej podstawie?
- Czy tablica pomaga nam w inspect & adapt, czy zaciemnia co jest naprawdę "done"?
- Ile kolumn to "przepływ pracy," a ile to "bo tak wyglądało na demo"?
- Czy każda kolumna ma właściciela i czas cyklu? Czy karteczki po prostu... stoją i czekają?
- Kto decyduje kiedy karteczka się przesuwa - i czy ta decyzja jest świadoma?
Tablica, która odpowiada na te pytania sensownie - zostaje lub zostaje uproszczona. Tablica, która jest wizualizacją chaosu - do przebudowania.
Kanban i Scrum mogą koegzystować w jednej organizacji - w różnych kontekstach, dla różnych zespołów, z różnymi pytaniami. Nie mogą koegzystować w tym samym projekcie, jeśli nikt nie zadał pytania: który framework odpowiada na pytanie, które musimy zadać?
Dla tych, którzy naprawdę chcą połączyć elementy obu: istnieje Kanban Guide for Scrum Teams - oficjalny materiał opisujący, jak świadomie i intencjonalnie wprowadzać praktyki Kanbana do pracy scrumowej. Albo Scrumban - bardziej ewolucyjne podejście do stopniowego przejścia między frameworkami. To nie to samo co Kanban board przyklejony do Scruma "bo tak jest przejrzyście." To przemyślana integracja z jasno określonymi pytaniami.
Czy Twój zespół ma Kanban board i sprint w tym samym projekcie? I czy ktoś kiedyś pytał - po co mamy oba, i co każde z nich naprawdę wnosi?