KANBAN
CZYLI FAKTY I MITY O KANBANIE W NASZYM ZESPOLE
FAKTY I MITY
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
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
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
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