Kiedy wybrać Scrum, a kiedy Kanban?

Wszystkie metody, praktyki i techniki należące do rodziny Agile opierają się o te same pryncypia: mechanizm empiryczny, Manifest Agile oraz 12 Zasad Zwinnego Tworzenia Oprogramowania.

Najważniejszym jest tu istnienie mechanizmu empirycznego – wszystko, co zostało w 2001 roku zawarte w Manifeście i Zasadach wywodzi się właśnie z niego (a wiele metod bazujących na empiryzmie, jak Scrum, XP, Crystal czy Kanban istniało wiele lat wcześniej, nim ukuto termin Agile).

Mechanizm empiryczny składa się z trzech elementów: inspekcji (sprawdzamy jaki jest stan faktyczny), adaptacji (dostosowujemy się, żeby lepiej osiągać cel), przejrzystości-transparencji (zapewnienia, że działamy na prawdziwych danych). Często opisuję go jak termostat – wyobrażamy sobie mechanizm z pokrętłem, który mierzy temperaturę w pomieszczeniu (inspekcja), dostosowuje ją do temperatury zadanej (podnosi, obniża – adaptacja) oraz działa w przejrzystych warunkach (np. nie kładziemy na nim mokrego ręcznika zaburzającego odczyty).

Potrzebujemy empirii przy budowaniu produktów, ponieważ dziedzina produkcji oprogramowania jest złożona – trudno przewidzieć wiele rzeczy, zmiany następują szybko, wymaga dużej wiedzy, często też znamy postawione cele, ale istnieje wiele dróg ich osiągnięcia (technologicznie, biznesowo itd.), a my chcemy je eksplorować, by wybierać te efektywne i maksymalizujące wartość. Nie możemy usztywniać się na realizacji planów rozpisanych na zbyt daleko do przodu, bo wiele czynników zmieni się, a wiele innych nie umiemy nawet dziś przewidzieć.

Dlatego każda metoda czy technika agile’owa jest: empiryczna, inkrementalna (przyrostowo dodaje wartość w produkcie), i iteracyjna (ma stałe cykle pracy). Dzięki tym trzem cechom, produkty budowane w sposób zwinny, mogą być zmieniane i dostosowywane w częsty, acz przemyślany i umotywowany biznesowo sposób.

Czym się charakteryzuje Scrum?

Obecnie istnieje ponad sto różnych metod i narzędzi pod wspólną etykietką Agile. Najpopularniejszym wg badań VersionOne jest Scrum (lub Scrum łączony z innymi metodami, jak np. ScrumXP), z którego korzysta ponad 60% badanych organizacji. Scrum jest metodą ramową, która porządkuje nieco proces budowania złożonych produktów. Nie wdając się szczegółowo w opis, Scrum ma pięć zdarzeń (punktów inspekcji i adaptacji w konkretnym czasie), trzy role oraz trzy artefakty (przedmioty poddawane tej inspekcji) i jako opisany koncept pochodzi z lat 90. Jest „ramowy”, ponieważ jedynie nakłada pewną formę postępowania, ale nie wyjaśnia żadnej „treści” wewnątrz owej „formy” – ten kontekst zależy tylko od zespołu/organizacji używającej Scruma.

Scrum używany jest do budowania złożonych produktów, głównie oprogramowania. Pozwala na eksplorację nowych pomysłów biznesowych lub technologicznych, minimalizuje ryzyko eksperymentowania dzięki stałym iteracjom, oraz na koniec każdej iteracji oddaje nam do rąk używalny przyrost produktu. Dzięki temu świetnie się sprawdza, kiedy chcemy utrzymać stałe tempo rozwoju produktu, którego nie możemy szczegółowo zaplanować na starcie.

Czym się charakteryzuje Kanban?

Kanban jest nie tyle metodą, co pewną strategią optymalizacji przepływu pracy zapożyczoną z japońskiego przemysłu samochodowego (Toyota). Chociaż korzeniami sięga lat 50. i świata Lean, to w Agile jego odmiana Kanban Software Development stawiana jest w rankingu popularności na drugim miejscu. Kanban pomaga zwiększyć efektywność danego procesu, i niekonieczne będzie to proces produkcji oprogramowania. Z Kanbana dobrze też korzysta się w świecie HRu, marketingu, call center czy dziale prawnym – wszędzie tam, gdzie kolejność pracy nie tyle zależy od wartości w produkcie (jak w Scrum), co jest po prostu kolejką tematów do zajęcia się.

Cztery zasady Kanbana to:

  1. Wizualizacja przepływu pracy (często kojarzona z kanbanem w japońskim znaczeniu, czyli tablicą, na której różne kolumny i karteczki oznaczają postęp prac).
  2. Ograniczanie ilości pracy w toku.
  3. Aktywne zarządzanie obecną pracą w toku.
  4. Poddawanie przepływu pracy inspekcji i adaptacji.

Jak widać, Kanban nie wymusza na starcie żadnych zmian w już istniejącym procesie. Pomaga go tylko zwizualizować, zacząć mierzyć podstawowe metryki i dzięki temu usprawniać. Kanban nie zakłada planowania pracy, lecz obsługę kolejki incydentów.

Owszem, mogą istnieć dwie dodatkowe role (Service Request Manager odpowiedzialny za rozwijanie produktu i potrzeby klientów oraz Service Delivery Manager odpowiedzialny za flow procesu), nie ma żadnych stałych zdarzeń, jedynie kadencje – czyli pętle informacji zwrotnej (może ich być aż siedem). Najważniejsze metryki kanbanowe to:

  1. lead time – pełen czas od zgłoszenia incydentu przez klienta do otrzymania gotowego rozwiązania. Chcemy, by malał.
  2. cycle time – czas, który zespół spędza nad aktualną pracą nad rozwiązaniem. Chcemy, by malał.
  3. throughput – przepustowość, czyli ile jednostek pracy (zadań, karteczek, story pointów itd.) zostaje wykonanych w jednostce czasu (w ciągu dnia, tygodnia itd.). Będzie dobrze, jeśli wzrasta.

Którą z nich wybrać i do jakich zastosowań?

Pomocne w wyborze między Scrumem a Kanbanem są trzy pytania:

  1. Jaki rodzaj pracy będzie wykonywać zespół?
  2. Czy będzie istniała wspólnota pracy, praca zespołowa, czy też każdy członek zespołu swoje zadania może wykonywać samodzielnie i niezależnie?
  3. Czy jest ważne utrzymanie stałego tempa pracy i rozwoju produktu?

Rodzaj pracy

Jeśli można przewidzieć, zaplanować i ustabilizować pracę na bliski horyzont czasu (między 1 a 4 tygodniami), prawdopodobnie powinniśmy stosować Scrum. Dzięki temu ryzyko, że nawet „przestrzelimy” z efektami naszej pracy lub utkniemy nad trudnościami kosztuje nas tylko tę jedną iterację. Praca eksploracyjna, eksperyment, odkrywanie niepewnego lub poszukiwanie najlepszego rozwiązania (znamy cel, nie znamy ścieżki dojścia) – to domena Scruma.

Natomiast, jeśli nie liczy się planowanie, bo i tak obsługujemy kolejkę pracy zgodnie z jakąś regułą, to warto rozważyć Kanban. Ostatecznie służy on procesom, więc jego efektem w przeciwieństwie do Scruma może nie być produkt (np. trudno wskazać, co byłoby produktem konsultantów call center lub zespołu prawników sprawdzających zgodność naszych usług z obowiązującymi przepisami). Prace administracyjne, utrzymanie, kolejka do wykonania, spływające zapytania – jeśli cokolwiek jest trudne do zaplanowania lub wręcz niemożliwe do przewidzenia (np. nie wiemy, ilu klientów i z jak trudnymi pytaniami zadzwonią do konsultantów), a może być obsługiwane tablicą z kolejką incydentów – oto dobre pole dla Kanbana.

Wspólnota pracy

Scrum wymaga wspólnoty pracy w zespole. Ma opisane role Developerów, Product Ownera i Scrum Mastera, którzy wspólnymi siłami przekładają potrzeby biznesowe na używalny produkt. Ma limit wielkości zespołu. Zespół powinien pracować razem, uzupełnia swoje zdolności (jest wszechstronny – ma wszystkie kompetencje potrzebne do zbudowania produktu), a wszystkie role po równo odpowiadają za przyrost produktu.

W Kanbanie może nawet nie istnieć zespół – w sensie grupy mającej wspólny cel i współdziałającej ze sobą – bo każdy może swoją pracę wykonywać sam (wróćmy znowu do przykładu z call center). Kanban jedynie obrazuje przepływ pracy, może wykazać pewne ograniczenia (np. tylko niektóre osoby mogą wykonać jakąś czynność, ktoś czeka aż ktoś inny skończy swoje zadanie itd.). Dobrze jednak wprowadzić rolę Service Delivery Managera, jako osoby dbającej o flow, uczącej i przypominającej o inspekcji, adaptacji i przejrzystości.

Stałe tempo pracy

W Scrumie istnieje coś w rodzaju dżentelmeńskiej umowy: Product Owner zamraża część wymagań, obiecując że w danej iteracji ich nie zmieni, żeby Developerzy mogli je przekuć w przyrost produktu, a Developerzy dają Product Ownerowi wolną rękę w pracy nad pozostałymi, niezamrożonymi wymaganiami. Ten cykl pracy, zwany Sprintem, ma stałą długość i pozwala nadać rytm pracy. Na koniec każdej iteracji powstaje coś gotowego i potencjalnie wydawalnego (tzn. Product Owner zawsze może to wydać przynajmniej na koniec iteracji, ale jest to jego biznesowa decyzja). Wymagania są segregowane względem wartości w produkcie, przez Product Ownera, na liście zwanej Product Backlogiem.

Kanban zakłada, że zmiana może się zadziać w każdym momencie. Dlatego nie da się ani przewidzieć ile pracy wpadnie do kolejki, ani nie trzeba czekać na rytm iteracji – po prostu ile razy coś jest skończone, może być wydane. Kanban jest też systemem pull – wciąganie pracy do wykonania następuje od razu, gdy poprzednia jest ukończona. Nakłada się jednak tzw. kadencje (pętle inspekcji i adaptacji), żeby utrzymać empiryzm.

Oczywiście – jak wszystko w świecie Agile – wybór między Scrum i Kanban jest bardzo kontekstowy. Zależy od wielu czynników, a ten artykuł ma poddać pod rozwagę te najczęściej spotykane. Jeśli nadal nie ma pewności co do zasadności jednej lub drugiej metody, proponuję… podejście empiryczne. Warto wypróbować obie i zobaczyć, która przynosi lepsze efekty (czyli zapewnia lepszą przejrzystość, pozwala usprawniać proces i podnosi wartość biznesową).


Artykuł ukazał się oryginalnie na blogu Code Sprinters http://agileszkolenia.pl/blog/kiedy-wybrac-scrum-a-kiedy-kanban/

Czy „zwinna organizacja” oznacza Scrum w każdym dziale?

Transformacja Agile

Powszechne zainteresowanie metodami z rodziny Agile 17 lat po publikacji Manifestu Agile i po ponad 20 latach wyraźnej obecności tych praktyk (Scruma, Kanbana, XP i in.) w naszej branży, nikogo nie powinno dziwić. Jednak wiele organizacji, które spotykam na swojej zawodowej ścieżce, dopiero rozpoczyna „zwinną transformację” – czyli próbuje agile’owe podejście uczynić standardem swojej organizacji pracy i rozwijania produktów. Najczęściej w firmie zaczyna się od przeorientowania istniejącego działu IT budującego te produkty, następnie przeszkolenia „biznesu” – a więc osób odpowiedzialnych za dostarczanie wymagań i dbanie o wartość rynkową tworzonych rozwiązań, potem (rzadziej na starcie) menedżerów i zarządu, a najrzadziej – samych klientów/odbiorców/użytkowników danego rozwiązania.

Często takie transformacje nie osiągają efektów, czemu się nie dziwię. Na przeszkodzie stoi:

1. zastana kultura organizacyjna (sztywne struktury i hierarchie, rozbuchane procesy, wewnętrzne rozgrywki „polityczne”),
2. powszechna „projektoza”, czyli brak poczucia wspólnoty pracy i obecność „zasobów ludzkich” w czterech projektach na raz, w każdym oczywiście na 100% czasu,
3. brak wyraźnej presji do zmian (firmie nie grozi upadek, nawet gdy nie będzie szybciej tworzyła wartościowych produktów),
4. a jako crème de la crème – brak spójnej wizji, po co taka transformacja w ogóle ma się odbywać!

I nie chodzi jedynie o wyjaśnienie programistom czy project managerom, dlaczego od jutra będą pracować inaczej. Grzechami głównymi źle przygotowanych transformacji są:

1. brak jasnego celu na poziomie wysokich warstw kierowniczych (po co cokolwiek zmieniać),
2. brak porywającej wizji dla całej organizacji (gdzie ta zmiana zaprowadzi naszą firmę),
3. brak przyzwolenia na realną zmianę – zamiast tego tylko naklejanie nowych etykietek na niezmienione role i procesy,
4. brak wiedzy jak mierzyć postępy (jakie metryki i gdzie), skąd będziemy wiedzieć, że osiągnęliśmy cele transformacji,
5. traktowanie zmian nie jako inwestycję, ale jako „zło konieczne” lub „modę na Agile”.

Unifikacja – Scrum dobry w każdym dziale

Jeśli jednak uda się te wymienione grzechy przezwyciężyć lub chwilowo odsunąć w czasie, pojawia się jeszcze jeden – będący owocem burzliwego związku Niewiedzy z Entuzjazmem. Tym grzechem jest potrzeba powszechnej unifikacji.
Kiedy organizacja uczy się metod zwinnych, to najpewniej na starcie zetknie się ze Scrumem, który jest świetnym sposobem na budowanie złożonych produktów wysiłkiem małego, samoorganizującego się zespołu. Największą zaletą Scruma jest bardzo szybka pętla informacji zwrotnej – także o tym wszystkim, czego się wstydzimy: nieznajomości domeny, technologii, potrzeb użytkownika, słabej komunikacji wewnątrz zespołu, niedociągnięć kompetencyjnych, niewystarczającego poziomu jakości itd.

Scrum jednak nie jest uniwersalną odpowiedzią na Największe Pytanie Wszechświata, ma bowiem szereg ograniczeń – wymaga pewnego *setupu* organizacyjnego, poznania nowego sposobu pracy, zrozumienia jego wartości, słabo służy powtarzalnym czynnościom lub obsłudze incydentów itd.

Oczywiście, pewne jego elementy, jak planowanie czy codzienne spotkania, mogą być używane niezależnie od samego Scruma, ale często widzę pełne wątpliwości spojrzenia przedstawicieli działów innych niż IT: „A jak my mamy tak pracować?”. Ambitne plany managementu, działu HR lub komórki odpowiedzialnej za transformację przydzieliły już bowiem pracowników do nowej struktury, nowych zespołów i produktów, a także wysłały ich na nowe szkolenia (ze Scruma najpewniej). Entuzjazm związany ze zmianą i przekształceniami spotyka niewiedzę (Scrum nie jest jedynym narzędziem z rodziny Agile i ma konkretne zastosowania produkcyjne). Jak mają się w tym odnaleźć administratorzy systemów, marketingowcy, prawnicy czy pierwsza linia obsługi klienta? Wszyscy ci, których praca niekoniecznie daje się planować na iteracje i nie zawsze dostarczają produkt jako efekt swojej pracy?
Bez obecności Agile Coacha lub kogoś z doświadczeniami z innych transformacji, może się tu wkraść słuszny lęk i opór przed zmianą, której część zespołu lub załogi nie rozumie i nie widzi w niej swojego miejsca.

Rozwiązanie

Istnieje tylko jedna odpowiedź: oni nie będą pracować w Scrumie, co nie oznacza, że nie mogą pracować zwinnie. Scrum jako taki w działach marketingu, prawnym czy obsłudze call center nie ma wielkiego sensu (co wyjaśniałem kiedyś we wpisie o Scrum vs Kanban). Ale podstawy zwinności: możliwość inspekcji pracy, jej adaptacji oraz utrzymanie przejrzystości wciąż mogą, a nawet powinny być nadal filarami pracy członków zwinnej organizacji. Dlatego z każdym działem trzeba ustalić, jakie praktyki i mechanizmy bedą u nich działać, by wzmacniać samoorganizację, zapewniać przejrzystość procesów oraz gdzie da się „zamontować” mechanizm empiryczny i jak często będzie on używany (jak długa będzie pętla informacji zwrotnej). Dlatego zastosowania różnych technik i praktyk z rodziny Agile będą się pewnie różniły między poszczególnymi częściami organizacji. Nie ma w tym nic złego, ale pod pewnymi warunkami:

1. Istnieje wspólne słownictwo, dzięki czemu zachowana jest przejrzystość. Wiadomo, na jakim etapie znajduje się praca poszczególnych jednostek, kiedy jest ukończona, co znaczą konkretne terminy.
2. Wszyscy w organizacji rozumieją, dlaczego stosuje się mechanizm empiryczny i że oznacza on konieczność *stałego* dostosowywania pracy. Jako taka transformacja jest więc ciągłym procesem, a nie określonym punktem w czasie.
3. Istnieją metryki pozwalające śledzić osiąganie celów całej organizacji bez lokalnych suboptymalizacji. To ważne w kontekście zagrożenia powrotem do pracy w silosach: dział IT znów pracuje na swoje cele, dział sprzedaży na swoje itd.

Artykuł ukazał się oryginalnie na blogu Code Sprinters http://agileszkolenia.pl/blog/scrum-w-kazdym-dziale/