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/

Eksperymenty i porażki

W ciągu swojej kariery w latach 1984-2003 koszykarz Michael Jordan przegrał (jak sam twierdzi) 300 spotkań, a 9000 razy oddał niecelny rzut, w tym 26 razy gdy od tego właśnie zależało zwycięstwo. Statystyka robi wrażenie, szczególnie gdy wiadomo, że chodzi o sportowca światowego formatu, legendę parkietu, powszechnie rozpoznawaną i kojarzoną z koszykówką przez każdego, kto nie spędził ostatnich 30 lat na bezludnej wyspie lub w sercu dżungli. Jaka jest więc wartość w liczeniu tych wpadek, skoro ostatecznie nikt nie podważa jego statusu gwiazdy?

Wszystko zależy od naszego podejścia do sukcesów i porażek. Jeśli traktujemy porażki jako kroki do ostatecznego sukcesu, to warto im się przyglądać bliżej i wyciągać z nich wnioski. Może nawet je świętować?

Celebruj uczenie się, nie same sukcesy

Celebrowanie sukcesów jest naturalne, celebrowanie porażek brzmi jednak nieco masochistycznie – mógłby wymyślić je jakiś internetowy guru od dziwnego lajfstajlu, ale w realnym życiu trudno spotkać kogoś, kto cieszy się z niepowodzeń. No, przynajmniej ze swoich…

Chyba, że wprowadzimy trzecią kategorię zdarzeń – eksperymenty, a to pozwoli nam przedefiniować zarówno pojęcie sukcesu, jak i porażki.

Powtarzalne czynności, co do których jesteśmy praktycznie pewni efektu, przynoszą korzyści najczęściej dlatego, że używamy do nich dobrych, sprawdzonych praktyk. Często te praktyki są wręcz automatyczne, jak nawyk częstego mycia rąk albo lista kontrolna dla pilotów przed startem. Odsetek chorób i wypadków lotniczych jest dzięki temu drastycznie obniżony (a jeszcze 150 lat temu dezynfekcja rąk czy narzędzi chirurgicznych była uznawana za fanaberię…). Mamy tutaj wysokie prawdopodobieństwo, że używając dobrych praktyk osiągniemy dobre efekty, ale wciąż jest to prawdopodobieństwo, a nie pewność. Czasami mamy po prostu pecha i nawet sprawdzone wzorce wiodą nas na manowce. Ot, choćby z mojego doświadczenia – częste aktualizacje w dziurawym WordPressie podnoszą bezpieczeństwo strony, to polecana praktyka. No, chyba, że zakodowałeś tam sobie wiele dodatków i pluginów „na sztywno”, a aktualizację wykonałeś dopiero po długim czasie – gdy większość z nich nie była już wspierana. Mnie opłacało się bardziej zaprojektować ładną stronę od nowa niż przywracać z kopii…

A co z błędami? Niektórzy popełniają w kółko te same, gdyż nawet nie są ich świadomi! Wtedy nie można wyciągnąć z nich żadnych wniosków na przyszłość, co w dłuższym okresie staje się nawet bardziej dewastujące, niż sama świadomość potknięcia. W ekstremalnie rzadkich wypadkach pomyłki mogą jednak skutkować wielkimi sukcesami. Pamiętacie, że odkrywca penicyliny Alexander Fleming po prostu nie domknął naczyń laboratoryjnych i zdziwił się, gdy pleśń zabiła jego hodowlę bakterii?
Tim Harford, autor książki Adapt, proponuje więc takie podejście:

Jeśli mamy oswoić porażki, Potrzebujemy więc metodycznego podejścia do sukcesów i porażek, dzięki któremu będziemy w stanie uczyć się w krótkiej pętli.

Jak działa Celebration Grid?

W Management 3.0 kładzie się duży nacisk na zdolność zwinnych organizacji do szybkiego uczenia się i eksperymentowania. Nie dziwi więc obecność przydatnego narzędzia: Celebration Grid, które pomaga celebrować eksperymenty, a nie tylko bezsens porażek ani zachwyt nad sukcesami. Ostatecznie chcemy cieszyć się z efektywnego wykorzystania naszej wiedzy, a nie tylko karać za pomyłki! Przy eksperymentach jest bowiem największa szansa na nauczenie się czegoś nowego – niezależnie czy potwierdzamy, czy obalamy pierwotnie postawioną hipotezę, zasilamy naszą organizację nową, użyteczną wiedzą.

Celebration Grid może być z powodzeniem użyty w czasie Retrospektywy. Znajdźmy najpierw wszystkie zachowania, praktyki, zdarzenia i przykłady z ostatniego sprrintu, które przychodzą nam do głowy. Następnie postarajmy się przyporządkować je do któregoś z obszarów:

  • błędy, z których jednak wyszło coś dobrego (górny lewy róg),
  • błędy i porażki (dolny lewy róg, czerwone pole),
  • eksperymenty zakończone sukcesem (środkowa zielona kolumna, góra) – tu potwierdziliśmy założenia,
  • eksperymenty niezakończone sukcesem (środkowa zielona kolumna, dół) – tu obaliliśmy założenia lub odkryliśmy coś niespodziewanego,
  • dobre praktyki, które się opłaciły (górny prawy róg, zielone pole),
  • te rzadkie przypadki, kiedy nawet dobra praktyka zawiodła (dolny prawy róg).
www.management30.com

Przejrzymy jak ułożyły się karteczki i odpowiedzmy w ten sposób na dwa pytania:

  1. Co zrobiliśmy dobrze? (Posiłkując się dobrymi praktykami)
  2. Czego się nauczyliśmy? (Prowadząc eksperymenty)

Każda karteczka zawieszona na zielonych polach to okazja do celebracji!
Dobre praktyki kontynuujemy, błędów nie powtarzamy, a staramy się znaleźć jeszcze więcej okazji na eksperymentowanie.
Jeśli chcesz dowiedzieć się więcej o eksperymentach w podejściu Management 3.0, zapraszam do kontaktu oraz udziału w szkoleniu.

Zobacz, jak uczestnicy mojego warsztatu przygotowali Celebration Grid:

Artykuł ukazał się oryginalnie na blogu Code Sprinters http://agileszkolenia.pl/blog/eksperymenty-i-porazki/

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/