Kanban i Scrum często traktowane są jako wykluczające się alternatywy, przez co konieczny ma być wybór, czy użyjemy jednego, czy drugiego. W zależności do tego, jak pracuje Zespół i co ma do zrobienia, powinniśmy jakoby posłużyć się Scrumem albo Kanbanem. A bywają i tacy, którzy sugerują sekwencyjne podejście: najpierw coś wytwarzamy w Scrumie, a potem utrzymujemy Kanbanem. Ewentualnie zaczynamy z niedojrzałym Zespołem w Scrumie (narzucającym sporo reguł), by po pewnym czasie wprowadzić Kanbana (kiedy reguły Scruma zaczną nas ograniczać).
To wszystko niemal prawda, a dokładniej ta trzecia prawda, o której mówił Tischner. I już wyjaśniam, dlaczego tak jest.
Kanban
Kanban wywodzi się z Leana, którego początki wiążą się z systemami produkcyjnymi (uwaga, nie produktowymi, ale produkcyjnymi – wytwarzaniem różnych dóbr). W ogromnym uproszczeniu, za co pewnie dostanę po głowie od znawców Leana, celem jest eliminacja marnotrawstwa i optymalizacja procesu tak, by doprowadzić do optymalizacji kosztów i zysków.
Uwaga: optymalizacja kosztów to nie ich bezwzględne zmniejszenie – nadmierna redukcja kosztów może prowadzić do degradacji jakości i w konsekwencji zaburzenia albo zatrzymania procesu produkcyjnego. Podobnie rozumieć należy maksymalizację zysków – nie może to odbywać się kosztem jakości ani w sposób prowadzący do degradacji samego procesu (zniszczenie narzędzi, skrajne wyczerpanie ludzi itd.).
Marnotrawstwem mogą być rzeczy oczywiste, np. skrawki materiału, użytego do produkcji jakiegoś przedmiotu. Jest nim również koszt magazynowania części wyprodukowanych bez potrzeby, straty spowodowane zamrożeniem kapitału w takich półproduktach czy przestoje spowodowane nieefektywną organizacją pracy. Chodzi o to, żeby robić jak najszybciej to, co jest naprawdę potrzebne, w minimalnej ilości, jakiej teraz potrzebujemy. Aby uzyskać ten efekt, konieczne jest ciągłe usprawnianie procesu, a co za tym idzie jego monitorowanie i wyciąganie wniosków z uzyskiwanych danych.
Tu jako ciekawostkę warto wspomnieć, że Lean ma kuzynkę, jaką jest Teoria Ograniczeń (stanowi ona jedną z podstaw Kanbana). Chętnych dowiedzieć się więcej odsyłam do książek nieżyjącego już niestety Eliyahu Goldratta.
Wracając do Kanbana: jest to strategia optymalizacji wartości poprzez optymalizację procesu, w którym wartość ta jest wytwarzana. Idea jest bardzo prosta: skoro to, co robimy, przynosi wartość w momencie zakończenia prac, im krócej ich wykonywanie trwa, tym więcej wartości w jednostce czasu da się uzyskać. Należy więc doprowadzić do tego, by w procesie zaistniał stan przepływu (ang. flow), czyli by nie dochodziło do niepotrzebnych przestojów. To wymaga ograniczenia liczby rzeczy realizowanych równocześnie do takiego poziomu, przy którym możliwości wytwórcze zaangażowanych w proces ludzi i narzędzi nie zostaną przekroczone.
Zwracam uwagę na to, że Kanban nie jest metodą, tylko strategią, więc nie definiuje konkretnego procesu (zdarzeń, artefaktów, ról, odpowiedzialności itd.). Jest zbiorem zasad i podstawowych praktyk, dzięki którym możliwe jest uzyskanie przepływu.
Zainteresowanych Kanbanem zachęcam do zapoznania się z jego definicją i moimi komentarzami do niej.
Scrum
Metoda powstała jako odpowiedź na pytanie o to, jak ograniczyć ryzyko inwestycyjne przy rozwoju produktów w dynamicznie zmiennym środowisku. Twórcy Scruma zaproponowali, by nie tworzyć długoterminowych projektów, w których z góry definiuje się co, jak i kiedy ma zostać zrobione, ale by użyć empiryzmu i w krótkich iteracjach (Sprintach) dokonywać inkrementalnie małych zmian w produktach.
Najrzadziej raz na miesiąc następuje sprawdzenie wartości tego, co już zostało wytworzone, więc maksymalna strata w przypadku podjęcia błędnych decyzji to koszy miesiąca pracy Zespołu. Daje to też możliwość regularnego potwierdzania i dostosowywania planów rozwoju produktu, co pozwala nadążać za zmianą potrzeb interesariuszy, uwarunkowaniami rynkowymi, ewolucją prawa itd.
Istotą podejścia produktowego zaproponowanego w Scrumie jest skupienie na realizacji tego, co jest niezbędne do osiągnięcia bieżących celów i zaprzestanie prac nad tym, co nie przynosi istotnej wartości. Priorytetem jest przy tym nie tyle płynny proces, ile przede wszystkim optymalizacja wartości tego, co wytwarza Zespół.
W odróżnieniu od Kanbana Scrum definiuje nie tylko zasady, ale też kluczowe elementy procesu: zdarzenia, artefakty i odpowiedzialności. Optymalizacja procesu i wartości odbywa się w trzech ściśle zdefiniowanych pętlach feedbackowych. Jedna związana jest z produktem, druga z procesem, a trzecia z zarządzaniem pracą w ramach iteracji.
Podobnie jak Kanban, Scrum inspiruje się Leanem: nastawiony jest na eliminowanie marnotrawstwa, jakim byłoby robienie mało wartościowych rzeczy. Od Zespołu Scrum wymaga się też dokonywania ciągłych usprawnień sposobu działania, by zwiększać skuteczność, rozumianą jako zdolność do dostarczania tego, czego potrzebują interesariusze wtedy, kiedy jest im to potrzebne.
Oficjalna definicja Scruma to oczywiście Scrum Guide, do którego lektury zachęcam.
Prawo Little’a
Zgodnie z tym prawem średni czas realizacji zleceń jest wprost proporcjonalny do średniej ilości pracy wykonywanej równocześnie (ang. work in progress, w skrócie WIP), a odwrotnie proporcjonalny do średniej przepustowości procesu (w uproszczeniu: jego możliwości wytwórczych). Zwracam uwagę, że to prawo operuje na wartościach średnich, więc nie ma sensu stosować go do pojedynczego zlecenia.
Z prawa Little’a płynie prosty wniosek: jeśli możliwości wytwórcze Zespołu ciężko zmienić w krótkim czasie (a zwykle wymaga to wielu czasochłonnych usprawnień), wtedy im więcej rzeczy Zespół robi naraz (im większy jest WIP), tym dłużej będzie je realizował. Jeśli kolejne zlecenia będą przyjmowane bez zakończenia tych już obsługiwanych, czyli gdy WIP będzie rósł, system przetwarzania zleceń utonie pod nadmierną ilością pracy, która ciągnęła się będzie w nieskończoność.
Stąd idea, by ograniczyć ilość pracy w toku do takiego poziomu, by realnie mogła być przez Zespół wykonywana bez niepotrzebnych przestojów. Taki system w języku angielskim określany jest jako pull system – polskie tłumaczenie jest nieco niezgrabne: system wciągania pracy. Da się w nim uzyskać możliwie niezaburzony i stały przepływ pracy przez proces. A po ludzku: skuteczne kontrolowanie ilości pracy w toku pozwala Zespołowi szybko kończyć to, co już zaczął realizować, bez miotania się pomiędzy dziesiątkami tematów, które ciągną się tygodniami.
Dlatego też kontrolowanie ilości pracy w toku jest jedną z trzech wymaganych praktyk w Kanbanie.
Kontrolowanie WIP-u w Scrumie
Wiele Zespołów pracujących w Scrumie ogranicza ilość pracy w toku, choć metoda tego nie wymaga. Developerzy umawiają się na przykład, że zmiany w produkcie, jakie planują zrealizować przed końcem iteracji, będą wykonywane sekwencyjnie. Lub że nie będą pracować nad więcej niż dwoma zmianami naraz.
Natomiast każdy Zespół, który posługuje się Scrumem, czy tego chce, czy nie, zawsze ogranicza ilość pracy w toku. Spowodowane jest to stałą długością iteracji oraz niezmiennym składem Zespołu w jej trakcie. Niezależnie od sposobu organizacji pracy developerskiej, Zespół może podjąć się realizacji tylko takiej liczby zmian w rozwijanym produkcie, na jaką pozwolą ograniczony czas i dostępność ludzi. To daje szansę na ukończenie prac w rozsądnym czasie (przed końcem iteracji).
To niejawne ograniczenie WIP-u ma zabezpieczyć system realizacji pracy przed utonięciem pod nadmiarem pracy, ale też ma spowodować, że w krótkim czasie pojawią się zmiany w produkcie, które możną będzie poddać ewaluacji pod kątem wartości. Gdyby Sprinty ciągnęły się w nieskończoność, szansa na uzyskanie czegoś namacalnego, dającego się zweryfikować i poddać walidacji, byłaby dużo mniejsza.
„Sprinty nas ograniczają”
Są Zespoły, które decydują się na porzucenie Scruma ze względu na „uwierające granice Sprintów”. Uważają, że arbitralne przerywanie pracy tylko dlatego, że kończy się iteracja, jest niepragmatyczne. I postulują, by zacząć pracować w Kanbanie, bo tam takich „sztucznych ograniczeń” nie będzie. Cóż, trafiają kulą w płot.
Po pierwsze, będą musieli sami zdefiniować proces, którym się posłużą. Kanban nie określa żadnych zdarzeń, ról, ani odpowiedzialności, nie wymaga też tworzenia żadnych artefaktów, co nie oznacza, że Zespół nie będzie musiał o to zadbać. Musi przecież stworzyć definicję przepływu pracy (ang. workflow), w tym obowiązujące w niej reguły (ang. policies). Jeśli tego nie zrobi i ograniczy się do sporządzenia na odczepnego jakiejś tablicy kanbanowej, to zamiast pragmatyzmu nastąpi chaos, a z Kanbanem nie będzie to miało nic wspólnego poza pozorami.
Po drugie, jeśli Zespół użyje Kanbana prawidłowo, wtedy będzie kontrolował WIP, by zabezpieczyć proces przed nadmiarem pracy. I mimo braku iteracji wciąż będzie musiał dążyć do jak najszybszego zakończenia już rozpoczętych prac, bo tylko wtedy możliwe stanie się podejmowanie nowych tematów. Jeśli development będzie nieefektywny, kolejka wejściowa do procesu zacznie się szybko rozrastać. No, chyba że Zespół zdecyduje się na nieustanne powiększanie WIP-u – wtedy pogrąży się w chaosie i niczego już nie będzie w stanie ukończyć w sposób przewidywalny.
Mówiąc wprost, granice Sprintów w Scrumie uwierają wiele Zespołów ze względu na nieumiejętność racjonalnego planowania, a potem skutecznego organizowania swojej pracy przez Developerów. Ucieczka od Scruma do Kanbana nic w takiej sytuacji nie da, bo istniejące problemy objawią się ponownie w inny sposób.
Oczywiście wiele Zespołów tej migracji dokonuje od Scruma nie do Kanbana, tylko do „Kanbana” (celowy cudzysłów), czyli posługuje się jedynie częścią praktyk kanbanowych bez jakiejkolwiek kontroli WIP-u i nie zamierza dążyć do uzyskania przepływu. Ich faktycznym celem jest spowodowanie, by nie było widać, jak bardzo są nieefektywne.
Nie stawiam przy tym tezy, że odejście od Scruma i sięgnięcie po Kanban w połączeniu z jakimś innym procesem nie ma nigdy sensu. Jeśli Zespół nie zajmuje się rozwojem jakiegoś produktu (jakkolwiek szeroko rozumianego) lub usługi, Scrum może zupełnie nie pasować do charakteru wykonywanej pracy, a wtedy rezygnacja z niego jest najbardziej logiczną decyzją.
„Scrum to metoda produktowa, Kanban służy do wykonywania powtarzalnych prac”
To nieporozumienie wynikające z naszego przyzwyczajenia do tego, jak Scrum i Kanban bywają używane. Nie ma żadnych przeszkód, by przy pomocy Kanbana budować produkt i wiele Zespołów to robi. Muszą oczywiście zadbać o zdefiniowanie procesu, jakim będą się posługiwać i w praktyce często powstaje coś, co bardzo przypomina Scruma.
Z drugiej strony powtarzalne prace da się wykonywać z użyciem Scruma, choć może okazać się, że niektóre z jego mechanizmów nie będą przydatne. Nie chodzi tu przy tym o charakter prac (czy one są powtarzalne, czy nie), ale raczej o możliwość dokonywania wyboru pracy, jaką wykonamy. Już wyjaśniam, co mam na myśli.
Jeśli spośród zbioru rzeczy, które potencjalnie można zrobić, wybierane są te, które faktycznie zrobimy (bo przyniosą największą korzyść), to nawet jeśli jest to praca powtarzalna, Scrum będzie miał nadal sens. Ma bowiem zdarzenia, w ramach których ustala się, co robić a czego nie robić, ma też Product Ownera, który podejmuje decyzje odnośnie do tego, co i w jakiej kolejności będzie realizowane.
Jeśli natomiast każde zlecenie trzeba wykonać i jedyne, czym da się żonglować, to kolejność, w jakiej zostaną one zrealizowane, wtedy elementy Scruma zdefiniowane po to, by pomóc w selekcji wartości (i odrzuceniu tego, co mało wartościowe), nie będą potrzebne. Przy czym na upartego nadal da się Scruma do tego użyć, nawet jeśli Kanban skojarzony z jakimś prostym procesem obsługi zleceń w tym przypadku byłby bardziej naturalnym wyborem.
Wspólnota pracy
Tym, co różni Scrum od Kanbana, jest podejście do kwestii wspólnoty pracy Zespołu, a dokładniej do tego, czy jest ona potrzebna (i w ogóle może zaistnieć), czy nie. Scrum opiera się o założenie, że do rozwiązania złożonego problemu trzeba połączyć różne kompetencje kilku osób, a praca jest na tyle złożona i jest jej na tyle dużo, że jeden człowiek zazwyczaj nie zdoła sam jej wykonać. Tak jest z reguły w przypadku budowania złożonych produktów (np. oprogramowania) i stanowi to drugi powód, dla którego Scrum dobrze do takich zastosowań pasuje.
Kanban wspólnoty pracy nie wymaga, ale jej nie zabrania. Są też praktyki kanbanowe, które opierają się o pracę zespołową, np. swarming, który polega na skupieniu wszystkich osób nad jednym tematem po to, by usunąć jakąś blokadę uniemożliwiającą zakończenie prac.
Jeśli praca, jaką wykonuje Zespół, polega na realizacji zleceń, które trzeba wykonywać jednoosobowo, albo wręcz wymagana jest specjalizacja (wymuszona np. prawem) – wtedy Scruma ciężko do tego użyć. Bez problemu można natomiast użyć w tym przypadku Kanbana, a dokładniej zastosować go jako strategię optymalizacji procesu, który wykorzystywany jest zamiast Scruma.
Przykładem takiego środowiska jest grupa administratorów systemów informatycznych, którzy obsługują zlecenia serwisowe (np. zakładają konta w różnych systemach, instalują oprogramowanie itd.). Zresetowanie komuś hasła lub nadanie uprawnień dostępowych do jakiejś usługi raczej nie wymaga pracy zespołowej tych ludzi. Do tego nie mogą oni wybierać, które zlecenia obsłużą, a które zignorują, uznając ich realizację za nieopłacalną.
To znacząco różni się od grupy prawników, którzy na zlecenie klientów (dużych korporacji) opracowują wspólnie skomplikowane umowy handlowe. Prawdopodobnie każdy z członków tego Zespołu będzie znał się na innych aspektach prawa, ale dopiero połączenie wiedzy ich wszystkich pozwoli stworzyć taką umowę lub kontrakt, jakiego oczekują kliencie.
Możliwości planowania iteracji
Czasami mówi się, że Scrum nie nadaje się do procesów wymagających pracy ciągłej. Przykładem może być obsługa klientów czy rozwiązywanie błędów zgłoszonych przez użytkowników jakiegoś produktu. Żeby zaplanować iterację, Zespół musiałby przewidzieć, jakie błędy zostaną zgłoszone, a to przecież niemożliwe. Dlatego trzeba to tego typu prac użyć Kanbana, który pozwala planować just-in-time.
Tyle że to nie do końca prawda. Scrum też pozwala planować w znacznym stopniu na bieżąco, bo jedyną rzeczą niezmienną w Sprincie jest Cel Sprintu (powód, dla którego realizowana jest iteracja). Niekoniecznie na początku Sprintu musi być ustalone w detalach co, jak i kiedy zostanie zrobione – wiele takich decyzji podejmuje się już w trakcie iteracji.
Niemniej jeśli Zespół miałby wyłącznie naprawiać błędy, Scrum faktycznie nie musi być dobrym wyborem. Nałożenie praktyk kanbanowych na jakiś prosty proces obsługi takich zgłoszeń wydaje się mieć większy sens. Przy czym może spowodować wyspecjalizowanie się w naprawianiu marnego produktu, podczas gdy dla organizacji lepiej byłoby doprowadzić produkt do stanu, w którym ilość błędów będzie minimalna. A do tego Scrum, wymuszający skupienie na wartości produktu, może być jednak skuteczniejszą metodą.
I tu ważna uwaga: zamiast odejścia od iteracji (i Scruma) na rzecz systemu pracy ciągłej i planowania just-in-time, czasem wystarczy po prostu zastosować krótkie Sprinty. Jeśli Zespół musi szybko reagować na napływające pilne zgłoszenia, których nie jest w stanie przewidzieć, posłużenie się miesięcznymi czy choćby dwutygodniowymi iteracjami nie wchodzi w grę. Gdyby jednak użyć Sprintów kilkudniowych (np. tygodniowych), wtedy można regularnie pobierać z kolejki zgłoszeń te aktualnie najpilniejsze. Proces będzie wystarczająco responsywny, a jednocześnie zapewni Zespołowi dużo większą stabilność i możliwość planowego działania, niż systemy pracy ciągłej.
Czy niezbędna jest dojrzałość Zespołów?
Zarówno Scrum, jak i Kanban mogą być użyte przez całkowicie niedoświadczone Zespoły. Oczywiście początki będą trudne i warto, by Zespoły dostały solidne wsparcie. I tu faktycznie objawia się różnica między Scrumem a Kanbanem.
W Scrumie zdefiniowana została odpowiedzialność Scrum Mastera, który ma obowiązek zadbać o skuteczność działania Zespołu, dostarczyć wiedzy o stosowanej metodzie, a także zapobiegać próbom ukrycia problemów pod dywanem i przejścia nad nimi do porządku dziennego. Do tego Scrum Guide opisuje zręby procesu, co zwalnia Zespół z konieczności definiowania wszystkiego samodzielnie.
W Kanbanie nie ma osoby będącej odpowiednikiem Scrum Mastera, przez co odpowiedzialność za skuteczność działania rozkłada się na cały Zespół. Jest niezerowe ryzyko, że nie będzie wtedy realizowana. A z racji tego, że Kanban nie określa, jaki powinien być proces, Zespół będzie musiał sam go zdefiniować albo sięgnąć po jakąś gotową metodę. Niedojrzały Zespół mający nikłą wiedzę o Kanbanie może sobie z tym nie poradzić.
Kluczowa jest przy tym nie sama dojrzałość, co samodyscyplina członków Zespołu. Bez chęci zrobienia czegoś sensownego i dbania o sposób pracy ani Scrum, ani Kanban w połączeniu z jakimś innym procesem, rzadko dają wymierne korzyści.
Scrum suplementowany praktykami kanbanowymi
Domykając klamrę, napiszę o łączeniu Scruma z Kanbanem. Istnieje wiele Zespołów, które korzystają ze Scruma, ale dołożyły do niego praktyki zaczerpnięte z Kanbana. Przykładem takiej praktyki może być organizacja pracy Developerów z użyciem tablicy kanbanowej, na której zwizualizowany jest proces, zdefiniowane są reguły oraz sposób kontrolowania WIP-u. Innym przykładem jest posługiwanie się miarami przepływu do aktywnego zarządzania pracą w toku.
Powstał nawet Kanban Guide for Scrum Teams, do którego lektury namawiam. Wynika z niego wyraźnie, że nie istnieje żadna sprzeczność między Scrumem a Kanbanem.
Czemu o tym piszę? Bo funkcjonuje przekonanie, że połączenie Scruma z Kanbanem polega na wybraniu z jednego i drugiego tylko niektórych elementów. Co znamienne, przy tej selekcji prawie zawsze ze Scruma wywalane są Sprinty, a z Kanbana kontrola nad WIP-em, czyli eliminowane są oba alternatywne mechanizmy zabezpieczające proces przed utonięciem pod nadmiarem pracy. Taki twór jest w istocie czymś mało efektywnym, choć jeśli ktoś chce, może tak pracować – byleby nie nazywał tego ani Scrumem, ani Kanbanem.
Czy to Scrumban?
Ciężko jednoznacznie odpowiedzieć.
Scrum jest metodą ramową, czyli absolutnie minimalistycznym zbiorem zasad i elementów, które umożliwiają empiryczną kontrolę nad procesem rozwoju produktu. Usunięcie z niej czegokolwiek nie musi, ale prawie na pewno będzie skutkować wyrugowaniem empiryzmu.
Kanban to strategia zdefiniowana w równie minimalistyczny sposób, przez co usunięcie z niego czegokolwiek bez negatywnych skutków wydaje się mało rozsądne, choć nie musi być katastrofalne w skutkach.
Niektórzy wybiórczy zestaw elementów Scruma i Kanbana rzeczywiście określają nazwą Scrumban, mimo że wtedy ani ze Scrumem, ani z Kanbanem nie ma to nic wspólnego. No, poza nazwą właśnie, która jest w istocie pustą obietnicą.
Inni, w tym ja, utożsamiają Scrumban wyłącznie z połączeniem poprawnie użytego Scruma z równie prawidłowo stosowanym Kanbanem. Nazwa nie jest już wtedy pustą obietnicą, bo tak rozumiany Scrumban jest zarówno Scrumem, jak i Kanbanem.
Są też osoby przekonane, że istnieje osobna metoda Scrumban, która ma swoją definicję. Przy czym takich konkurujących ze sobą definicji jest kilka, a twórca i fani każdej z nich upierają się, że ta ich jest jedyną słuszną.
Mniejsza o nazwę. Ważne, że Scrum i Kanban doskonale się uzupełniają i da się je połączyć. Każdy, kto utrzymuje, że jest inaczej, w najlepszym razie nie ma dostatecznej wiedzy, a być może kieruje się jakimiś uprzedzeniami. Ewentualnie ma do zaoferowania „jedynie słuszne” podejście, ze sprzedawania którego się utrzymuje…
Zanim wybierzesz
Przede wszystkim nie musisz wybierać między Scrumem a Kanbanem – da się użyć obu na raz. A jeśli już wybierasz, upewnij się, że robisz to świadomie. Co brać pod uwagę przy podejmowaniu decyzji? Oto kilka pytań, które warto sobie zadać:
- Co jest celem? Optymalizacja wartości? Optymalizacja procesu? Obie te rzeczy?
- Czym zajmuje się Zespół? Realizacją zleceń? Rozwojem produktu lub usługi? Obiema tymi rzeczami naraz?
- Jak pracuje Zespół? Konieczna jest wspólnota pracy? Jak wygląda typowy przebieg prac, które wykonuje Zespół?
- Czy dokonywana jest selekcja tego, co będzie robione, czy nie? Czy można jakoś wpłynąć na to, co zlecane jest Zespołowi, czy nie?
- Czy da się zaplanować choćby krótką iterację? Jak i kto zarządza zleceniami? Ja często zmienia się kolejka tych zleceń?
- Dla kogo pracuje Zespół? Jak potwierdzana jest wartość będąca efektem jego pracy?
- Jakich zdarzeń w procesie potrzeba, by działał empiryzm? Jakie pętle empiryczne są w ogóle potrzebne? Jak często trzeba dokonywać sprawdzeń i dostosowań?
- Czym jest marnotrawstwo w rozumieniu tego, co robi Zespół? Co jest miarą tego marnotrawstwa? Jakich mechanizmów potrzeba, by marnotrawstwo eliminować?
Mając odpowiedzi na te pytania (i kolejne, które wyłonią się w trakcie), często i tak trzeba po prostu eksperymentować. Prawdopodobnie z różnych perspektyw czasami Scrum a czasami Kanban (w połączeniu z jakąś inną metodą) wyda się lepszym wyborem. Z czymś należy zacząć, pozostawiając sobie otwartą drogę do zmiany. Przy czym dokonując jej, warto pamiętać o paru kwestiach:
- Powodem ma być dążenie do uzyskania nowych możliwości, a nie ucieczka od problemów lub chęć uczynienia ich niewidocznymi.
- Nie powinno się zmieniać metody, jeśli nie wyczerpały się możliwości rozwiązania w niej problemów, z którymi boryka się Zespół.
- Migrujmy do innej metody dopiero wtedy, gdy potrafimy bardzo efektywnie użyć tej stosowanej aktualnie i przestaje nam ona wystarczać, albo wręcz zaczyna nas ograniczać.
- Nie zwlekajmy natomiast z migracją, jeśli aktualnie stosowana metoda jest niewłaściwa i potrafimy tego bezsprzecznie dowieść.
Dwa ostanie punkty są kluczowe. Wiele Zespołów decyduje się na skakanie między różnymi metodami tak często, że w praktyce potencjału żadnej z nich nie ma szans ani doświadczyć, ani wykorzystać. Ciężko więc powiedzieć, że dokonują świadomego wyboru opartego o miarodajną ocenę tego, co działa dobrze, a co wymaga zmiany.