Na konferencję AgileByExample Light trafiłem dzięki otwartemu podejściu organizatora do procesu rejestracji. Na listę uczestników zapisywałem się z odpowiednim wyprzedzeniem, ale zapisywać się i zapisać to nie to samo. Na szczęście Piotr znalazł sposób na dopisanie mnie do zamkniętej już listy uczestników, przy okazji potwierdzając swoją pasję do zwinnego zarządzania.
Prezentacja nosiła tytuł Agile Bullshit i dotyczyła szkodliwości przesądów podbudowanych niepotrzebnymi emocjami. Paweł wielokrotnie odnosił się do hejtu, który jest sensem życia hejterów. Jak wiadomo hejter to “Zazdrosny koleś który nie potrafi cieszyć się sukcesem kogoś innego, dlatego próbuje wytknąć w nim wszystkie możliwe wady”. Paweł wybrał sobie ryzykownego pomocnika do prezentacji ale Cuius regio, eius religio, a odwaga jest warunkiem koniecznym do odniesienia sukcesu nie tylko w Extreme Programming. Istotą podejścia Agile jest szeroki horyzont myślenia, otwartość na nowe idee i odwaga w atakowaniu problemów. Szeroki horyzont myślenia pozwala na zastosowanie wielu narzędzi i płynne łączenie starego z nowym. Jeżeli ktoś poznał nową technikę estymowania to nie powinien zapominać o metodach używanych poprzednio, nawet jeżeli ta fascynuje go planning poker pokazywany na ostatnim szkoleniu Scrum. Otwartość na nowe idee pozwala sprawnie ewoluować od starych do nowych metod. Nawet jeżeli przez jakiś czas będziemy używać metodologii ScrumBUT (Scrum ALE) nie tracimy honoru towarzyskiego. Ważne że elementy nowej metodologii pozwalają nam lepiej realizować nasze cele. Odwaga w atakowaniu problemów chroni przez popadnięciem w stan, kiedy wszyscy wiedzą że jest źle i robi się coraz gorzej ale nikt nie zażąda zmian. Promując odwagę unikniemy sytuacji kiedy 90% czasu poświęcamy na tworzenie testów a 10% na pisanie kodu i kolejny raz nie dowozimy obiecanego wyniku. Zaoszczędzimy też na wizycie konsultanta i rysowaniu prostych diagramów konfliktu, bo nie będziemy się bali odpowiedzialności za dokonany wybór a konsultanta wykorzystamy do trudniejszych problemów. Paweł postawił ciekawą tezę, ze kontrakty time&material zabijają rynek firm piszących software. Niestety nie udało mi się nakłonić go do rozwinięcia tezy. Stwierdził też, że kompetencje programistów dostępnych na rynku potrafią być bardzo niskie, bo ludzie nie dbają o własny rozwój, dlatego trzeba je sprawdzać.
Prezentacja Marcina miała tytuł Zrozum swojego szefa. Nieoficjalna stopa bezrobocia na rynku managerów w Warszawie wynosi 30%, więc szef ma powody do stresu. Z własnego doświadczenia w korporacji wiem, że im wyżej w organizacji tym większa rola polityki a polityka jaka jest każdy widzi. Szef ma zestaw diagramów konfliktu do rozstrzygnięcia przerastający twoje pojmowanie rzeczy i wie, że jakkolwiek by nie postąpił będzie tego żałował. Dodatkowo często ma hipotekę we franku wartą więcej niż nieruchomość i rozwód w toku. Zycie szefa w korporacji nie jest zatem usłane różami, a i w małych firmach też słodko nie jest. W małych firmach szef nieustannie myśli o tym jak zapłacić twoją pensję w terminie nie rujnując przepływów pieniężnych firmy. Codziennej porcji polityki dostarczają mu wspólnicy, klienci i konkurencja. Skoro już wiesz to wszystko sroga lub wiecznie zatroskana mina szefa już cię nie dziwi. Nie daj się też zwieść wyluzowanej wesołości. Pamiętaj, że szef to też człowiek, jeżeli będziesz nieustannie obciążał go swoimi problemami nie będziesz mile widziany. Jeżeli umiesz zatroszczyć się o siebie i zadbać o ludzką relację z szefem w nagrodę możesz liczyć na informację, naukę a czasem nawet na pomoc w ramach skromnych możliwości szefa. Dla lepszego zrozumienia szefa Marcin polecał lektury:
Jednominutowy menedżer (Ken Blanchard)
Jednominutowy menedżer spotyka małpę (Ken Blanchard)
7 nawyków skutecznego działania (Stephen Covey)
Marek Kirejczyk, Tomek Łasica i Mateusz Srebrny
Po przerwie na lunch zamiast prezentacji była gra a konkretnie Ball Point Game. Uczestnicy konferencji podzieleni na 3 grupy mieli za zadanie opracować w 6 iteracjach sposób na przeniesienie jak największej liczby piłeczek. Każdy członek zespołu powinien dotknąć przenoszonej piłki, zaś piłka nie mogła dotknąć ziemi. Gra po przerwie na lunch była dobrym pomysłem, bo rozproszyła naturalną po posiłku senność i ożywiła atmosferę. Dała też możliwość do małego networkingu, podając sobie piłkę z rąk do rąk łatwiej się przedstawić, poza tym wspólne zadanie zbliża ludzi. Generalnie wszyscy byli zgodni, że rozwiązywanie zadania metodą kolejnych prób dało lepszy efekt niż dłuższa sesja planowania. Ciekawe jaka byłaby konkluzja gdyby zamiast piłek przenosić jajka? Nie chodzi tu o rujnowanie relacji z właścicielem sali, lecz o wpływ jaki ma łatwość zniszczenia obiektu próby na strategię rozwiązania zadania. W tym przypadku chodziło bardzie o fizyczne rozruszanie uczestników tudzież efekt socjalny, co udało się znakomicie i było dobrym wprowadzeniem do prezentacji o grach w rozwoju oprogramowania.
Sponsor konferencji Itvivus.pl
Firma z Rygi dostarczająca rozwiązania na rynku finansowym. Szuka developerów java i specjalistów od testów (QA). Ciekawa była formuła prezentacji, zamiast opowiadać cuda o swoich przewagach powiedział kogo szuka i zapytał czy tacy ludzie są na sali.
Prezentacja nosiła tytuł Agile Games i dotyczyła zastosowania gier dla usprawnienia pracy zespołu. Świeży przykład Ball Point Game pokazał, że gry ożywiają zespół i poprawiają nastrój. Człowiek szczęśliwy pracuje lepiej i wydajniej. Dodatkowo kreatywne myślenie wymaga oderwania się od rutyny, w czym gry znakomicie pomagają. Gra pozwala na wyciągnięcie ludzi z maniery. Jeżeli w zespole mamy nieustannego krytyka, to gra prowadzona w konwencji kiedy rozdzielamy wypowiedzi na bloki (np. co się zdarzyło, co było dobre, co było złe, co chcemy zmienić) może go wyciągnąć poza ulubioną krytykę. Wszystko dlatego że to tylko gra i takie zasady zabawy ustaliliśmy. Tomek opowiadał też o szkoleniach prowadzonych w konwencji gier, na przykład jednodniowe szkolenie Scrum gdzie budowano makietę zamku z improwizowanych materiałów. Podobno jako budulec rewelacyjnie spisują się makarony. Tomek polecał stronę TastyCupcakes gdzie można znaleźć ciekawe recepty na gry. Gra ma stworzyć bezpieczne środowisko do zabawy, która nauczy ich czegoś użytecznego.
Prezentacja Agaty Lean Startup w praktyce opowiadała o tym jak zrobić nowy produkt korzystając ze struktury starej firmy, której tradycyjna oferta ma kurczące się grono klientów. Young Digital Planet zostało stworzone prze koncern Sanoma. W ramach grupy działa inkubator nowych pomysłów, który wspiera je początkowo radą i dobrym słowem, zaś kiedy nabiorą realnych kształtów zasobami niezbędnymi do dalszego wzrostu (programiści, środki na marketing, etc.). Produktem Agaty była gra questrunner przeznaczona dla uczniów szkół podstawowych i gimnazjów, która uczy np. historii przez zabawę w terenie. W startupie problemem jest brak opinii klienta o przyszłym produkcie. Dlatego mentor przydzielony przez inkubator domagał się włączenia potencjalnych użytkowników w prace rozwojowe. Agata nawiązała współpracę ze szkołą i przeprowadziła testy prototypu gry w terenie. Scenariusz przewidywał wyszukiwanie w Gdańsku miejsc dawniej używanych do karania złoczyńców. Sukces prototypu ekipa twórców poznała po trudności w nadążeniu za grupą dzieciaków wciągniętych przez grę. Questrunner powstał w ciągu 9 miesięcy, zgodnie z tradycją startupów pierwszy klient zamówił produkt, który jeszcze nie był gotowy. Agata zwracała uwagę na korzyści z iteracyjnego podejścia do budowy produktu i udziału klienta w tworzeniu rozwiązania, dzięki czemu rośnie motywacja zespołu i spada ryzyko rozminięcia się z potrzebami klienta. Koncentrując się na wykonaniu zadania w takich warunkach zaskakująco dużo można zrobić w 5 dni.
Michał Ślizak i Danuta Bemowska
Prezentacja nosiła tytuł Stakeholder jungle – a survivor’s guide. Chodziło o to jak przeżyć ścięcie dwóch liderów i dzielić skromne zasoby zespołu tak, żeby sposobem podziału nie tworzyć konfliktów. Oczywiście żaden z liderów życia nie stracił, zmienił tylko stanowisko. Pierwszy z nich był zwolennikiem centralizacji zarządzania i odpowiedzialności. Chronił zespół za cenę przeciążenia siebie, pierwszy przychodził do pracy i ostatni wychodził. Zwolnienie członków zespołu z odpowiedzialności i zrozumienia tego co dzieje się dookoła było pozornie miłe, ale ograniczało możliwości rozwoju, bo rozwój pracownika w firmie wymaga szerszego kontekstu. Oczywiście kiedy lider odszedł nikt nie wiedział jak prowadzić zespól i tu organizacja podała pomocną dłoń mianując nowego szefa. Nowy lider lubił wyzwania, podejmował się realizacji większej liczby zadań niż poprzednik. W rezultacie wzrosła nominalna wydajność zespołu i spadła jakość pracy mierzona liczbą błędów w pisanych skryptach testowych. Nastąpiła kolejna zmiana lidera, tym razem wyznaczono jednego z członków zespołu, który dostał dodatkowe obowiązki. Okazało się że konieczność ujawnia możliwości. Nowy lider postanowił wprowadzić zmiany organiczne. Podzielił się władzą i odpowiedzialnością z zespołem, wspólnie wprowadzili nowe metody pracy. Dla uporządkowania strumienia zadań zespołu wdrożono kanban. Zadania podzielono według wielkości i ważności wizualizując to na tablicy. W rozwiązywanie sporów co do ważności zadań zaangażowano ich właścicieli, co przesunęło konflikt poza zespół i pozwoliło na poznanie zdania organizacji (klienta). Pilne i małe zadania dostały wyższy priorytet. W zespole wprowadzono zwyczaj dzielenia się wiedzą przez pracę w parach i krótkie (15 minut) prezentacje wygłaszane bez specjalnego przygotowania. Jeden ze słuchaczy spisywał podsumowanie prezentacji na wiki, wygłaszający prezentację weryfikował wpis. Decentralizacja zarządzania i nowe metody pracy sprawdziły się w praktyce. Wzrosła wydajność zespołu, spadła liczba błędów w tworzonych skryptach testowych.
Prezentacja Agile Bootcamp. Jak użyć agile, żeby uczyć agile pokazała jak w grupie Allegro rozwiązano problem przygotowania ludzi do wdrożenia Scrum. Jak wiadomo istotną role w tej metodyce odgrywa Scrum Master. Osób o takim profilu nie było wiele na rynku. Próbowano ich szukać przez ogłoszenia, najlepsze wyniki dało ogłoszenie treści: Szukamy Scrum Mastera. Obowiązki bycie Scrum Masterem (naprawdę). Wdrażanie nowości wyłącznie w oparciu o ludzi nowych w organizacji jest ryzykowne. Dlatego równolegle uruchomiono program szkolenia dla pracowników, którzy mieli motywację do objęcia nowej roli. Kandydatów szukano wśród developerów, kierowników liniowych, “klasycznych” kierowników projektów, pracowników HR. Ciekawe było to, że ze szkolonych kierowników liniowych nikt nie został w roli Scrum Mastera, zostali w niej wszyscy kierownicy projektów. Bardzo dobrymi w nowej roli byli też kandydaci z HR. Program szkolenia zrealizowano za pomocą Scrum. Okazało się, że wbrew powszechnym opiniom Scrum jest metodyką na tyle elastyczną, że można go używać do wielu rzeczy, nie tylko tworzenia oprogramowania. W Allegro znakomicie sprawdził się przy szkoleniach. W sumie z materiału szkolenia łatwo zrobić product backlog. W każdym sprincie wybieramy jaką część wiedzy chcemy opanować i jaką metodą. Można wybrać książki, webinaria, pracę z mentorem, pracę z zespołem realizującym projekt jako zastępca Scrum Mastera. Daily Scrum znakomicie nadaje się do śledzenia postępów, na koniec zaś mamy sprint rewiew meeting gdzie prezentujemy rezultaty i potwierdzamy skuteczność nauki. Dopasowanie metody do preferencji studenta i specyfiki partii materiału potwierdziło prawdziwość maksymy przypisywanej Konfucjuszowi:
Powiedz mi a zapomnę
Pokaż a zapamiętam
Pozwól zrobić a zrozumiem
Wyniesione z konferencji
- Inspiracja ma ograniczony termin ważności.
- Zaskakująco dużo można osiągnąć w 5 dni koncentrując się na zadaniu.
- Scrum można stosować do zarządzania dowolnym projektem.
- Ortodoksyjne trzymanie się metodyki (nawet Scrum) jest sprzeczne z filozofią Agile.
- Wczesne zaangażowanie klienta zwiększa szanse na sukces startupu.
- Chwila zabawy i trochę jedzenia skokowo poprawiają nastrój i uwagę zespołu.