Scrum with Kanban – parę refleksji na temat nowej certyfikacji

Być może obiło się wam już o uszy, że scrum.org wypuścił nowy kurs i certyfikat Scrum with Kanban. Że co? Scrum z Kanbanem? Tak, dobrze widzicie. Zdecydowanie doceniamy dobre chęci budowania mostów między dwoma światami, które do tej pory nie pałały do siebie sympatią. Ponieważ na Twitterze rozpętała się dyskusja:

  • purystów, którzy widzą tutaj zagrożenie dla dobrostanu Scruma,
  • zwolenników Kanbana, którzy kwitują całą aferę, że wreszcie ci od Scruma zauważą, że to Kanban z dodanymi paroma spotkaniami dla zamydlenia oczu,
  • wrogów jakichkolwiek certyfikacji jako sposobu na wyciąganie kasy od naiwnych,
  • praktyków, którzy dostrzegają w tym ruchu błędne zawężenie Kanbana,

postanowiliśmy w redakcji rozważyć za i przeciw łączenia Scruma z Kanbanem i troszeczkę skomentować Kanban Guide for Scrum Teams wydany przez Scrum.org.

Plusy wykorzystania Kanbana w zespole scrumowym

  • Zastosowanie limitów na Work in Progress, czyli kontrola, ile zadań mamy rozgrzebanych i nad iloma pracujemy jednocześnie. Ta praktyka przydaje się zespołom, które jeszcze nie do końca potrafią dobrze zaplanować prace na Sprint i zaczynają prace nad zbyt wieloma historyjkami naraz lub ugruntowały sobie już jakieś tempo pracy, ale chcą przetestować hipotezę na temat tego, czy multitasking obniża im efektywność. Skoncentrowanie się na kończeniu zadań, zamiast zaczynaniu kolejnych wprowadza dodatkowy porządek w pracach i dyscyplinuje zespół.
  • Wizualizacja workflow pracy – ustalenie kolejnych stanów, przez jakie przechodzi zadanie/element Product Backlogu realizowane przez Zespół Deweloperski, wizualizacja wąskich gardeł, zobrazowanie miejsc, w których zadania się starzeją (spowalniają albo zatrzymują swoje flow). Wszystko podparte jasnymi regułami, najlepiej wypisanymi gdzieś przy tablicy, co pomaga wszystkim członkom zespołu się do nich stosować oraz zmieniać je, jeśli dostrzeżemy jakąś niedoskonałość albo mamy pomysł na eksperyment usprawnieniowy.
  • Zorganizowanie pracy nad zadaniami nieplanowanymi – dziwi nas, że akurat tego aspektu nie uwzględnił Scrum.org, bo to chyba najpopularniejszy przyczółek wykorzystania praktyk kanbanowych przez zespoły scrumowe. Zespoły scrumowe zajmujące się kompletnie danym produktem muszą sobie zorganizować zadania utrzymaniowe w ramach Sprintu. Mogą to być błędy z produkcji, jakieś drobne zlecenia niecierpiące zwłoki, może jakieś zadania konfiguracyjne, które trzeba póki co wykonywać ręcznie, bo ich automatyzacja odbywa się w ramach zaplanowanego kolejnego przyrostu. Niektórym zespołom sprawdza się zostawienie buforu na takie zadania i zarządzanie nimi poprzez praktykę tablicy kanbanowej, limitowania pracy w toku i usprawniania procesu przepływu.

Minusy wykorzystania Kanbana w zespole scrumowym

  • Naszym zdaniem (z perspektywy Kanbana) błędem metodycznym jest założenie, które wspomniane jest na samym początku Kanban Guide’a dla Scruma – “introduce complementary practices from Kanban while continuing the way they are already working with Scrum”. Kanban zakłada ewolucyjne usprawnianie procesu. Błędem jest założenie, że możesz zmieniać co chcesz, pod warunkiem że nadal będziesz robić Scruma (z konkretną listą ról, artefaktów i wydarzeń). Dla ścisłości – uważamy (i w praktyce tak robimy), że można dołożyć Kanbana do istniejącego Scruma. Ale ważne jest to, że od tego momentu zespół w ramach usprawniania przepływu pracy może zdecydować się na delikatne a z czasem coraz bardziej radykalne naruszanie jakiejś z zasad czy praktyk leżących u podstaw Scruma. Analogicznym błędem metodycznym jest wytyczna “możesz robić Scruma, pod warunkiem, że nie naruszysz Waterfalla” – no chyba nie zadziała to tak jak planowali jego twórcy 😉
  • Kanban rozumiany jako całościowy system na etapie rozpoczęcia wykorzystania ma ważne założenie poszanowania istniejących ról i procesów, co w tym miejscu jest wyraźnie odmienne od Scruma. Zespół Scrumowy stawiający pierwsze kroki w danej firmie ma wyraźne wytyczne jak powinien wyglądać jego sposób pracy (m.in. praca przechodzi przez Product Backlog i jest priorytetyzowana przez Product Ownera, wybieramy zadania do Sprintu, na końcu Sprintu powstaje Przyrost) – dla wielu firm jest to szok i ciężki wysiłek by się wpasować w taki sposób pracy. W materiale dostarczonym przez scrum.org nie ma ani słowa o tym aspekcie Kanbana. Dla wielu zespołów oznacza on, że nie będą realizować tych trudnych zmian wypisanych jak recepta w Scrumie – z perspektywy Kanbana dobrze, z perspektywy Scruma jest to zagrożenie “Scrum-butem”.
  • Toczy się też debata na temat tego, czy Kanban to metoda dobrze funkcjonująca w realiach domeny złożonej (co jest w założeniach Scruma). Zwłaszcza zawężony Kanban rozumiany jako metoda na flow tasków przechodzących przez zunifikowaną tablicę jakiegoś zespołu może mniej nadawać się do eksploracji złożonych problemów – ale tego argumentu my nie podzielamy. Równie dobrze w Scrumie jak i w Kanbanie można jako element pracy traktować jakiś cel biznesowy, hipotezę do testowania, nowy feature, który chcemy w jakiejś wersji MVP wypuścić do klienta i go przetestować.

Słów kilka o Kanban Guide

Mamy wrażenie, że Scrum.org potraktował Kanbana po macoszemu, a jednocześnie na siłę próbuje wtłoczyć Kanbana zespołom dla lepszej współpracy. Przykłady poniżej.

  • Użycie Kanbana do wizualizacji pracy Scrum.org tłumaczy tym, że w Scrum Guide mówi się tylko o transparencji pracy, a nie ma wytycznych, jak ją osiągnąć. Ponieważ w Kanbanie mówi się wprost, że trzeba pokazać całą pracę i jej przepływy, pomoże to zespołowi scrumowemu lepiej zarządzać swoimi pracami. Przecież mnóstwo zespołów stosuje tablicę wizualizującą sprint backlog i nie nikt musi nazywać tego kanbanem…
  • Pamiętajmy, że kanbanowa definicja „workflow” może wykraczać poza Sprint Backlog (np. na początku zespoły mogą sobie rozbić na etapy proces dodawania elementów do Product Backlogu), może wykraczać poza ramy Sprintu (hmmm, to po co Sprinty jako wyznacznik cyklu pracy zespołu?). Porządna wizualizacja procesu może oznaczać, że zespół wrzuci sobie na tablicę proces rozwoju produktu od pomysłu do wykorzystania po wdrożeniu. W obrębie swojej pracy Zespół może patrzeć zarówno na tematy jeszcze niespełniające Definition of Ready, gotowe do pracy elementy Backlogu Produktu, kolejne etapy pracy zespołu do uzyskania Definition of Done jak i elementy już będące na produkcji, ale jeszcze niespełniające jakiegoś kryterium biznesowego. Widzimy tu sporą niekonsekwencję między iteracyjno-przyrostowym założeniem sprintu w Scrumie a płynnością flow założoną w Kanbanie.
  • Zarządzanie elementami na Workflow i usprawnianie go – czyli parę słów o tym, że zespół dzięki praktykom Kanbana zacznie rozmawiać o tym, jak pracować z tablicą, oraz, że warto sobie ustalone zasady pracy spisać i powiesić dla lepszej pamięci. Mamy poczucie, że zespoły scrumowe w toku usprawnień na kolejnych retrospektywach same wpadają na takie rozwiązania i nie ma potrzeby podciągania pod to konkretnie Kanbana.
  • Jest również mowa o metrykach – o WIP, Cycle Time (a dla niejednego zespołu scrumowego o wiele większym wyzwaniem mogłoby być pomierzenie Lead Time liczonego od pomysłu do wykorzystania przez odbiorcę), wiek zadania (czyli czas zadania od momentu startu do teraz, co ma umożliwić kontrolę nad zadaniami, które za długo są In progress) oraz Throughput (liczba zadań skończonych w danym czasie). Kontrowersyjne jest to, że podpowiadane są te, a nie inne metryki, niektóre z nich w lekkiej kontrze do wcześniej proponowanych metryk scrumowych (np. velocity). A tymczasem metryk może być o wiele więcej i to niekoniecznie zapożyczonych z Kanbana. I naprawdę warto się zastanowić, które z metryk stosować i co z nich nam wynika.
  • Na temat kilku zdań wskazujących, jak praktyki Kanbana można zaadaptować do spotkań zespołu scrumowego, nie będziemy się nadmiernie rozpisywać. Temat został potraktowany powierzchownie, a jednocześnie opisuje oczywistości, które większość znanych nam zespołów scrumowych już stosuje, nie wiedząc że to jest nazywane przez Scrum with Kanban Guide jako praktyka kanbanowa.

Czy Scrum.org jest właściwą organizacją do szkoleń i certyfikacji Kanbana?

Na koniec mamy jedną refleksję.Scrum.org to organizacja stricte scrumowa, która teraz zacznie szkolić z Kanbana. Jako że część naszej redakcji miała możliwość skorzystać z nauk Dawida Andersona i u źródła poznać, co stało za jego rozumieniem Kanbana i zaadaptowaniem metod z TPS do wytwarzania oprogramowania, bardzo nas zastanawia, u kogo trenerzy Scrum.org pobrali wcześniej nauki, by faktycznie wiedzieć, jak dobrze przekazać wiedzę o Kanbanie. Nie przekonuje nas to, że będą korzystali z wystandaryzowanych materiałów dostarczonych przez organizację. Naszym zdaniem – Kanban jest świetną metodą pracy, można z niej wiele skorzystać i zaadaptować w Scrumie (jak zobaczyliście wyżej), ale tylko wówczas, gdy metody tej nauczy was praktyk, ktoś kto od lat z Kanbana korzysta. Wcale nie chcemy reklamować szkoleń Andersona, sugerujemy, żebyście przed wzięciem udziału w szkoleniu PSK zweryfikowali porządnie praktykę trenera w temacie Kanbana. I jeśli chcecie się dowiedzieć więcej o Kanbanie, by wzbogacić swojego Scruma – raczej skorzystajcie ze szkolenia u praktyka Kanbanowego, a nie przedstawiciela organizacji, która promuje Kanbana pod warunkiem niezmieniania Scruma. Tak samo, jak nie chcielibyście się uczyć Scruma od Project Managera bez doświadczenia w agile, który chętnie pouczy zwinnego podejścia, pod warunkiem niezmieniania waterfalla.

Kontrowersyjnym pomysłem jest też to, że Scrum.org chce certyfikować ze znajomości Kanbana. Jak już wskazaliśmy w tym artykule – jest sporo luk między tym, co zawarto w Kanban Guide for Scrum Teams, a tym, czym jest Kanban rozpowszechniony dzięki pracom Davida Andersona i społeczności związanej z Lean Kanban. Wielkim nieszczęściem dla rynku profesjonalnego może być traktowanie certyfikatu PSK jako wyznacznik znajomości Kanbana.

Źródło zdjęcia: https://www.scrum.org/resources/blog/scrum-kanban-its-time-cross-bridge

Współautorzy artykułu: Ewa Gowin, Jakub Szczepanik

Komentarze do wpisu: “Scrum with Kanban – parę refleksji na temat nowej certyfikacji

  1. Liczyłem o zahaczenie o temat Scrumban. Patologia pt. „anie Scrum ani Kanban” bez wiedzy, że jest coś takiego jak metoda Scrumban i książka do niej i to też zupełnie coś innego niż PSK.
    Nie ma czegoś takiego jak Definition of Ready w Scrum. To jest pewna dodatkowa praktyka.

    „bardzo nas zastanawia, u kogo trenerzy Scrum.org pobrali wcześniej nauki,” Odpowiadam. Steve Porter przeszedł całą ścieżkę certyfikacyjną u Andersona i jest Trenerem Kanbana. Druga osoba, która stoi za szkoleniem i Guidem to Daniel Vacanti, były VP firmy Andersona i certyfikowany trener kanbana, który powinien być znany społeczności kanbanowej.

    Z guide’a nie da się wszystkiego wyczytać. Nowa wersja szkolenia jest całkiem sensowna a od trenerów PST, którzy chcą robić PSK, obecnie wymaga się opisania case Kanbana tak jak w organizacji Andersona.

    • Dzięki Krystian za komentarz,

      > Liczyłem o zahaczenie o temat Scrumban

      Nie ma słowa o nim w „Scrum with Kanban Guidzie”, więc nie wyciągaliśmy z szafy, żeby dodatkowo nie mieszać 😉

      > Nie ma czegoś takiego jak Definition of Ready w Scrum

      Wiemy. Użyliśmy „niespełnienie DoR” jako przykładu dobrze obrazującego okres w życiu elementu Backlogu Produktu, gdy nie ma jeszcze stanu gotowości do rozpoczęcia pracy. Prace w toku procesu refinementu można zwizualizować i lepiej nią zarządzić, jeśli się okaże, że w tym procesie są niedoskonałości.

      > od trenerów PST, którzy chcą robić PSK, obecnie wymaga się opisania case Kanbana tak jak w organizacji Andersona

      Bardzo dobra wiadomość.

      Pozdrawiam, Kuba


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x