Blog

W poprzednim artykule o związkach Scruma z Kanbanem zająłem się tym, co łączy te dwa narzędzia. Zgodnie z obietnicą pora przyjrzeć się różnicom.

Metoda i strategia

Scrum to ramy postępowania (ang. framework), a Kanban to strategia. Pochylmy się na moment nad znaczeniem obu tych pojęć.

Framework

Po polsku to ramy postępowania lub metoda ramowa, czyli zbiór elementów oraz zasad posługiwania się nimi w taki sposób, by zadziałała jakaś kluczowa mechanika lub zjawisko, przynosząc wymierne korzyści. Stąd płyną dwa wnioski:

1. Metod ramowych używa się zawsze po coś i sensownym celem nie może być samo ich stosowanie.
2. Użycie frameworku w sposób sprzeczny z jego definicją będzie marnotrawstwem, jeśli kluczowa mechanika lub zjawisko będące jego podstawą nie ma z tego powodu szans zadziałać.

Kluczową mechaniką w Scrumie jest empiryzm, którego skuteczne zastosowanie pozwala na lepsze radzenie sobie z niestabilną złożonością. W dalszej konsekwencji rosną szanse na wytworzenie wartościowych produktów i usług, a następnie ich długotrwałe rozwijanie w zmiennym środowisku. I właśnie to jest w sumie jedynym sensownym celem, dla którego organizacje i Zespoły w nich funkcjonujące sięgać powinny po Scruma.

Przy czym nie jest to kompletny proces, a jedynie jego szkielet. Użytkownicy Scruma muszą samodzielnie dobrać praktyki, narzędzia i techniki, którymi będą się posługiwać. W ten sposób powstaje specyficzna metoda pracy konkretnego Zespołu Scrum.

I tak np. Scrum Guide opisuje zdarzenia, które w określonej sekwencji mają wystąpić w trakcie Sprintu. Określa, jaki jest ich maksymalny czas trwania, kim powinni być uczestnicy i do jakiego celu mają oni dążyć. Nie wskazuje natomiast konkretnego sposobu realizacji żadnego z tych zdarzeń ani nie wymaga zastosowania określonych praktyk itd. Wszystko to pozostaje w gestii Zespołu Scrum.

Strategia

To sposób postępowania (a czasami plan działania) pozwalający na osiągnięcie jakiegoś celu długoterminowego lub takiego, do którego dąży się w sposób potencjalnie nieskończony. Strategia może, podobnie jak metoda ramowa, opierać się o jakąś kluczową mechanikę lub zjawisko, ale istnieją też strategie związane z kodeksem wartości, zbiorem zasad, a nawet jakimiś fundamentalnymi założeniami, które wciąż wymagają potwierdzenia (nie zostały w pełni dowiedzione).

Kanban to strategia optymalizacji wartości kreowanej przez jakiś proces na skutek uzyskania stanu przepływu w tym procesie. Ów stan przepływu to zjawisko płynnego przemieszczania się nośników wartości przez proces od punktu rozpoczęcia prac nad czymś do momentu ich zakończenia.

Strategia nie definiuje zwykle żadnego procesu ani nawet jego zrębów, a jedynie zasady, jakimi należy kierować się przy tworzeniu tego procesu i późniejszym użytkowaniu. Jeśli nawet w ramach strategii wymagane jest posłużenie się określonymi praktykami, to są one zdefiniowane również w bardzo generyczny sposób.

Przykładem takiej praktyki może być wymóg kontrolowania ilości pracy w toku (ang. work in progress, w skrócie WIP) w Kanbanie. Kanban Guide wyjaśnia, dlaczego jest to niezbędne i jakie korzyści z tego płyną, ale nie narzuca żadnego sposobu implementacji tej praktyki.

Co wynika z tej różnicy?

Kanban może być zastosowany jako strategia optymalizacji przepływu w dowolnym procesie nastawionym na kreowanie szeroko rozumianej wartości. Można więc go użyć jako strategii także i w Scrumie.

Zastosowanie Scruma jest dużo bardziej ograniczone (co nie oznacza, że jest małe), bo konieczne jest posługiwanie się procesem zgodnym z wymogami frameworku, żeby zmaksymalizować korzyści płynące z posługiwania się empiryzmem.

Natomiast dzięki temu, że dla Scruma zdefiniowany został szkielet wymaganego procesu, można posłużyć się nim wprost bez konieczności sięgania przy tym po inne metody. Oczywiście ten brak konieczności łączenia Scruma z innymi metodami nie oznacza, że nie można ani nie warto tego zrobić. Jeśli tylko nie prowadzi to do łamania zasad Scruma, każda fuzja metod dająca pozytywne rezultaty jest dobrym pomysłem.

W odróżnieniu od Scruma Kanban zawsze wymaga posłużenia się jakąś metodą pracy, choćby samodzielnie ukształtowaną, bo jako strategia jest nakładany na istniejące już procesy celem ich optymalizacji. I mimo że istnieje coś takiego jak Metoda Kanban (ang. Kanban Method), która jest pewną propozycją implementacji praktyk kanbanowych, to wciąż stanowi ona uzupełnienie używanego przez Zespół procesu, a nie definiuje go od podstaw.

Powody użycia

Subtelna i zarazem istotna różnica między Scrumem a Kanbanem leży w obszarze celów, które powodują (a przynajmniej powinny powodować), że Zespoły sięgają po każde z tych narzędzi.

W przypadku Scruma, o czym już pisałem powyżej, celem jest wytworzenie wartościowego produktu i poradzenie sobie z niestabilną złożonością, która będzie to utrudniać. Można więc powiedzieć, że każdy Zespół posługujący się tym frameworkiem ma zupełnie inny cel (bo tworzy różne produkty), ale charakter wszystkich tych celów jest taki sam: dostarczyć wartościowe rozwiązanie interesariuszom, a w tej grupie przede wszystkim użytkownikom produktu.

Natomiast niezależnie od tego, czym zajmują się Zespoły sięgające po Kanban, robią to z jednego powodu: chcą zoptymalizować swój proces, aby po zaistnieniu w nim przepływu uzyskać maksymalną możliwą wartość w zamian za wykonywaną pracę. Przy czym miarą tej wartości nie jest liczba zrealizowanych rzeczy, ale zdolność do uzyskiwania tego, co jest potrzebne, wtedy, kiedy jest to potrzebne i to sposób w dostatecznie przewidywalny (pozostający pod kontrolą).

A zatem jeśli Zespół chce wytworzyć i rozwijać wartościowy produkt w sposób przynoszący maksymalne korzyści, to powinien sięgnąć po oba narzędzia. Inaczej mówiąc, mimo że powody stosowania Kanbana i Scruma są różne, to dopełniają się wzajemnie.

Empiryzm

Kolejna różnica, tym razem istotna, to zastosowanie empiryzmu w Scrumie, bez którego metoda przestaje mieć sens, a którego Kanban dla odmiany nie wymaga.

Oznacza to, że Kanban może być z powodzeniem zastosowany przez Zespoły, które posługują się tradycyjnymi metodami projektowymi i dążą do optymalizacji przepływu w nich. Nie jest bowiem prawdą, że stan przepływu da się osiągnąć wyłącznie dzięki Agile – już prędzej jest na odwrót, czyli dobry flow sprzyja zwinności, choć jej nie zapewnia.

Natomiast próba fuzji klasycznych metod projektowych ze Scrumem prowadzi do logicznej sprzeczności, którą można podsumować takim oto bełkotem: „ponieważ niestabilna złożoność nie pozwala na skuteczne planowanie i prognozowanie długoterminowe, sięgamy po Scruma, aby za jego pomocą zrealizować plany sporządzone z góry na początku projektu”.

Praca iteracyjna

Kolejna kwestia, będąca echem opisanej powyżej różnicy: Kanban nie wymaga pracy iteracyjnej, która jest integralną częścią mechaniki Scruma (bez iteracyjności i inkrementalnego podejścia do rozwoju produktu nie sposób posłużyć się empiryzmem).

Nie oznacza to bynajmniej, że iteracje są zakazane w Kanbanie – mogą być wykorzystane jako ułatwienie w zarządzaniu przepływem. Przy czym to bzdura, że brak iteracji w Kanbanie umożliwia robienie rzeczy w nieskończoność – byłoby to objawem braku przepływu, czyli czymś fundamentalnie sprzecznym z celem Kanbana jako strategii.

I na wszelki wypadek podkreślę, że robienie czegoś w nieskończoność to brak przepływu, co może wydawać się nieintuicyjne, bo zwyczajowo z takim brakiem kojarzymy bezczynność. Tymczasem to nie ciężka praca Zespołu świadczy o przepływie, ale wymierne przybliżanie się do zakończenia prac i uzyskania dzięki temu korzyści. Jeśli ciężka praca nie prowadzi do żadnej zmiany stanu faktycznego, takie dreptanie w miejscu to nie tyle przepływ, ile wir…

Źródła pracy dla Zespołu

Scrum posługuje się specyficznym artefaktem (Backlogiem Produktu) do zarządzania kolejką wejściową do procesu. Kanban niczego nie wymaga w tej kwestii poza obowiązkiem jasnego zdefiniowania, czym będą nośniki wartości, które przepływają przez proces i jakie są zasady rozpoczynania pracy nad nimi.

Scrum jest więc niewątpliwie mniej elastyczny, ale wynika to wprost z przyczyn, dla których metoda w ogóle powstała – co prowadzi do kolejnej różnicy w stosunku do Kanbana.

Obszar zastosowania

Otóż Scrum jest metodą produktową, a zatem przeznaczony jest dla Zespołów, które rozwijają produkty lub usługi poprzez ich udoskonalanie (modyfikowanie) w szeregu iteracji.

Kanban może być użyty w połączeniu z każdym procesem, który nastawiony jest na generowanie wartości w wyniku wykonywania jakiejś pracy. Nie musi to być rozwój produktu – równie dobrze może chodzić o obsługę klientów, wykonywanie jakichś prac serwisowych itd.

Przy okazji raz jeszcze zwracam uwagę na to, że Kanban jest strategią, a nie metodą – konieczne jest zdefiniowanie jakiegoś procesu, w ramach którego ta obsługa klientów lub prace serwisowe się odbywają.

Wspólnota pracy

Ostatnia różnica, o której chcę napisać, dotyczy potrzeby istnienia wspólnoty pracy.

Kanban jej nie wymaga i może być zastosowany przez Zespół, w którym co do zasady ludzie nie pracują nad niczym wspólnie, a jedynie koordynują swe działania tak, by nie utonąć pod nawałem roboty.

Scrum dla odmiany zakłada, że ludzie tworzący Zespół potrzebują wspólnoty pracy, bo dzięki niej łączą posiadane kompetencje i potrafią razem poradzić sobie z problemami, które byłoby trudne lub niemożliwe do rozwiązania przez jedną osobę.

Oczywiście Kanban wspólnoty pracy nie zabrania – wszystko zależy od Zespołu, a czasami od procesu, jakim się on posługuje i na który Kanban jako strategia jest nałożony.

Mity, nieporozumienia i bzdury

Prawie każda wzmiankowana przeze mnie różnica między Kanbanem i Scrumem zaowocowała powstaniem mitu lub bredni, na których masę można natknąć się w Internecie, a czasami i w książkach.

Najbardziej bolesnym jest ten głoszący konieczność dokonania wyboru: albo Kanban, albo Scrum. Uważny czytelnik bez trudu zauważy, że taka alternatywa jest z gruntu fałszywa. Nad przyczynami powstania tego mitu spuśćmy litościwie zasłonę milczenia, bo jest ich wiele i to mało chwalebnych.

Innym szkodliwym mitem jest przekonanie, że jeśli Zespół ma do zrobienia coś dużego, czego nijak nie da się upchnąć w krótkie Sprinty, to naturalnym wyborem dla niego jest Kanban. Ja zawsze wtedy pytam o proces, jaki w tym Kanbanie będzie używany. I jeśli słyszę, że „będziemy po prostu używać Kanbana”, to już wiem, że dobrze się to nie skończy. Dlaczego?

Jeśli ta duża rzecz do zrobienia to zmiana w produkcie, zakopanie się w jej realizacji na wiele tygodni jest karkołomnym pomysłem. Skąd teza, że w ogóle da się to zrobić? Skąd przekonanie, że warto to robić? Krótkie Sprinty w Scrumie mają za zadanie między innymi doprowadzić Zespół do szybkiego potwierdzenia, że rozwój produktu zmierza w dobra stronę. Ucieczka do „po prostu Kanbana” usuwa ten mechanizm ograniczania ryzyka inwestycyjnego i decyzyjnego, nie dając nic w zamian.

Poza tym, jak takie podejście („robimy coś ciągiem tak długo, aż skończymy”) ma się do kanbanowej optymalizacji przepływu? W prawdziwym Kanbanie taką dużą rzecz też należy podzielić na kawałki i zadbać o szybki przepływ (a zatem krótki czas trwania prac) dla każdej z nich.

Jeśli Zespół zdecyduje się realizować dużą rzecz w całości, będzie to trwało w nieskończoność. A im dłużej będzie robione, tym większe będzie ryzyko, że coś w trakcie prac spowoduje ich zatrzymanie. Lub że pojawi się coś pilniejszego, czym trzeba będzie się zająć najpierw i Zespół zacznie tonąć w coraz większej ilości zaczętej, ale wciąż nieukończonej pracy… – a czym się to kończy, obrazuje doskonale prawo Little’a, jakie opisywałem jakiś czas temu.

Poza tym Kanban wymaga określenia oczekiwanego poziomu obsługi (ang. service level expectation, w skrócie SLE) i dążenia do jego dotrzymywania, co nijak nie pasuje do „robienia czegoś ciągiem tak długo, aż skończymy”.

Jeśli Zespół rozwijający produkt zechce posłużyć się Kanbanem z jakimś samodzielnie zdefiniowanym procesem, to przyjmując, że faktycznie będzie optymalizował przepływ i dbał o kreowanie wartości, dojdzie ciężkim wysiłkiem chłopa i robotnika do sposobu pracy bardzo zbliżonego lub wręcz tożsamego ze Scrumem. Więc po co wymyślać koło na nowo? Nie znam dobrej odpowiedzi na tak postawione pytanie.

Scrum w połączeniu z Kanbanem

Kanban i Scrum mogą być użyte równocześnie ze względu na szereg podobieństw, o których pisałem w poprzednim artykule i specyfikę różnic, które nie prowadzą do wzajemnego się wykluczenia.

O tym, jak takie połączenie wygląda w praktyce, jakimi zasadami należy się przy tym kierować i kiedy ma to sens, piszę w artykule kolejnym.

A na koniec chcę podzielić się pewną refleksją.

Brak wiedzy dużo kosztuje

Bardzo często (zbyt często!) odkrywam w rozmowach z osobami deklarującymi, że używają Scruma albo Kanbana, iż tak naprawdę mają znikomą wiedzę o tych narzędziach. Przy czym częściej zdarza się to w przypadku Kanbana – wiele osób bywa zaskoczonych, że nie wystarczy stworzyć tablicę i wprowadzić limity WIP, aby twierdzić, że „oto jest Kanban”. A jeszcze bardziej dziwią się, gdy słyszą, że limity WIP wcale nie są obowiązkowe w Kanbanie…

Ta niewiedza ma dewastujące skutki. Jednym z nich jest duża podatność na podszepty różnych szamanów, którzy zarabiają na sprzedawaniu swoim ofiarom „jedynie słusznego podejścia”, dzięki któremu nagle Zespół stanie się efektywny, marnotrawstwo zniknie itd. Oczywiście żaden profesjonalny trener lub konsultant zajmujący się Scrumem czy Kanbanem takich kocopołów nie opowiada, ale nie zawsze trafimy na etycznego doradcę.

Innym skutkiem jest pochopne podejmowanie decyzji o zmianie sposobu pracy w przekonaniu, że to pozwoli cokolwiek robić lepiej. Jeśli Zespół Scrum, który boryka się z użyciem tej metody, porzuci ją na rzecz kulawego pseudo-Kanbana, dość szybko pogrąży się w chaosie. Trzeba bowiem naprawdę dużej samodyscypliny i niezłych kompetencji, by zacząć samodzielnie kształtować proces i optymalizować przepływ w nim. Szanse, że podoła temu Zespół, który nie poradził sobie z użyciem Scruma (metody prostej, mającej dostępną literaturę, która została przez tysiące organizacji sprawdzona), są bliskie zeru.

Dlatego zachęcam, namawiam, napominam: jeśli z czegoś korzystacie, postarajcie się zdobyć choćby podstawową wiedzę na ten temat. To zwiększy szansę na sukces albo przynajmniej ograniczy ryzyko nierozsądnego porzucania narzędzia dlatego, że jakimś cudem nie zadziałała magia i nie rozwiązało ono z dnia na dzień wszystkich problemów.