Archiwum

Rozprawiamy się z wrzutkami Kanbanem

Na naszych łamach poruszaliśmy już kilkukrotnie tematy związane z Kanbanem. Iza przybliżyła wam samą ideę, Kuba nawiązał do pierwszej z zasad, czyli wizualizacji, i wyjaśnił, czemu służy i jak można wizualizować, a potem nieco przeskoczyliśmy naprzód i Iza opisała, jak i po co limitować pracę w toku.Ponieważ jednak w rozmowach często słyszymy pytania o to, jak zacząć pracę Kanbanem, pora zmierzyć się z tym tematem. Dziś będzie o tym, jak wdrożyć Kanbana, gdy nie panujemy nad ilością, rodzajem prac i mnogością wrzutek.

Zacznijmy od tego, że David Anderson, twórca idei przeniesienia Kanbana z fabryki Toyoty i linii produkcyjnych do developmentu, pisze o 6 zasadach Kanbana:

  1. Wizualizuj.
  2. Limituj pracę w toku.   
  3. Zarządzaj przepływem prac.
  4. Wyjaśniaj zasady.
  5. Stwórz pętle feedbacku.
  6. Ulepszaj i ewoluuj.

Nie jest wprost powiedziane, że te 6 zasad należy wprowadzać chronologicznie, Hakan Forss wprost proponuje inną kolejność, ja natomiast uznaję nieco mniej radykalnie, że część tych zasad należy wprowadzać równolegle. A zatem zacznijmy:

WIZUALIZUJ

Zdecydowanie pierwszą zasadą, którą zespół zaczynający pracę Kanbanem powinien wprowadzić, jest wizualizacja. Bez niej nie będziemy w stanie zapanować nad ilością pracy i stworzyć zasad poprawiających pracę. Tutaj zespoły napotykają na pierwsze problemy, które często zniechęcają je do dalszego stosowania Kanbana. Żeby bowiem móc myśleć o usprawnieniach, należy pokazać CAŁĄ i KAŻDĄ pracę zespołu. I nagle okazuje się, że tej pracy obok zadań, które zespół wykonuje „zgodnie z planem”, jest całe mnóstwo:

  • maintenance – czyli uciążliwa utrzymaniówka, która zawsze się jakoś pojawia, a niekoniecznie jesteśmy w stanie ją w całości zaplanować (drobne poprawki, refactoring kodu, wewnętrzne usprawnienia)
  • dodatkowe zadania zlecone przez przełożonych lub osoby decyzyjne z innych obszarów firmy („to zadanie z samej góry, nasz CEO je zlecił”)   
  • drobne prośby mailem, telefonicznie czy na komunikatorze, by sprawdzić bądź coś wykonać („to zajmie ci góra 5 minut”)   
  • koleżeńskie przysługi („no weź nie bądź, rzuć na to okiem”)   
  • spotkania wszelakiego sortu   
  • inne (na pewno ze swojego doświadczenia wymienicie spokojnie jeszcze kilka rodzajów prac, które odciągają was właściwych zadań).

Cały szkopuł tkwi w tym, jak te dodatkowe prace pokazać i po co. Przede wszystkim musimy sobie uświadomić, że większość wymienionych wyżej typów zadań to wrzutki, których chcemy się pozbyć, bo nas rozpraszają i wpływają na naszą efektywność. Wizualizujemy je zatem po to, żeby zobaczyć, ile ich jest, czy faktycznie mają wpływ na naszą zasadniczą pracę, a jeśli tak, to odpowiedzieć sobie na pytanie, jak wyrugować je w możliwie najszybszy sposób.

W zależności od typu pracy zespołu tych wrzutek może być tygodniowo od kilkunastu do nawet kilkuset. Moment! Kilkuset? Przecież wizualizowanie szczegółowo dwustu czy trzystu dodatkowych zadań zabije zapał do Kanbana w każdym! Tak, i właśnie dlatego w pierwszym kroku próbujemy po prostu pokazać, ILE tygodniowo mamy tych wrzutek i jakiego rodzaju. Do tego spokojnie wystarczy stawianie na wspólnej tablicy, wyznaczonym flipie czy zwykłej kartce papieru np. kreski za każdy telefon, kropki za każdy mail z zadaniem, wykrzyknik za wrzutę z „góry”, a spotkania możemy zazwyczaj wyciągnąć z kalendarza. Po dwóch lub trzech tygodniach takiego liczenia mamy już wystarczająco dużo danych, żeby zorientować się, które wrzutki są najczęstsze i najbardziej nam przeszkadzają. Zazwyczaj też pokrywają się one z początkowym rozpoznaniem zespołu, który sam wie najlepiej, co go odrywa od pracy. Cała jednak siła tej minimalnej wizualizacji tkwi w liczbach, faktach, z którymi nie można dyskutować. Co innego gdy zespół skarży się przełożonemu, że jest zawalony pracą, a co innego, gdy pokazuje, że w minionych 3 tygodniach poza zwykłą pracą wykonał 70 zleceń z telefonów, 40 mailowych i musiał wziąć udział w 10 spotkaniach niepoświęconych bezpośrednio ich produktowi, a dodatkowo miał jeszcze 12 wrzut od samego przełożonego. Taka wizualizacja pobudza do refleksji, skłania do zastanowienia, że może jednak warto by było trochę zespół odciążyć, umożliwić im pracę nad tym, co najważniejsze, co zaplanowane, co zlecone przez lidera czy innego managera. I to jest nasz pierwszy krok w implementacji Kanbana, który, żeby było jasne, może potrwać kilka lub kilkanaście tygodni, bo przecież żeby wyciągnąć jakieś wnioski z wizualizacji (o czym niżej), musimy chwilę poobserwować status quo.

ZARZĄDZAJ PRZEPŁYWEM PRAC

Gdy mamy już pomysł na wizualizację, wcieliliśmy go w życie i zaczynamy widzieć nasze procesy pracy, jakieś trendy w rodzajach zadań, możemy przejść do trzeciej zasady i zastanowić się na podstawie zebranych danych, co warto zmienić w pierwszej kolejności w pracy zespołu. To pierwsze usprawnienie powinno nam pomóc w usunięciu najliczniej występujących, najbardziej uciążliwych wrzutek. A gdy już sobie to usprawnienie w zespole ustalimy, próbujemy z nim żyć pierwszy tydzień, drugi tydzień, sprawdzając, czy przynosi efekty, czy liczba wrzutek się zmniejszyła, czy skupiamy się na właściwych zadaniach. Jakie to może być usprawnienie? A chociażby, żeby:

  • co tydzień ktoś inny był dyżurnym i odpowiadał na wszystkie telefony i prośby na komunikatorze,
  • zespół przestał odbierać / wyłączył telefony,
  • przekierowywać osoby z maili do systemu, w którym mamy nasze prace, aby tam założyły zadanie dla nas do normalnego skolejkowania,
  • przełożony przestał wrzucać zadania i dawał odpór innym managerom z wrzutkami
  • wszystkie wrzutki trafiały do przełożonego albo innej osoby, która decyduje o priorytetach prac i może podjąć właściwe decyzje.

WYJAŚNIAJ ZASADY

W tym momencie bardzo ważne jest również wdrożenie w życie czwartej zasady Kanbana dotyczącej transparencji i edukacji otoczenia. Bez zakomunikowania ustaleń zespołu na zewnątrz, bez ambasadora w postaci choćby przełożonego, bez zespołu tłumaczącego zasadę jednym językiem wszystkim zainteresowanym i klientom procesu, nie możemy mieć pretensji do reszty organizacji, że postępuje po staremu i burzy się na nowe porządki. My jako zespół jesteśmy odpowiedzialni za edukowanie reszty firmy, po co wdrożyliśmy dane usprawnienie, pokazując liczby, przyczyny i spodziewane efekty. To zrozumienie jest niezbędne, żeby nasza implementacja Kanbana mogła się udać. A jednocześnie stanowi podwaliny do piątej zasady – wymiany feedbacku w zespole, z osobami spoza zespołu, zleceniodawcami i wreszcie klientami i użytkownikami. Co jednocześnie bardzo ważne – cały zespół powinien tak samo rozumieć zasady, wg których chce pracować, i tak samo je tłumaczyć.

I tu chciałabym się w tym artykule zatrzymać. Rozprawienie się ze wrzutkami, czy przeczyszczenie kolejki zadań, czy uporządkowanie prac zespołu może potrwać. Miesiąc, kwartał, pół roku – w zależności od sprzyjających bardziej lub mniej okoliczności. Z każdym tygodniem, z każdym usprawnieniem będziemy coraz bardziej uszczegóławiać zwizualizowaną listę zadań (zapewne w postaci jakiejś tablicy, będziemy ulepszać przepływ pracy, natykać się i rozwiązywać kolejne problemy. I absolutnie nie należy traktować tego czasu jak straconego, bo te kolejne usprawnienia, te następne zasady porządkujące prace, to właśnie jest nasz początek z Kanbanem. Bardzo niewdzięczny i ciężki do wdrożenia, wymagający ogromnego zaangażowania ze strony zespołu, często przy ogromnym oporze reszty organizacji. Ale gdy już pozbędziemy się przeszkadzaczy, przejdziemy ten chrzest bojowy, to w końcu będziemy mogli skupić się na swojej robocie. I wówczas odkryjemy, że Kanbana można używać nie tylko do wychodzenia na prostą, ale do faktycznego skracania czasu pracy nad zadaniami i szybszego dostarczania wartości klientowi końcowemu, do rozwoju produktu i realizowania najwartościowszych prac. Ale o tym w kolejnym artykule…

 

Jak się miał Agile w 2018?

Na rok odpuściłam sobie lekturę raportu State of Agile wydawanego przez firmę Version One, ponieważ chciałam zobaczyć, czy w perspektywie dwóch lat pojawią się bardziej spektakularne zmiany i interesujące trendy. Ponieważ właśnie pojawił się nowy raport, zapraszam was do subiektywnego przeglądu jego zawartości.

(więcej…)
 

Złodziej czasu – ukryty Work In Progress

Można mieć wrażenie, że złodzieje czasu są dzisiaj plagą. Mamy dostęp do ogromu informacji, miejsc do zobaczenia i rzeczy do zrobienia, a zarazem jakby coraz mniej czasu na to, by działać i doświadczać. W ubiegłym roku podczas konferencji Agile By Example Henrik Kniberg wystąpił ze świetną prezentacją, w którym porusza m.in. temat tego, jak korzystamy z czasu – prywatnie i zawodowo. Całe wystąpienie jest inspirujące, mi natomiast szczególnie mocno utkwiło w pamięci proste i bolesne zarazem stwierdzenie, że wszyscy mamy do dyspozycji dwadzieścia cztery godziny na dobę, ani minuty więcej. Jedni w tym czasie robią mnóstwo ciekawych, wartościowe rzeczy, inni żyją w przekonaniu, że ktoś nieustannie okrada ich z tego czasu właśnie; być może ci pierwsi, skoro mają niesprawiedliwy dostęp do extra godzin – “skąd ty bierzesz na to wszystko czas”? “Z tej samej puli dwudziestu czterech godzin, z której korzystasz ty”, brzmi poprawna odpowiedź. Podobnie jest z zespołami. Część z nich również narzeka, że ktoś wykrada im cenny czas, który mogłyby poświęcić na robienie “tych wartościowych” rzeczy. Mam odpowiedź na pytanie kto – ukryty Work In Progress.
(więcej…)

 

Podstawowe miary w Kanbanie

Podstawowe miary w KanbanieMetryki pomagają podejmować decyzje oraz zrozumieć faktyczny przepływ (flow) prac w zespole i organizacji. Są punktem odniesienia, kiedy chcemy sprawdzić, na ile eksperymenty w zespole, czy próby usprawnień, przekładają się na lepsze efekty. Lead Time, Cycle Time oraz Throughput to podstawowe miary w Kanbanie. Czym są i jak z nich korzystać tak, aby pomagały doskonalić sposób pracy. (więcej…)

 

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.

(więcej…)

 

Jak się miał agile w 2016?

Mniej więcej tydzień temu ukazał się kolejny raport z serii State of Agile będący wynikiem ogólnoświatowej ankiety przeprowadzanej przez VersionOne. Wyniki za rok 2016 nie zawierają spektakularnych niespodzianek czy poważnych zmian. Można raczej mówić o umacnianiu się pewnych trendów lub wycofywaniu się firm z niektórych pomysłów. Poniżej tradycyjnie garść informacji, które wydały nam się najbardziej interesujące. (więcej…)

 
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