Chyba nikt w naszym kręgu kulturowym nie powinien mieć wątpliwości, co do tego, że centralne sterowanie nie działa. Z drugiej zaś strony, mało kto słyszał o genchi genbutsu. Co to za zwierz i jak się on ma do naszego zwinnego światka?
Genchi genbutsu
Genchi genbutsu to jedna z zasad Toyota Production System. W zależności od tłumaczenia oznacza „prawdziwe miejsce, prawdziwą rzecz” bądź po prostu „idź i patrz”. Zasada genchi genbutsu mówi, że aby w pełni zrozumieć jakiś proces (lub problem, sytuację), musimy udać się do miejsca, w którym on się dzieje i posiąść informacje z pierwszej ręki.
W tym elemencie TPS-u chodziło o to, że każda sprawa dotycząca linii produkcyjnej powinna być rozwiązana właśnie w tym miejscu, a nie w pokoju kierownika czy – o zgrozo – w centrali firmy.
Ponadto, od managerów oczekiwano, że będą oni spędzać czas w miejscu, którym zarządzają, patrząc na to, jak wykonywana jest praca. Niezwykle trudno jest bowiem kierować czymś, o czym nie mamy pojęcia albo czego nie doświadczyliśmy osobiście.
I chociaż samo obserwowanie genchi genbutsu na pewno pomoże, to jednak nigdy nie będzie to wystarczające do skutecznego zarządzania. Stąd tak duży nacisk kładziemy na samoorganizację, która jest niezbędna, żebyśmy mogli mówić o zwinnym podejściu.
Wiadomo, że aglie’owa samoorganizacja niekoniecznie sprawdziłaby się na linii produkcyjnej, chociaż i tam znajdziemy jej odpowiedniki. Chociażby w tym, co tak pięknie opisuje nasz ulubiony manifest – w pozwoleniu ludziom na własnoręcznie usprawnianie ich pracy.
„Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie” – Agile Manifesto
Facylitacja samoorganizacji
Echa pomysłu genchi genbutsu znajdziemy w roli Scrum Mastera, który patrzy z boku, ale jednak jest „w miejscu, w którym się dzieje” (jap. genba). I chociaż nie jest on żadnym kierownikiem, to jednak zarządza procesem scrumowym. Żeby skutecznie pełnić tę funkcję, musi być w centrum wydarzeń.
Podobnie zresztą jest z pozostałymi rolami. Trudno, żeby PO mógł decydować o kierunku rozwoju produktu, jeżeli nie uczestniczy w jego powstawaniu. Z kolei zaś zaangażowanie Development Teamu w bieżące prace jest oczywiste i wynika wprost z definicji zespołu.
Pamiętajmy, że nie ma żadnej hierarchii w Scrum. To znaczy, każda z ról (Product Owner, Scrum Master, Development Team) powinna znajdować się na tym samym poziomie. Nie powinno być między nimi zależności przełożony-podwładny. Dla nas ważne jest, że wszyscy są tam, gdzie się dzieje.
Bo przecież cały Scrum Team bierze udział we wszystkich wydarzeniach z wyłączeniem Daily Scrum. Mamy więc zapewnioną obecność każdej zaangażowanej osoby w genchi genbutsu zarówno na poziomie Sprintu, jak i wymagań (patrz: Product Backlog Refinement). Z kolei sam Development Team nie dość, że siedzi razem (zespołom rozproszonym mówimy „Nie!”), to jeszcze codziennie planuje swoją pracę na Daily.
Każdy jest tam, gdzie pracuje i ma wpływ na swoje codzienne zadania. A co z decyzjami strategicznymi?
Centralne sterowanie nie działa
Rola kierowników liniowych w podejściu zwinnym, a w Scrumie w szczególności, się zmniejsza. Zdajemy sobie również sprawę, że trudno jest podejmować decyzje będąc oddalonym od miejsca, w którym odbywa się praca i pojawiają się jej rezultaty. Takie zmiany są więc czymś naturalnym.
Wierzymy też, że decyzje o produktach podejmowane przez Product Ownerów wynikają z odpowiednich priorytetów przekazanych przez interesariuszy. Bo to mimo wszystko sponsorzy, klienci i odbiorcy podejmują decyzje strategiczne. Ale gdy już wiemy, co tworzymy, to im niżej rozstrzygane są dylematy operacyjne, tym lepiej.
W tym momencie ktoś może zapytać „A co z architekturą i projektem tworzonego systemu?” Na szczęście i na to mamy gotową odpowiedź.
„Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów” – Agile Manifesto
Popatrzmy na ten cytat pod kątem bohatera dzisiejszego odcinka, czyli genchi genbutsu. To zespoły, które będą później używały danej architektury bądź będą rozwijały dany produkt, stworzą najlepszy i dopasowany do swoich potrzeb plan. Tu wracamy do kwestii odczuwania konsekwencji swoich decyzji, czyli skin in the game.
Jeśli nie muszę utrzymywać danego produktu, nie będę się przejmował tym, czy poprawa błędów będzie prosta. A jeżeli nie ja będę implementował rozwiązanie według stworzonej przeze mnie architektury, nie będę się zastanawiał czy na pewno jest to optymalny pomysł dla iteracyjnego tworzenia oprogramowania.
Więc jeżeli już mamy wydzielony zespół architektoniczny, to jako absolutne minimum musimy zaprosić go do genba i pokazać mu, jak pracujemy. Bez doświadczenia konsekwencji architektonicznych mamy ogromne szanse na piękne projekty, które jedynie ładnie wyglądają na papierze i nie przeżywają zderzenia z rzeczywistością.
I tak to nam się wszystko łączy: genchi genbutsu, skin in the game, samoorganizacja i zwinność. Bo przecież wszystkie te pomysły to nic innego, jak zdrowy rozsądek, nieprawdaż?
