PROFESSIONAL SCRUM WITH KANBAN™

SZKOLENIE PROFESSIONAL SCRUM™ WITH KANBAN

Zespół robi Scrum – sprinty się kończą, retrospekcje się odbywają, codziennie jest daily. Mimo to coś nie gra z przepływem pracy: zadania czekają w kolejce, praca piętrzy się w środku sprintu, a przewidywalność dostarczania wciąż kuleje. A wykres spalania Sprintu bardziej przypomina klify w Dover niż równie pochyła. “Robimy Scrum, to czemu mamy nieefektywny proces?” – to pytanie pada na każdej edycji szkolenia Professional Scrum with Kanban (PSK).

Scrum Guide celowo nie mówi, jak zarządzać przepływem pracy wewnątrz sprintu – to nie jest jego zadanie. Odpowiedź na to pytanie daje Kanban: konkretne praktyki wizualizacji pracy, limitowania pracy w toku (WIP) i metryk przepływu, które nakładają się na Scruma, nie zastępując go.

To szkolenie jest zbudowane na praktyce wdrożeniowej, nie na teorii z podręcznika. Dwa dni pracy warsztatowej, symulacje przepływu pracy i realne metryki – nie slajdy o tym, czym jest Kanban.

PSK jest częścią programu Scrum.org rozwoju kompetencji Scrum Masterów i członków zwinnych organizacji. Dodatkowo, szkolenie przygotowuje do pierwszego stopnia certyfikacji (PSK) znanej i cenionej organizacji – Scrum.org, założonej przez jednego z twórców Scrum – Kena Schwabera. Więcej o programie i certyfikacji.

DLA KOGO JEST SZKOLENIE PROFESSIONAL SCRUM™ WITH KANBAN.

• dla Scrum Masterów, którzy chcą wykorzystać praktyki Kanban do poprawy przepływu pracy w zespole;
• dla profesjonalnych Developerów wykorzystujących Scrum, którzy chcą większej efektywności i przewidywalności własnej pracy;
• dla Liderów i Managerów, którzy chcą pomagać zespołom skuteczniej wykorzystywać Kanban obok Scruma;
• dla Product Ownerów, którzy chcą rozumieć, skąd biorą się metryki przepływu, na których opierają prognozy dostarczania.

Szkolenie prowadzone po polsku. Nie jest wymagana wcześniejsza wiedza o Kanbanie – potrzebna jest tylko podstawowa znajomość Scruma.

CO ZYSKASZ DZIĘKI SZKOLENIU PROFESSIONAL SCRUM™ WITH KANABN

Dwa dni pracy warsztatowej – teoria, studia przypadków i symulacje, nie wykład o metodzie Kanban.

Po szkoleniu będziesz:

• rozumieć, jak łączyć cztery praktyki Kanban ze Scrumem, nie tracąc korzyści żadnego z nich – i wiedzieć, że Scrum Guide przy tym się nie zmienia;
• potrafić zbudować Definicję Przepływu Pracy dla Sprint Backlogu i zdefiniować limity pracy w toku (WIP), które faktycznie zmieniają zachowanie zespołu;
• znać cztery metryki przepływu (Cycle Time, Throughput, WIP, Work Item Age) i umieć czytać wykresy, które za nimi stoją – Cycle Time Scatterplot i Cumulative Flow Diagram;
• wiedzieć, jak Prawo Little’a i prognozowanie oparte na danych (w tym symulacje Monte Carlo) poprawiają Sprint Planning – z większą przewidywalnością niż samo story-pointowanie;
• umieć prowadzić Daily Scrum, Sprint Review i Retrospektywę w oparciu o przepływ pracy, nie o rundę statusów;
• rozumieć, jak zmienia się praca Scrum Mastera, Product Ownera i Developerów, kiedy do Scruma dochodzi Kanban;
• przygotowany do egzaminu PSK I.

CO BĘDZIE NA SZKOLENIU PROFESSIONAL SCRUM™ WITH KANBAN

Scrum – odświeżenie fundamentów. Krótkie przypomnienie frameworku Scrum przed przejściem do Kanbana – żeby cała grupa startowała z tego samego punktu, niezależnie od tego, jak dawno kończyła PSM.

Teoria i praktyki Kanban. Cztery praktyki rdzeniowe Kanban dla zespołów Scrumowych: wizualizacja przepływu pracy, limitowanie pracy w toku (WIP), aktywne zarządzanie pracą w toku, inspekcja i adaptacja Definicji Przepływu Pracy. Cztery metryki przepływu – Cycle Time, Throughput, WIP, Work Item Age – i Prawo Little’a jako matematyczny fundament tego, dlaczego mniej pracy naraz kończy się szybciej, nie wolniej.

Kanban w praktyce – symulacja. Ćwiczenie na żywym przykładzie, nie na teorii. Czytanie wykresów, które rzeczywiście mówią coś o pracy zespołu: Cycle Time Scatterplot (gdzie leżą 50., 85. i 95. percentyl) i Cumulative Flow Diagram (skąd się bierze wąskie gardło, zanim ktokolwiek je zauważy).

Scrum z Kanbanem – wciąż Scrum. Obalanie mitów (“Kanban to melanż, nie Scrum”, “trzeba zacząć od Scruma, a dopiero potem przejść na Kanban”). Budowanie Definicji Przepływu Pracy dla Sprint Backlogu – analogicznie do Definition of Done, ale dla samego procesu. Typowe polityki przepływu: rodzaje elementów backlogu, limity WIP, polityki priorytetyzacji, Service Level Expectations.

Przepływ w zdarzeniach scrumowych Jak Kanban i metryki przepływu wpływają na każde zdarzenie, nie zmieniając samego Scruma: Sprint Planning oparty na Throughput i prognozowaniu (w tym symulacje Monte Carlo) zamiast samego story-pointowania; Daily Scrum czytany od prawej do lewej strony tablicy, z naciskiem na Work Item Age zamiast rundy statusów; Sprint Review jako okazja do przeglądu metryk i planowania wydań; Retrospektywa oparta na danych z wykresów przepływu, nie tylko na odczuciach.

Kanban z perspektywy ról w Scrumie. Jak zmienia się praca Scrum Mastera (rola “flow managera” jako rozszerzenie, nie zamiana roli), Developerów (limity WIP jako wsparcie samoorganizacji, nie jej ograniczenie) i Product Ownera (zarządzanie przepływem odkrywania i doskonalenia produktu, nie tylko przepływem sprintu).

Increment i Sprint w świecie ciągłego przepływu. Czy Kanban prowadzi do rezygnacji ze Sprintu. Jak wygląda dostarczanie ciągłe (continuous flow) w ramach Scruma i gdzie leży granica między Kanbanem wspierającym Scruma a przejściem w stronę modelu DevOps.

DLACZEGO WARTO U NAS

Andrzej i Adam nie uczą Kanbana z podręcznika – stosowali praktyki przepływu pracy przy wdrożeniach Scruma i LeSS w dużych organizacjach, gdzie przewidywalność dostarczania była realnym problemem biznesowym, nie ćwiczeniem na szkoleniu.

Najczęstszy mit, z którym się mierzą, to “Kanban to tablica” – że wystarczy narysować kolumny To Do / Doing / Done i problem z przepływem sam się rozwiąże. To nieprawda, i pokazują to nie twierdzeniem, tylko danymi: na symulacjach i realnych metrykach przepływu widać, jak nieefektywne są procesy, które wyglądają dobrze na tablicy, ale mają wysoką pracę w toku, długi Cycle Time i wąskie gardła niewidoczne gołym okiem. Dopiero to przekonuje zespoły, że limit WIP i Definicja Przepływu Pracy to nie biurokracja, tylko odpowiedź na problem, który właśnie zobaczyli na własnych danych.

Na szkoleniu to widać. Metryki przepływu, o których mówimy, to nie liczby ze slajdu – to sposób, w jaki rozliczaliśmy zespoły z realnej przewidywalności dostarczania podczas wdrożeń.