Kanban i Scrum – z doświadczenia zespołu sysadminów

book

Wiedza | PROCES

Zespół, który wcześniej używał Scruma, lub przynajmniej próbował i jest świadomy jego plusów i minusów, może wprowadzić Kanban w oparciu o podstawy Scruma. Zespół, który ma się sam rozwijać, mając nakreślone jedynie trzy zasady, ma nikłe szanse powodzenia. Kanban jest świetną skrzynką na narzędzia, ale żeby naprawdę dobrze działać wymaga dobrze złożonego zestawu narzędzi.

 

Notka początkowa: ten tekst ukazał się blisko 10 lat temu na moim anglojęzycznym blogu. Wywołał dużo emocji i zainteresował sobą społeczność na tyle, że napisałam na jego podstawie opracowanie w formie IEEE, które zostało opublikowane i było cytowane kilkukrotnie w badaniach przekrojowych metod zarządzania w IT. Dla zainteresowanych wersja oficjalna znajduje się tutaj: Combining Kanban and Scrum — Lessons from a Team of Sysadmins

Warto też pamiętać, że wytyczne dotyczące Scruma od tego czasu wyewoluowały, bo Scrum Guide w 2009 roku znacznie różnił się od aktualnego, więc weźcie to pod uwagę czytając ten przypadek. Bo też przyczynił się on do niektórych zmian w samym Scrumie!

 

Ken Schwaber i wczesny kanban

Jednym ze swoich ostatnich artykułów, w którym skrytykował dość mocno Kanban, Ken Schwaber poruszył w posadach cały świat Scruma, Kanbana i Lean.Mowa o dwu następujących artykułach: Decay And DeterminationWaterfall, Lean/Kanban, and Scrum.

Nie opowiadając się po żadnej ze stron, spójrzmy, jak te dwa podejścia mogą ze sobą współpracować.

Kanban jest z natury bardzo lekki. Można go praktycznie opisać jedną frazą: przejrzystość, usprawnienia i ograniczenie prac w toku. Brzmi nieźle, oszczędnie[1]. Ale widzę tu duży problem: to nie wystarczy. Kanban jest tak lekki, że nie oferuje wystarczających wskazówek dla zespołów, które posługują się innymi metodami niż waterfall czy partyzancki dewelopment. Znam zespoły, które nie potrafią samodzielnie wymyślić całego procesu. Stworzenie procesu wymaga bowiem:

  • ustalenia sposobu gromadzenia wymagań
  • ochrony procesu
  • rozwiązywania problemów związanych z rozszerzaniem zespołu
  • przełożenia wartości biznesowej
  • raportowania przewidywań na przyszłość
  • radzenia sobie z problemami finansowymi
  • i tak dalej…

Ogarnięcie tego wszystkiego jest ogromnie praco- i czasochłonne, a do tego odciąga zespół od faktycznej pracy. A nie możemy przecież wprowadzić bezpośredniego kierownika, bo tracimy wtedy atut samoorganizacji. Aż prosi się to o odgórną kontrolę procesu. Chyba rozumiem teraz wątpliwości Kena Schwabera na temat Kanbana.

Kanban ma też swoje miejsce

Ale co z zespołami, które zajmują się wsparciem technicznym? Nie mają możliwości planowania sprintów. Przykładem mogą być administratorzy systemu, dostawcy infrastruktury itd. Jest dobrze, jeśli zespół deweloperski prowadzi wsparcie techniczne własnych narzędzi, ale musi być też ktoś, kto zapewnia zespołowi przestrzeń. Są też zespoły wspierające produkty skierowane do wycofania, więc zajmują się tylko najbardziej krytycznymi błędami do czasu, gdy produkt zostanie zastąpiony lub odejdzie w niepamięć. Oni również nie mogą korzystać ze Scruma, jako że nie mają możliwości planowania pracy (choć próbowali)[2].

Połączenie kanbana i Scruma – ScrumBan i inne wynalazki

Jakiś czas temu spróbowaliśmy połączyć Scrum i Kanban. Zawsze mam obiekcje, kiedy ktoś używa słowa Scrum na określenie czegoś, co Scrumem nie jest, więc to nowe podejście nazwaliśmy Kate-Ban :). To, czego potrzebowaliśmy, zaczerpnęliśmy z Kanbana, dopełniając całość elementami Scruma. Spójrzmy, jak nam poszło.

Z początku było kilka problemów – zespół nie był zbyt wielozadaniowy. Sysadmini windowsowi wspierali sieć laboratoryjną, a linuxowi sieć roboczą i łącza między lokalizacjami. Z racji polityki bezpieczeństwa, te dwie kategorie obowiązków nie mogły się przeplatać. Goście od Windowsa mieli podstawową wiedzę na temat środowisk linuxowych, ale nie mieli dostępu do wszystkich ich części – i vice versa. Żeby było ciekawiej, zespół obsługiwał około 1700 klientów, więc ustalanie porządku w backlogu było niełatwym zadaniem. Utrudniało to też śledzenie pracy nieplanowanej, która – jak się później okazało – stanowiła około 50% całości. Praca nieplanowana w tym przypadku oznaczała problemy na 10 minut roboty, jak tworzenie konta, a nie błędy do usunięcia przed upływem dnia – te były konkretną pracą.

Niekonwencjonalna tablica kanbanowa i jej flow

Tablica wyglądała tak:

Kate Terlecka Hobler Scrum i Kanban

Kolejki (zielone linie na górze)

Kolejki były dwie – linuxowa i windowsowa. Elementy były zdejmowane z tablicy zgodnie z ich priorytetem – najważniejsze znajdowały się w prawym dolnym rogu. Zadania mógł się podjąć każdy, kto był w stanie się nim zająć. Generalnie zadania linuxowe przypadały linuxowym adminom i podobnie po stronie Windows, choć zdarzały się wyjątki. Ktokolwiek był w stanie podjąć się zadania z przodu każdej kolejki, zdejmował je z tablicy. Kolejki miały limit 10 elementów, reszta była przechowywana w Product Backlogu.

Grupy kompetencji (linie żółte)

Każda grupa miała nałożony limit 4 zadań (na 3 osoby), dodatkowo każdej grupie przydzielono zadanie typu QR. QR (quick response) to w gruncie rzeczy zabawa w strażaka i załatwianie drobiazgów. Mimo to, było to zadanie krytyczne – w oparciu o wykonane zadania QR, do kolejki dodawane były nowe elementy, co pomogło jak najbardziej zautomatyzować tę rolę. Powstało też specjalne miejsce na zadania, które utknęły w martwym punkcie na skutek różnych zewnętrznych zakłóceń.

Zrobione i Odrzucone (linie czerwone)

Miejsce na zadania zakończone było zwalniane, gdy tylko się zapełniło. Odrzucone były te zadania, które nagle okazywały się niepotrzebne lub bezsensowne.

To tyle, jeśli chodzi o Kanban. Teraz trzeba to zescrumować.

Jak sescrumować kanbana?

Powołano Product Ownera[3], który zajmował się Product Backlogiem i dostarczaniem zadań na tablicę. Jego obowiązkiem było pilnować, by zawsze było co robić, ale też by liczba zadań na tablicy nie przekraczała 10 w każdej kolejce.

Mieliśmy też Kanban Mastera (to ja! 😉 ), który zajmował się procesem, pilnował, by tablica była w należytym porządku, opiekował się rozwojem zespołu itd.

Dla kilku rodzajów zadań powstała Definicja Słowa „Zrobione”, której należało się trzymać.

Co tydzień odbywała się sesja Doszlifowywania[4] – na przemian bardziej techniczna i zorientowana na klienta.

Co dwa tygodnie odbywała się Retrospekcja, chyba że trzeba ją było z jakiegoś powodu zrobić wcześniej.

Mieliśmy też Przegląd, przeprowadzany przez Product Ownera, gdy zakończona została jakaś logiczna część funkcjonalności, ale nie częściej niż raz na dwa tygodnie.

Codziennie przeprowadzaliśmy Daily Planning – połączenie Sprint Planningu i Daily Scruma – dwuetapowe, półgodzinne spotkania przy tablicy, podczas których zespół aprobował nowe elementy w kolejkach, planował następne 24 godziny i krótko streszczał wykonaną pracę.

Nie każdy eksperyment się udaje

Wpadki:

Brak terminów. W Scrumie, Sprinty nadają pracy rytm, określając moment, kiedy zadania są sprawdzane i komentowane. W tym układzie nie mieliśmy czegoś takiego, więc po jakimś czasie zespół zaczął określać terminy dla najważniejszych i najbardziej zaległych zadań.

Brak regularnych informacji zwrotnych pozwolił niektórym na trochę lenistwa albo zajmowanie się czymś innym w międzyczasie, co przez dość długi czas umykało uwadze innych.

W tym przypadku, zespół mógł się pochwalić świetnym Product Ownerem, ale nietrudno byłoby zmienić takie podejście na zbyt duży zalew informacji.

Ale też z eksperymentów wychodzą niespodzianki!

Niespodzianki:

Jako, że zbyt ciężko było szacować w tym środowisku, nie szacowaliśmy czasu na wykonanie zadań. Product Owner tworzył prognozy na podstawie liczby zadań, a nie ich wielkości. W tak zróżnicowanym środowisku sprawdziło się to zaskakująco dobrze. [5]Może i Jim Highsmith miał rację, kiedy nawoływał do zmniejszenia nacisku na prędkość.

Ale to temat na inny raz.

Historia tego zespołu została, niestety, w nagły sposób urwana przez ciąg niefortunnych zdarzeń. Zastąpili ich ludzie, którzy postanowili zachować tylko kilka z powyższych zasad, ale nie wychodzi im to na dobre.

Kanban i Scrum: Spojrzenie na w przyszłość okiem 2008/2009 roku

Wniosek:

Zespół, który wcześniej używał Scruma, lub przynajmniej próbował i jest świadomy jego plusów i minusów, może wprowadzić Kanban w oparciu o podstawy Scruma. Zespół, który ma się sam rozwijać, mając nakreślone jedynie trzy zasady, ma nikłe szanse powodzenia. Kanban jest świetną skrzynką na narzędzia, ale żeby naprawdę dobrze działać wymaga dobrze złożonego zestawu narzędzi.

[1] W 2010 roku David Anderson opublikował najpopularniejszą (a do tego bardzo dobrą) książkę o Kanbanie – „Kanban: Successful Evolutionary Change for Your Technology Business”, gdzie dodaje wiele dobrych praktyk z innych metod, między innymi Scruma tak, żeby Kanban stał się wystarczający, aby wesprzeć cały proces tworzenia oprogramowania. Tekst ten jednak powstał zanim książka się upowszechniła – zaledwie dwa miesiące po jej wydaniu.

[2] Dla dzisiejszego stanu Scruma to już nie jest przeszkoda. Brak dolnych ograniczeń długości Sprintów i brak silnych rekomendacji planowania 70% pojemności Sprintu sprawia ze Scrum jest z powodzeniem stosowany zgodnie z wszystkimi zasadami nawet w zespołach wsparcia.

[3] W tym wypadku był to rodzaj słabego PO, zbliżonego do analityka biznesowego, który z czasem ewoluował w kogoś, kto odpowiada za produkty tworzone przez ten zespół, kiedy procentowy udział zadań wsparcia spadał.

[4] Wtedy jeszcze zwana Groomingiem, teraz byłby to Refinement

[5] Uważny czytelnik zauważy tutaj początki podejścia NoEstimates ????

Najlepsze artykuły:

Powiązane artykuły, mogą Cię też zainteresować!

" Model Spotify " – lekcja transplantologii

Nie wprowadzajcie tak zwanego “Modelu Spotify”. Inspirujcie się tym, jaką kulturę ma Spotify, bo to bardzo dobry przykła...

Trzy trudne narzędzia Scrum Mastera

Nie bójmy się radykalnych rozwiązań i kroków. W sytuacjach kryzysowych jest to ludziom potrzebne.Pamiętajmy: głaskanie s...

Ilustrowany Scrum Guide - darmowy e-book do ściągnięcia

Scrum: jest lekki, łatwy do zrozumienia i trudny w implementacji. Dlatego 7 listopada 2017 Jeff Sutherland i Ken Schwab...

Problemy z rozmiarówką - estymacje dla opornych

Za oknem deszcz. Zrobiło się na tyle ciemno, że nawet włączenie światła jakoś niewiele daje. Taki nieustanny biały szum ...

Najlepsze artykuły: