Aberracje (?) Kanbanu

Tytuł brzmi złowieszczo, ale w obecnych warunkach atmosferycznych (32 stopnie Celsjusza w cieniu) ciężko się myśli. Dziś zatem nieco krótszy temat, czyli tytułowe błądzenie czy odstępstwo od przyjętych reguł w Kanbanie (zwróćcie uwagę na znak zapytania…) w postaci Protokanbanu i Scrumbanu. Coś się tam wam o uszy obiło? Znacie kogoś, kto w ten sposób pracował i to była totalna porażka? Zespół wam wmawia, że to jego metoda pracy, ale efekty są z tego mizerne? No to wyjaśnijmy sobie te pojęcia i znak zapytania przy aberracji.

Na początek weźmy Protokanbana. Pewnie (i słusznie) pierwszy człon tego wyrazu nasuwa wam skojarzenia ze słowami takimi jak protoplasta czy prototyp. Proto oznacza coś pierwszego, początkowego czy pierwotnego i tak właśnie jest z Protokanbanem. To nie jest jeszcze Kanban, to nie pretenduje nawet do miana Kanbana, to dopiero zestaw eksperymentów i prób, który odpowiednio rozwijany może stać się pełnoprawnym Kanbanem. W artykule From visualization to Kanban Method Primitivo Cachero Viejo wymienia kilka oznak świadczących o tym, że pracujemy Protokanbanem i zaczynamy kwestionować i zmieniać nasz system pracy:

  • decyzje są podejmowane na podstawie tablicy z zadaniami
  • pojawiają się miary, żeby podejmować decyzje na podstawie danych
  • rozpoczyna się zmiana w kierunku systemu PULL
  • zespół przed podjęciem decyzji dyskutuje nad tablicą uwzględniając feedback
  • a na wizualizacji zadań pojawiają się kolumny pokazujące proces prac

To jeszcze nie jest limitowanie WIP, to jeszcze nie są ustalone zasady czy wprowadzony prawidłowo PULL. Ale to nie jest już tylko sama wizualizacja prac. Coś zaczyna się dziać w zespole, pojawia się refleksja i chęć eksperymentowania w kierunku rozwoju procesu pracy. I to właśnie jest Protokanban. Jeśli zatem zespół mówi, że pracuje Kanbanem, ale nie ma elementów właściwych dla tej metody pracy, nie wytykajmy zespołowi wszystkich usterek, ale spójrzmy czujnym okiem, czy może jednak coś dobrego się w nim dzieje i mamy do czynienia z Protokanbanem.

A co ze Scrumbanem? Przeciwnicy tej metody często prychają z lekceważeniem, że to taki wytrych dla zespołów, które nie dowożą celu sprintu i próbują się wybronić.Tymczasem pierwotna idea stojąca za Scrumbanem i opisana przez Coreya Ladasa pokazywała, jak dojrzały zespół pracujący Scrumem przechodzi powoli w stronę Kanbanu wprowadzając kolejnego jego elementy do swoich sprintów, NIE likwidując od razu planowania czy review, nie zmieniając czasu na iterację, ale podejmując stopniowo w oparciu o wyniki kolejnych eksperymentów decyzje usprawniające (nie ułatwiające – to zasadnicza różnica) ich proces pracy. A zatem, jeśli zespół przychodzi i mówi, że Scrum im się nie sprawdza i chcą pracować Kanbanem, to nie rzucajmy ich na głęboką wodę, tylko właśnie przeprowadźmy małymi krokami przez zmianę metody pracy, dokładając elementy Kanbanu i sprawdzając, jak zespół się z nimi czuje, czy poprawiają proces, czy dzięki nim jest efektywniejszy.
Uwaga – oczywiście na samym początku przeprowadzamy rozmowę z zespołem, chociażby korzystając z 5why, żeby sprawdzić, czy rzeczywiście Scrum nie jest dla nich najlepszym rozwiązaniem, czy może tylko chcą pójść “na łatwiznę”, bo Scrum wymaga od nich zbyt wiele.

Poprzez tytułowy znak zapytania chciałabym zatem, żebyście zawsze pamiętali, że Protokanban i Scrumban to nie jest nic złego, to nie są pomyłki czy odszczepieńcy. To osobno funkcjonujące metody pracy, które mają swoje przeznaczenie, swoje zasady i swój rytm. Co więcej ich poprawne używanie też wymaga czasu, zaangażowania i wysiłku całego zespołu. Czy zatem mieliście do czynienia z opisanymi metodami, czy z ich namiastką, którą zespół używał jako wygodnej wymówki na złagodzenia wymagań wobec siebie?

Reklama


Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X