To Twój ostatni Sprint. Co robisz?

Ostatni Sprint

Ostatni Sprint

Wyobraź sobie, że Sprint, w którym właśnie bierzesz udział, jest Twoim ostatnim Sprintem. Twój szef to CEO całej firmy i właśnie podjął taką decyzję. Nie chce bowiem inwestować już więcej pieniędzy w produkt X, ponieważ aktualnie większy zwrot z inwestycji da firmie praca nad produktem Y. Brzmi całkiem sensownie.

Pierwsze wrażenie – szok. Jak to możliwe? Przecież miało być tak pięknie! Jednak chwilę później przypominasz sobie, że sam przekonywałeś go, że agile znaczy szybciej. Że agile to większa elastyczność. Mówiłeś o reagowaniu na zmiany ponad podążanie za planem.

Masz pecha – Twoje buzzwordy właśnie zamieniły się w rzeczywistość.

No cóż, czar prysnął. Idziesz więc do swojego zespołu przekazać im gorącą informację od CEO. Prosisz ich o przygotowanie ostatniego wydania.

Niestety, zamiast szampana oraz serpentyn pojawia się smutna lista problemów, które uniemożliwiają zakończenie prac nad produktem w aktualnym Sprincie:

  • „brakuje nam …. „
  • „mamy gotowe tylko … z …. kroków tego procesu”
  • „to co najmniej … tygodni dewelopmentu”
  • „potrzebujemy dodatkowy Sprint na …”
  • „nie wiedzieliśmy że …”
  • „zależymy od …”
  • „to nie będzie takie proste, bo …”
  • „nie da się” (w sensie ogólnym)

Jeżeli usłyszałeś choćby jedno z powyższych zdań, masz problem.

Bardzo łatwo jest powoływać się na „robienie Scruma” kiedy jest to wygodne. Bardzo łatwo jest wybiórczo rzucać wybrane cytaty ze Scrum Guide’a.

Przykładowo, łatwo jest wysłać osobę – która przychodzi o coś zapytać zespołu – na przysłowiowe drzewo, bo przecież „jesteśmy w środku Sprintu”. Unikać mówienia o datach, bo przecież „Product Owner to ogarnia”, a w ogóle to „będzie jak będzie”. Ignorować jakiekolwiek sygnały z zewnątrz, bo przecież „zespół się samoorganizuje”.

A co z tym fragmentem mówiącym o iteracyjnej oraz inkrementalnej pracy? Co z zawsze dostępnym, potencjalnie użytecznym produktem? Hmm…

Tak więc pytanie na dzisiaj brzmi – co by się stało, gdyby Twój aktualny Sprint miał być Twoim ostatnim?

PS. Za inspirację dziękuję @Kuba_Szc oraz @poddrzewem.

Fotografia użyta na licencji Creative Commons od użytkownika Hans.

Zmiany vs. eksperymenty

Zróbmy mały eksperyment

Zróbmy mały eksperyment

Prowadziłem ostatnio retrospektywę w zaprzyjaźnionym zespole. Spotkanie zmierzało powoli do końca – mieliśmy już bowiem zidentyfikowane problemy wraz z potencjalnymi rozwiązaniami. Wystarczyło tylko podjąć decyzję, które rozwiązania wybrać.

10-osobowy zespół, ze względu na specyfikę produktu złożony głównie z programistów, rozpoczął dyskusję nad wyborem rozwiązania do jednego z problemów. Z puli potencjalnych rozwiązań pozostały dwa najciekawsze, które podzieliły zespół na dwa obozy.

Rozpoczęła się dyskusja. Wymiana zdań była długa, pełna nieoczekiwanych zwrotów akcji i pomimo moderacji – trudna do opanowania, ze względu na emocje panujące w zespole.

Jednak z mojej perspektywy najciekawsze w tym wszystkim było to, że zespół przez cały czas operował na poziomie teorii. Dyskutowali o tym, co się wydarzy na skutek podjęcia takiej, a nie innej decyzji. Trochę tak, jakby wybór był wiążący na całe życie.

Dlaczego moim zdaniem nie warto było poświęcać więcej czasu na dyskusję nad zmianą, a zamiast tego zdecydować się na eksperyment?

  • to tylko teoria – rzeczywistość może okazać okaże się zapewne nieco inna, aniżeli została opisana przez zwolenników oraz przeciwników rozwiązania,
  • złożoność środowiska – na poziomie ludzi, zespołu, produktu oraz firmy. Gotowe rozwiązania czy najlepsze praktyki nie działają w złożonym otoczeniu, być może rozwiązanie wyłoni się dopiero na skutek pracy zespołu,
  • łatwość zmiany decyzji – nie trzeba czekać do kolejnej retrospektywy, żeby zmienić raz wybrane podejście. Jeżeli coś nie działa, możemy to zmienić od razu,
  • zdobywanie wiedzy – traktowanie rozwiązania jako mały eksperyment z wartościowym rezultatem (jakikolwiek by nie był), nauczy zespół więcej, aniżeli najciekawsza wymiana zdań.

A Ty jak traktujesz zmiany? Zapraszam do komentowania.

Fotografia użyta na licencji Creative Commons od użytkownika snre.

Pułapka błędnych założeń

Nasz mózg

Nasz mózg

Spędziłem ostatnio trochę czasu z zespołem, który pracuje ze sobą od niemal dwóch lat. Lubię obserwować takie zespoły, ponieważ zazwyczaj funkcjonują w swoim oryginalnym stylu, wychodząc daleko poza schematy opisane w Scrum Guide. Nie inaczej było tym razem – przyjemnie było poobserwować samoorganizację teamu w kwestii moderacji spotkania (Scrum Master nie miał właściwie nic do roboty), zobaczyć autorskie podejście do planowania pracy oraz przekonać się, że pod pozornym chaosem kryje się duże zaangażowanie oraz odpowiedzialność zespołu.

To, co zwróciło moją uwagę w pewnym momencie – i niejako zachwiało tym sielankowym obrazem – był sposób komunikacji jednego z członków zespołu w stosunku do reszty. Kiedy wypowiadał się, używał formy „zrobicie”, „będziecie”, „zrealizujecie”, co spowodowało, że od razu zacząłem się zastanawiać, jak to możliwe, że w tak zgranym zespole, może pojawić się ktoś z tak silnym poczuciem odrębności.

Równolegle z dalszym podążaniem za przebiegiem spotkania uruchomił mi się w głowie proces odpowiedzialny za analizę zaistniałej sytuacji. Dlaczego tak się zachował? W jakiej relacji jest z resztą zespołu? Skąd takie zachowanie w tak zgranym zespole? Dlaczego nikt nie reaguje? I tak dalej.

Kiedy na koniec spotkania podzieliłem się swoją obserwacją, usłyszałem prostą odpowiedź od zainteresowanego: „Po prostu idę na urlop i nie będę mógł uczestniczyć w kolejnym Sprincie – dlatego nie mówiłem zrobimy tylko zrobicie”. Proste, prawda?

Poniższa sytuacja uzmysłowiła mi, jak łatwo wpaść w pułapkę własnych myśli. Za dużo zakładamy, myślimy, dopowiadamy sobie, snujemy tezy. Budujemy alternatywny obraz sytuacji na podstawie mieszanki tego co widzimy oraz tego co wiemy. Nasz mózg jest podatny na tego rodzaju kreatywne zabawy.

Przypomniała mi się porada, której udzielił doświadczony tłumacz młodszemu koledze, który wybierał się na konferencję międzynarodową, aby w locie tłumaczyć treść wykładów dla zgromadzony. Brzmiała ona: „Expect the unexpected.”

Fotografia użyta na licencji Creative Commons od użytkownika perpetualplum.

Podwodny świat zespołów scrumowych

Budowa peryskopu

Budowa peryskopu

Wyobraźmy sobie nowoczesną łódź podwodna, wyruszającą na misję bojową. Świetnie przygotowana załoga doskonale radzi sobie z obsługą okrętu. Wszystkie systemy są naszpikowane elektroniką, a całość spina wysokiej jakości oprogramowanie.

Okręt zbliża się w strefę walki. Pomimo sugestii doradcy, że warto by było ocenić, co znajduje się na horyzoncie, oficer dowodzący jest zdania, że łódź jest tak nowoczesna, iż nie ma sensu użyć peryskopu. Uważa, że wszystko co ważne, wskazuje nam aparatura pokładowa, a załoga nie raz już płynęła na misję, więc wiedzą doskonale, co mają robić.

10 minut później łódź zostaje trafiona torpedą wystrzeloną z wrogiego okrętu. Łączność z naszym statkiem zostaje utracona. Znajdująca się w pobliżu jednostka potwierdza jego zatonięcie. Misja kończy się niepowodzeniem.

Jak to się ma do Scruma?

Ta niepozorna historia ma wiele wspólnego z pracą nad rozwojem produktu. Poznałem ostatnio zespół, który pracuje w nowoczesnej technologii. Starają się wytwarzać kod wysokiej jakości. Mają dostęp do narzędzi oraz wiedzy, która pozwala im dobrze wykonywać swoją pracę. Rozmowy zespołu dotyczą zazwyczaj szczegółów technicznych, rysowane są diagramy, omawiane interfejsy oraz komponenty.

W tym wszystkim jakby zapominali, że istnieje świat nad powierzchnią wody. Że użytkownika nie interesuje jak coś jest zrobione, tylko co mu to daje. Że ma być użytecznie oraz intuicyjnie. Że w ogóle jest jakiś użytkownik, który nie jest systemem, komponentem czy klasą, tylko żywym organizmem, który ostatecznie będzie z tego korzystał.

Zapominają użyć peryskopu, aby wyjrzeć na powierzchnię i ocenić, jak ich praca ma się do sytuacji na polu bitwy. Tracą przez to informacje, które pomogły by im lepiej przeprowadzić misję. Ryzyko niepowodzenia wzrasta. Świat pod wodą wygląda inaczej, niż ten rzeczywisty.

A może zamiast używać peryskopu, lepiej wykonać pełne wynurzenie?

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

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.