KANBAN

CZYLI FAKTY I MITY O KANBANIE W NASZYM ZESPOLE

FAKTY I MITY

"Nie robicie retro"

Kanban też przewiduje retrospektywę
Robimy ją regularnie tworząc ActionPointy do zrealizowania

FAKTY I MITY

"Nie musicie się tak spinać"

KanBan skutecznie eliminuje przestoje w pracy
W każdej chwili mamy co robić
Wciąż ewidencjonujemy poświęcony na pracę czas

FAKTY I MITY

"Jesteście fabryką tasków"

Angażujemy się w kształt zadań na etapie przygotowywania
Identyfikujemy się z produktem i wciąż myślimy jak możemy go usprawnić

FAKTY I MITY

"Zespół nie ma skupienia"

Dbamy by historie nawiązywały do celów kwartalnych
Naszym celem jest znaczne podniesienie jakości naszych produktów
Nasza tablica wyznacza nam jasne priorytety

FAKTY I MITY

"Coś tracicie..."

Nie uzyskaliśmy jednoznacznej odpowiedzi "co tracimy"
... ale jako zespół widzimy jak dużo zyskaliśmy na zmianie metodyki
PO nic nie stracił, nie odczuwa zmiany metodyki w negatywny sposób

FAKTY I MITY

"Inne zespoły są zgorszone"

Wciąż nie wiemy które i co je gorszy
Nie zaobserwowaliśmy "zgorszenia" naszą zmianą
Dwa zespoły widząc rozrost "afery" samodzielnie wyraziło swoje wsparcie dla nas

FAKTY I MITY

"Tak naprawdę macie Scrum"

Scrum i Kanban to podzbiory metodyk Agile - mają dużo wspólnego
Pewne elementy Scruma pochodzą z KanBana (np. tablica) a inne na odwrót
Chcemy zachować kompatybilność z procesami działającymi w firmie

"Tak naprawdę macie Scrum"

• Zrezygnowaliśmy z iteracyjności

Trzymamy równe tempo w każdym tygodniu

• Nie planujemy wg. velocity zespołu

48 to za mało na sprint, 52 za dużo - co to właściwie oznacza?

• Zrezygnowaliśmy z wirtualnych estymat

Istotny jest dla nas realny czas wykonania historii

• Odeszliśmy od sztywnych spotkań

Robimy to na żądanie, gdy jest taka potrzeba

"Tak naprawdę macie Scrum"

• Wciąż planujemy

Na Replenishmentach uzupełniamy pracę w kolumnach

• Nadal wpływamy na kształt historii

Mamy spotkania Refinement, gdzie analizujemy wartości historii

• Codziennie spotykamy się na standupie

Mimo, iż tablica jest naszą wyrocznią w sprawie stanu pracy

• Nadal prezentujemy nasze Review

Review to snapshot stanu pracy + metryki

"Tak naprawdę macie Scrum"

• Utrzymujemy retrospekcję

Wypisujemy AP do zrealizowania i analizujemy postęp realizacji

• PO - nadal ten sam ;)

... i wciąż uśmiechnięty :)

FAKTY I MITY

"To tylko eksperyment"

Jako zespół chcieliśmy spróbować nowej metodyki
Jesteśmy zadowoleni z efektów eksperymentu i jesteśmy zdecydowani pozostać przy tej metodyce
Wciąż adaptujemy proces do naszych potrzeb i widzimy jak z tygodnia na tydzień bardziej nam on odpowiada

FAKTY I MITY

"Problemy wynikają z braku celu"

Mamy cele kwartalne, które są dla nas nadrzędne
Na prośbę zespołu Process mamy cele iteracyjne
Problemów było więcej, omówimy je w kolejnej części

GENEZA

25.11.2015r - Warsztat z Tomkiem

GENEZA - PROBLEMY

ZA DŁUGIE SPRINTY

Spotkania (replenishment) na żądanie - kiedy są potrzebne
Ciągłość procesu
Gdy w innych zespołach trwa stabilizacja u nas praca wciąż wre - jak w każdym innym tygodniu

GENEZA - PROBLEMY

BRAK ZAUFANIA

Czytelna i transparentna tablica uwzględniająca wszystkie wydarzenia w pracy
"świeży start"

GENEZA - PROBLEMY

ESTYMACJE

Podział na mniejsze, możliwie równe elementy
Estymacje godzinowe
Estymacje wynikają z doświadczeń z poprzednich zadań i są wsparte wskaźnikami Lead i Cycle Time

Nie wyrabiamy się w sprincie, estymacje nie działają

GENEZA - PROBLEMY

PLANOWANIE

PO może w dowolnym momencie zmienić plany
Gdy brak jednego celu nie ma konieczności jego "sztucznego" tworzenia

Dynamiczna zmiana planów, feature soup, nie możemy dobrać celu sprintu

GENEZA - PROBLEMY

ZALEŻNOŚCI OD ZESPOŁÓW

Szybka reakcja na potrzeby innych zespołów
Zmiana priorytetu naszych historii kiedy zależność jest gotowa

GENEZA - PROBLEMY

NIE ZNAMY PRĘDKOŚCI

Lead Time i Cycle Time jako coraz bardziej dokładne wskaźniki
Zaczynamy liczyć throughtput dla błędów i historii
Pojedynczy task/bug jest jednostką

GENEZA - PROBLEMY

DŁUG TECHNICZNY

PO jawnie planuje poprawę błędów
Skupienie na jakości
Sprint review pokazuje zadania ukończone a nie "dopchnięte" do dema.

CO ZYSKALIŚMY

Tablica pozwala łatwo odnaleźć blokady w procesie

(limity, podświetlanie przepełnionych kolumn)

CO ZYSKALIŚMY

Uwolniliśmy się od abstrakcyjnych estymat

Widzimy historie przeestymowane i niedoestymowane

CO ZYSKALIŚMY

Skupienie zespołu:

Większy focus na zadaniach

Mniej spotkań

Finalnie: więcej zrealizowanych historii

CO ZYSKALIŚMY

Dynamiczne zmiany:

Elastycznie reagujemy na zmiany w planach

PO może w każdej chwili zmienić nam priorytet

Możemy wziąć historię do realizacji jak tylko jej zależności są ukończone

CO ZYSKALIŚMY

Transparentność i zaufanie:

Większa świadomość PO w zakresie ilości poprawianych błędów i prac dodatkowych

Wszystko ląduje na tablicy

MIARA SUKCESU

Pracujemy nad LeadTime / CycleTime
Aktualne wartości i zmiana na Review
Liczymy Throughtput dla błędów i historii
Wybraliśmy i zwiększamy wskaźniki jakości

Jak zespół chce pokazać, że się rozwija

"Dostosowaliśmy proces do naszej pracy

a nie naszą pracę do procesu"

"PO nie odczuł różnicy, bo tak naprawdę od dawna pracowaliśmy jak w KanBanie"

"Nie przywiązuj się do jednej

broni ani do jednej szkoły

walki."

~ Miyamoto Musashi

Źródło: Kanban i Scrum - jak uzyskać najlepsze z obu