Walking skeleton – coś o zwinnym przywództwie

walking skeletone

Dobry lider uczy się i szuka inspiracji dookoła. A jako że świat ostatnich lat konsekwentnie zmierza w kierunku podejścia zwinnego, odbywającego się w otoczeniu o dużej zmienności, tak ważne staje się zrozumienie na czym polega zwinne przywództwo.

Z tego artykułu dowiesz się

co ma wspólnego chodzący szkieletor ze zwinnym liderem?

O co chodzi z tym walking sekeleton?

alistair cockburn
Picture by Dennis Hamilton

Koncepcję walking skeleton po raz pierwszy przedstawił Alistair Cockburn (jedna z ważniejszych postaci w świecie zwinnego realizowania projektów) w książce: „Growing Object-Oriented Software Guided by Tests„.
Jak dla mnie walking skeleton idealnie oddaje ducha agile (cóż za ironia, że szkielet ukazuje ducha). W moim świecie agile (czyli zwinność) jest bardziej sposobem myślenia i patrzenia na świat niż konkretną metodyką czy narzędziem. Elementy z tego podejścia zastosujesz z powodzeniem stosować w innych dziedzinach, nie tylko IT.
Dla nas najważniejsze jest szukanie analogii do zwinnego przywództwa. A takich jest bardzo dużo.

Szkielet, czyli…?

Szkielet to inaczej minimalna wersja tego, co chcemy na końcu osiągnąć. Cała idea zwinnego realizowania projektów opiera się na budowaniu rozwiązań krok po kroku. Przyjęta na początku koncepcja rozwiązania nie musi być tą ostateczną i może się zmieniać wielokrotnie w trakcie trwania projektu.
Najpierw powstaje więc podstawa — szkielet, wokół którego dobudowujemy z czasem kolejne warstwy, lub nawet przebudowujemy jego podstawy. Taki szkielet często stanowi podwaliny pod finalne rozwiązanie.

No, ale on chodzi…

Dokładnie tak! Tutaj pojawia się druga istotna kwestia. Szkielet realizowany w sposób zwinny nie może być tylko prototypem, jakąś pół-funkcjonalną makietą. On chodzi, czyli faktycznie działa. Jest to więc pełnowartościowy produkt, zwykle bardzo ubogi w funkcje, ale jednak produkt.
Co ważne, do jego ukończenia powinny być zaangażowane wszystkie zespoły, które następnie będą budować rozwiązanie docelowe. Chodzi o to, aby przećwiczyć w praktyce wszelkie mechanizmy i punkty styku pomiędzy zespołami. Często nie zdajemy sobie sprawy z tego, co może pójść nie tak, dopóki faktycznie nie zbudujemy chociaż szkieletowego rozwiązania.
Do typowych problemów możemy zaliczyć np.:

  • Testowanie i automatyzacja testów rozwiązania
  • Zarządzanie wersjami i utrzymywanie kompatybilności
  • Przygotowywanie danych testowych i ich utrzymywanie
  • Proces wydawania wersji na różne środowiska
  • Odtwarzanie systemu po awarii

Zalety chodzącego szkieletora

O podstawowych zaletach takiego podejścia wspominałem już w poprzednim rozdziale, czyli o możliwości przetestowania w praktyce wielu istotnych mechanizmów.
Kiedy projekt trafi do faktycznej fazy realizacji, wtedy zwykle wystarczy te działania przeskalować, czyli rozszerzyć na więcej zespołów i osób, jednocześnie zostawiając sprawdzone mechanizmy bez zmian.

Sytuacja byłaby zupełnie inna, gdyby zacząć inaczej, czyli od zbudowania szerokiego zakresu funkcjonalności, ale tylko na określonym poziomie, np. przygotować jedynie API, bez uruchomienia pełnej funkcjonalności chociażby tylko w ramach jednego, małego modułu.
Jeżeli przy takim podejściu odkryjemy jakieś nieprawidłowości w późniejszych fazach, to może okazać się konieczne zmodyfikowanie całego kodu dla warstwy API, bądź nawet napisanie jej od nowa.

Przykłady — IT

W IT większość przedsięwzięć da się podpiąć pod tę koncepcję.
Powiedzmy, że budujemy duży system wspierający pracę fabryki mebli. W skład systemu będą wchodziły moduły do obsługi zamówień, produkcji, magazynu, księgowości i zakupów. Aby przekonać się, czy mamy wystarczające procesy i narzędzia do zrealizowania projektu, możemy wybrać jeden moduł i przygotować go w uproszczonej wersji. Powiedzmy, że wybieramy magazyn, gdzie implementujemy obsługę przyjęcia i wydania z magazynu. Tylko tyle. Jednocześnie weryfikujemy wszystkie procesy pozwalające nam budować rozwiązania wysokiej jakości, takie jak CI, CD i wszelkie automatyzacje testów, zarówno te funkcjonalne jak i niefunkcjonalne.
Dopiero gdy mamy to przećwiczone na szkielecie, wtedy możemy założyć że w większej skali te same rozwiązania również się sprawdzą.

Zwinne przywództwo według koncepcji walking skeleton

I teraz dochodzimy do sedna. Zwinny szkieletor, tfu! – lider to kto? Przez analogię do opisanych praktyk technicznych, to ktoś:

  • kto wdraża procesy i wszelkie działania najpierw na mniejszą skalę. Zmienia, sprawdza, koryguje. Nie rzuca się od razu na głęboką wodę.
  • kto poszukuje ciągle rozwiązań, zwinnie dostosowując się do otaczającego świata. Nie trzyma się na siłę z góry przyjętego planu.
  • kto przyznaje się do błędów. Jeżeli koncepcja się nie sprawdza, to mówi „przepraszam” i korzysta z wsparcia innych.
  • kto dba o to aby interesy każdej z osób były uwzględnione. Nie skupia się na wybranej grupie. Dba równo o wszystkich.

Przykład zwinnego przywództwa

przykłady zwinnego przywództwa

W jednym z zespołów pojawia się idea zwiększenia odpowiedzialności zespołu za końcowy sukces. Zespół chce być bliżej klienta końcowego i nie korzystać z warstwy wielu pośredników w trakcie definiowania wymagań. Takie podejście ma zapewnić płynniejszy przepływ informacji w obie strony.
Cała idea brzmi jak najbardziej słusznie i rozsądnie. Czy wdrażasz ją od razu we wszystkich zespołach i projektach?

Zwinny lider postąpiłby na przykład tak:

  1. Wybiera niewielki projekt na potrzeby testowe. Najlepiej taki projekt, który jest w dobrej kondycji (bez opóźnień, mało ryzykowny) oraz taki zespół, który jest pozytywnie nastawiony do zaproponowanych zmian.
  2. Pracuje z zespołem projektowym nad nowym podejściem. Rozmawia o zaletach i wadach. Nowych rolach i obowiązkach. Czy czujemy się z tym ok?
  3. Jasno definiuje zakresy odpowiedzialności. Czy wszyscy rozumiemy to tak samo?
  4. Startujemy! Pracujemy po nowemu. Trochę po omacku, ale do przodu.
  5. Wymienia informację zwrotną. Co zadziałało? Czy idziemy w dobrym kierunku. Cały czas mierzy i monitoruje wspólnie sytuację.
  6. Zbiera wnioski, podsumowuje, organizuje retrospektywę. Czy przenosimy ten model na inne projekty i zespoły?

W ten sposób zwinny lider unika wdrażania wielkich zmian metodą „na żywioł”. Jeżeli coś nie działa, to można szybko i tanio to naprawić. A jak działa…to już masz pierwszą grupę zwolenników nowego podejścia. Kogoś, kto pomoże Ci wdrożyć tę koncepcję w innych zespołach.

Anty-przykład zwinnego przywództwa

Jako lider dużego projektu wpadłeś na pomysł, aby przeorganizować nieco pracę na każdym z poziomów równocześnie. Tak będzie lepiej i wygodniej. Wszystkim.
Ogłaszasz więc swój pomysł. Niby jako pomysł, ale faktycznie jako oświadczenie. Ci, którzy zadają niepotrzebne pytania to malkontenci. Szkoda tracić na nich czas! Lecimy z tematem.

Mijają dni i tygodnie a malkontentów przybywa. Temu przeszkadza coś, tamtej jeszcze coś innego. Czego oni nie rozumieją? Przecież to taka genialna koncepcja.
Z czasem widzisz, jak ludzie się poddają. Część przestaje walczyć o lepszą sytuacją a część odchodzi i szuka swojego miejsca gdzieś indziej. Co się stało?

  • nie przetestowałeś zmiany na mniejszej skali
  • przesadnie uwierzyłeś, że wszystko będzie ok
  • nie słuchałeś (o aktywnym słuchaniu poczytaj tutaj)

Przykłady — inne branże

Tutaj trochę zaimprowizuję, ale wydaje mi się, że podobne mechanizmy można stosować na przykład w biznesach typu:

  • cateringu — jeżeli chcesz wystartować z firmą obsługującą przyjęcia dla kilkuset osób, to może warto zacząć od mniejszej skali i spróbować zorganizować urodziny dla kilkunastu gości. Zobaczysz wtedy jakiego typu problemy logistyczne, związane z dostawcami, przechowywaniem żywności itp. mogą się pojawić. Jeżeli znajdziesz rozwiązania w mniejszej skali, wtedy dużo łatwiej pokonasz te trudności w większym przedsięwzięciu.
  • ogrodnictwo — gdy chcesz zająć się uprawą jakichś roślin, to również warto zacząć od mniejszej skali. Przekonasz się wtedy jakie czynniki mogą wpłynąć na powodzenie Twojego biznesu. Być może po takich pierwszych testach zmienisz koncepcję, zajmiesz się uprawą czegoś innego, co będzie bardziej odporne na zmieniające się warunki.

Nie polecam natomiast takiego podejścia na przykład w budownictwie lub służbie zdrowia 🙂


Podobne wpisy

Artur GułaArtur Guła, pasjonat tematyki zarządzania i przywództwa z życiową misją dzielenia się wiedzą i doświadczeniami z innymi menedżerami.
Doświadczony lider w projektach IT z różnych dziedzin.
Autor książki Fascynujący świat przywództwa.

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

two × two =