Model Cynefin w Scrumie

Model złożoności wg. Cynefin

Model złożoności wg. Cynefin

Wielokrotnie zastanawiałem się, jak pełniąc rolę Scrum Mastera lub Agile Coacha, zachować odpowiedni balans pomiędzy mentoringiem oraz coachingiem w stosunku do zespołów. Kiedy mówić wprost o rozwiązaniach, a kiedy prowokować do myślenia zadając pytania? Kiedy zespół potrzebuje prostych zasad oraz ograniczeń, a kiedy absolutnie wolnej ręki?

Okazuje się, że ostatecznie jedyna słuszna odpowiedź to ta, której często nie lubią Ci, którzy szukają odpowiedzi, a mianowicie – „to zależy”.

Cynefin framework – teoria

Z pomocą przychodzi nam Cynefin – jest to model, który pomaga przyjąć odpowiednią postawę, w zależności od domeny problemu, z którym przyszło nam się zmierzyć. Model składa się z pięciu obszarów, które reprezentują różną skalę złożoności systemu, w którym możemy się poruszać:

  • prosty – rozpoznajemy wyraźnie związki przyczyna-skutek; istnieje jedna, poprawna odpowiedź na konkretny problem; proponowany sposób działania: odczuj-klasyfikuj-reaguj
  • skomplikowany – związki przyczyna-skutek są rozpoznawalne, ale nie dla wszystkich są oczywiste; istnieje więcej niż jedno rozwiązanie problemu; proponowany sposób działania: odczuj-analizuj-reaguj
  • złożony – ciągłe zmiany oraz nieprzewidywalność; związków przyczynowo-skutkowych możemy doszukiwać się tylko dla danych historycznych; istnieją konkurujące ze sobą odpowiedzi; proponowany sposób działania: sonduj-odczuj-reaguj
  • chaos – brak ciągu przyczynowo-skutkowego; dużo decyzji do podjęcia przy jednoczesnym braku czasu na przemyślenie rozwiązań; brak poprawnych odpowiedzi; proponowany sposób działania: działaj-odczuj-reaguj
  • nieporządek – stan, w którym nie jesteśmy pewni, który z powyższych systemów jest dominujący

Systemy proste oraz skomplikowane reprezentują uporządkowanie, złożone oraz chaotyczne – nieuporządkowane. W dużym skrócie, to tyle, jeśli chodzi o podstawy teoretyczne.

Jak to się ma do roli Scrum Mastera?

Codziennie spotykamy się w pracy z sytuacjami, w których musimy określić nasz kontekst operacyjny (czyli złożoność systemu), aby podjąć właściwą decyzję. Aby lepiej zrozumieć w czym rzecz, przygotowałem po jednym przykładzie dla każdego systemu.

  • prosty – młody zespół wystartował pierwszą iterację. Podczas odbioru produktu pod koniec jej trwania okazuje się, że produkt nie spełnia kryteriów akceptacji, ponieważ zespół zinterpretował je na swój sposób (odczuj). Widoczny jest silny związek przyczynowo-skutkowy: zespół nie komunikował się z Product Ownerem, więc szczegóły nie zostały doprecyzowane (klasyfikuj). Klasyfikacja tego problemu jest dosyć oczywista – spisane elementy Product Backlogu to nie wszystko, zacznijcie ze sobą rozmawiać (reaguj)
  • skomplikowany – zespół sygnalizuje, że ma problem z dostarczaniem zaplanowanych zadań na koniec iteracji (odczuj). Przyczyny mogą być różne i należy się im przyglądnąć – np. zbyt dużo zadań w fazie „in progress”, brak kompetencji w zespole, zupełnie nowy produkt w Product Backlogu, brak motywacji, management przeszkadza w pracy zamiast pomagać, itd. Istnieje co najmniej kilka sposób, które mogą rozwiązać ten problem – pomocna może być konsultacja z innymi Scrum Masterami (analizuj). Pozostaje wybrać najlepsze rozwiązanie (reaguj).
  • złożony – zespół rozpoczyna pracę nad nowym produktem, w zupełnie nowej technologi. Wymagania nie są doprecyzowane, wydajność finalnego produktu na tym etapie pozostaje zagadką, jak również ostateczne grono osób zainteresowanych. Nie pozostaje nic innego, jak tylko wystrzelić pocisk smugowy na podstawie posiadanej wiedzy (sonduj), a następnie zapytać interesariuszy, czy to jest to, czego się spodziewali (odczuj). W kolejnej iteracji możemy zmodyfikować produkt zgodnie z ich oczekiwaniami (reaguj)
  • chaos – zespół otrzymuje informacje, że ich produkt – uruchomiony produkcyjnie dla ponad 10 000 klientów – przestał działać. Telefony zaczynają się urywać. Na skrzynkę pocztową wsparcia technicznego w ciągu 5 minut pojawia się 40 wiadomości od wkurzonych klientów. Zespół jest zdziwiony, bo nie robił ostatnio żadnej zmiany produkcyjnej, ani na warstwie kodu, ani na warstwie sprzętowej. Pierwsza myśl – sprawdźmy logi serwera (działaj). Wstępne opanowanie sytuacji, tj. określenie, że problem jest sprzętowy (odczuj), pozwala nam podjąć stosowne decyzje i być może w krótkim czasie wrócić ze świata chaosu do świata złożonego (reaguj).

Gdzie jest haczyk?

Największym problemem jest precyzyjne określenie, w jak złożonym środowisku aktualnie się poruszamy. Błędne sklasyfikowanie może poprowadzić do podjęcia błędnych decyzji. Stąd łatwo można zakwestionować powyższe przykłady – coś, co dla jednej osoby wygląda na prosty, trywialny problem, dla innego może być złożonym zagadaniem. Cynefin nie zaklasyfikuje problemu za nas. Ostateczna decyzja zależy od nas samych.

Fotografia użyta na licencji Creative Commons ze strony Wikipedia.