Blog

Czy często zdarza się wam słyszeć od znajomych, że pracują zgodnie z „metodologią Agile”? A jak często dopytując o szczegóły, dowiadujecie się, że rozmówca stawia znak równości między Scrumem i Agile oraz pomiędzy metodami i naukami o metodach? O ile takie pomieszanie pojęć mogło być zrozumiałe kilkanaście czy dziesięć lat temu, dziś zaskakuje. Choć może nie powinno: wiele korporacji wytwarzających oprogramowanie – i niemal wszystkie nowe organizacje – mówią, że są Agile, a echo powtarza za nimi „mamy Scruma, mamy Scruma…”.

Agile to podejście do rozwiązywania problemów z wykorzystaniem empirycznej kontroli procesu. Jest to też zarazem ruch propagujący to podejście i zbiór metod (ale nie metodologii) podpowiadających, jak działać w sposób zwinny. Podobnie jest z metodami wywodzącymi się z podejścia Lean. Żadna z nich nie daje gotowej recepty, a jedynie ramy postępowania, które trzeba w świadomy sposób wypełnić kontekstem własnej organizacji i niezbędnymi praktykami. Scrum, Kanban, DSDM czy XP nie muszą być użyte, by organizacja stała się zwinna lub choćby zwinniejsza. Mogą stanowić inspirację do stworzenia własnego, opartego na empiryzmie podejścia, być może efektywniejszego niż którakolwiek z wymienionych metod.

Scrum dobry na wszystko?

Najpopularniejszą z metod zwinnych jest Scrum, który poprawnie użyty daje efekt wow!, gdy Zespoły zaczynają efektywnie dostarczać działające i wartościowe (!) rozwiązania problemów biznesowych. Oczywiście nie każdej firmie i nie każdemu Zespołowi się to udaje, ale dzieje się to na tyle często, że Scrum urasta do rangi złotego środka – rozwiązania wszystkich problemów. Cytując jednego ze znanych mi kierowników, można nagle zrobić „więcej, lepiej, szybciej, taniej”. Być może tak jest, ale wielu firmom się to nie udaje, choć bynajmniej nie z winy samej metody.

Scrum doskonale sprawdza się w rozwoju produktów: empiryzm wbudowany jest w zdarzenia metody, która wspiera poszukiwanie najlepszych rozwiązań i sposobów ich realizacji. Jeśli organizacja lub Zespół rozwija np. oprogramowanie lub jakikolwiek złożony produkt, Scrum jest dobrym wyborem.

Często jednak Zespoły nie rozwijają produktu, ale zajmują się realizowaniem zleceń (zadań technicznych, rozwiązywaniem błędów, ale też zatrudnianiem ludzi, obsługą prawną etc.). Najczęściej nie jest wtedy możliwe negocjowanie zakresu prac, bo te wynikają albo z umów, albo z regulacji prawnych, albo procesów organizacji. Empiryzm wciąż jest konieczny, ale na pierwszy plan wysuwa się optymalizacja przepływu zleceń przez system ich realizacji.

Kanban bywa lepszym rozwiązaniem

Być może wyszarpuję właśnie dywan spod nóg osób przekonanych, że aby być Agile, trzeba stosować Scruma. Nie trzeba. Jeśli nie rozwijamy produktu, a zależy nam na efektywnym działaniu – zaprzyjaźnijmy się z Kanbanem, mającym korzenie w podejściu Lean. W odróżnieniu od Scruma nie jest to metoda ramowa (ang. framework), ale strategia optymalizacji wartości przez udoskonalenie stosowanych procesów tak, by wyeliminować z nich marnotrawstwo. Kanban pozwoli zatem na optymalizację obsługi zleceń również tam, gdzie Scrum (jako proces) nie może być zastosowany, na przykład przy pracach serwisowych i realizacji zadań innych niż tworzenie nowych rozwiązań i produktów.

Aby zacząć pracę w Kanbanie, nie jest konieczne zdefiniowanie nowych ról, artefaktów ani zdarzeń (spotkań). Równie sensowne będzie ewolucyjne usprawnianie już działających procesów, a pierwszym krokiem jest zwykle wizualizacja ich bieżącego stanu, niekoniecznie zaś rewolucyjna zmiana sposobu pracy. Wizualizacja taka ma formę tablicy, najczęściej z kolumnami reprezentującymi poszczególne stany, przez które przechodzą zlecenia. Reguły obsługi zleceń muszą być jasne i spójne z wizualizacją na tablicy. W ten sposób realizowany jest w Kanbanie postulat przejrzystości niezbędny do kontrolowania procesów.

W Kanbanie konieczne jest zarządzanie przepływem wartości (a dokładniej zleceniami, których obsłużenie wartość tą przyniesie) tak, by czas realizacji zlecenia był możliwie najkrótszy. Po co? Im krócej coś robimy, tym mniejsza szansa, że wymagania zmienią się w trakcie, poza tym to przymusza do skupienia się na małej ilości problemów na raz i wyeliminowania tego, co zbędne (mało wartościowe). W Scrumie cel ten realizowany jest poprzez ograniczoną (i stałą) długość Sprintu.

Kanban jest systemem pracy pull, czyli takim, do którego zadania są pobierane dopiero wtedy, kiedy istnieje możliwość rozpoczęcia ich realizacji. Oczywiście można sobie wyobrazić, że będziemy rozpoczynać kolejne zadania i robić równolegle wiele z nich, natomiast to nieuchronnie spowoduje wydłużenie czasów realizacji. Ograniczenie ilości pracy w toku (a dokładniej jej kontrolowanie) zabezpiecza przed zapchaniem procesu i pozwala stworzyć wspomniany system pracy typu pull.

W Scrumie planowanie odbywa się na początku każdego Sprintu. W Kanbanie zlecenia mogą być pobierane do procesu w sposób ciągły, oczywiście w granicach rozsądku i tylko wtedy, gdy aktualna ilość pracy w toku na to pozwala.

Łatwo sobie wyobrazić, że usprawnianie procesu, kontrola nad ilością pracy w toku i określenie zasad pobierania zleceń wymaga poddawania tego procesu i obowiązujących w nim reguł inspekcji i adaptacji, zupełnie jak w Scrumie. Różnica polega na tym, że Kanban nie proponuje wprost zdarzenia (spotkania), które ma służyć temu celowi. Nic wszakże nie stoi na przeszkodzie, by cyklicznie przeprowadzać retrospekcje (choć oczywiście nie będą to Retrospekcje Sprintu, jeśli nie jest stosowany Scrum).

Dlaczego czasami Kanban działa lepiej?

Trzymając się zasad i praktyk Kanbana, można ewolucyjnie usprawnić proces tak, by nie pojawiały się wąskie gardła, czas realizacji zleceń był powtarzalnie krótki, a przepustowość całego systemu obsługi względnie stała. Tam, gdzie zasadniczym pytaniem nie jest „co i jak chcemy zrobić?”, ale „kiedy to będzie gotowe?”, Kanban jest często lepszym rozwiązaniem niż Scrum.

Scrum nie pozwala łatwo radzić sobie z sytuacją, gdy zlecenia pojawiają się w sposób ciągły i nie ma możliwości negocjowania zakresu wymaganych prac. Wtedy również należy rozważyć skorzystanie z Kanbana.

Jaki sposób działania wybrać?

Dokonując wyboru pomiędzy Scrumem i Kanbanem należy zrozumieć oba podejścia i zastanowić się, które lepiej pasować będzie do stanu, jaki chcemy osiągnąć (a niekoniecznie do stanu, jaki mamy teraz). Jakiego typu problemy będziemy rozwiązywać? Czy zależy nam na czasie realizacji, czy też na inkrementalnym rozwoju produktu i jego częstej walidacji?

Jeszcze bardziej ostrożnym należy być przy podejmowaniu decyzji o zmianie metody. Są organizacje, które rozwijają nowe produkty w Scrumie, po czym uciekają do Kanbana, bo uwiera ich zbyt krótki Sprint. Cóż, Kanban też nie pozwoli ciągnąć prace nad jednym wymaganiem dowolnie długo, albo ciężko będzie mówić o optymalizacji czasu jego realizacji…

Zróbmy sobie Scrumban

Uważny czytelnik zapewne już doszedł do wniosku, że da się pogodzić Kanban ze Scrumem i de facto korzystać z nich jednocześnie. Rzecz jasna nie chodzi tu o wybranie tego, co nam pasuje ze Scruma i Kanbana – robiąc to, ryzykujemy, że poniesiemy koszty transformacji, nie zyskując nic w zamian. Natomiast można i często warto organizować pracę Zespołu Scrum, posiłkując się Kanbanem.

Jak to działa? Planujemy i poddajemy inspekcji produkt oraz sam proces tak, jak w Scrumie, Zespół jest zdefiniowany zgodnie z wymogami tej metody, również rygory czasowe (w szczególności stała długość Sprintu) jest zachowana. Natomiast dodatkowo wizualizujemy proces, kontrolujemy ilość pracy w toku (na przykład pracując na raz tylko nad jednym z wymagań zaakceptowanych do Sprintu) i tak dalej. Innymi słowy, przetwarzamy Backlog Sprintu, korzystając z Kanbana.

Innym wariantem jest zastosowanie Kanbana w szerszym kontekście organizacji, to znaczy nie tylko do rozwiązywania już nazwanych i dobrze zdefiniowanych problemów biznesowych, ale także do całego procesu przetwarzania oczekiwań i pomysłów, które mogą, ale nie muszą się przełożyć na wymagania, oraz do dostarczania lub wdrażania rozwiązań po tym, jak zostaną one zrealizowane. Wtedy jednym z etapów w procesie kanbanowym będzie wytworzenie rozwiązania, a etap ten z powodzeniem można realizować scrumowo.

Warto też mieć cały czas świadomość, że ani Kanban, ani Scrum nie są metodami totalnymi i nie odpowiadają na wszystkie pytania na temat tego, jak działać powinna organizacja. Tak długo, jak nie są łamane zasady i wartości obu podejść, każde z nich, albo oba jednocześnie, mogą uzupełniać już istniejące procesy i metody pracy. Co więcej, nic nie szkodzi na przeszkodzie, by zacząć ten model twórczo rozwijać i stworzyć własne rozwiązanie (ba! jest to właściwie nieuniknione przy dużej skali organizacji).