Polecono mi przeczytanie książki
Learning Agile. Stronię od takich pozycji ze względu na ich zerowe przełożenie programistyczne, ale najwyraźniej przyszła pora zmienić podejście, bo za często domaga się ode mnie umiejętności zbudowania i poprowadzenia zespołów programistycznych.
W lekturze tej książki nie byłoby nic nadzwyczajnego, gdyby nie zbieżność wydarzeń, która sprowadziła czytanie w wolnej chwili do czytania w czasie służbowym jako pełnoprawne zadanie projektowe (!)
Zaintrygowany? Ja byłbym, a nawet jestem!
Dzisiejszy dzień rozpocząłem od pożegnania zespołu, który przez ostatnie tygodnie borykał się z dostarczaniem oprogramowania na czas.
Mój czas dobiegł końca - zespół działa i jest gotowy do samodzielnego podejmowania decyzji z pomocą osób odpowiedzialnych za docelową postać wytwarzanego produktu. Można by o tym pisać całe tomy - kto, kiedy, dlaczego, po co, itp. - ale istota sprawy to aż kłujący w oczy brak doświadczenia mojego i zespołu w planowaniu i późniejszym realizowaniu założonego harmonogramu. W zasadzie nałożyły się na to młodość zespołu oraz brak myślenia startup'owego (w którym w moim wyobrażeniu zakłada się czas finansowania, a jego niedotrzymanie skutkuje natychmiastowym rozwiązaniem zespołu -- takie myślenie bardzo pomaga mi w podjęciu decyzji co jest aktualnie ważne i czy zespół ma dane zadanie robić).
Leżeliśmy na całego.
I wtem kolega z zespołu postanowił "wyposażyć" się we wspomnianą książkę
Learning Agile. Super, ekstra i fajnie byłoby poczytać, ale jak tu poradzić sobie z "delivery" po nocach i jednocześnie czytaniem książki?! I tak sobie książka poleżała tydzień na moim biurku, a my jak w ukropie lataliśmy łatać dziury. Pewnie popełnialiśmy wszystkie możliwe błędy prowadzenia projektu informatycznego wytwarzania oprogramowania biorąc dowolną metodykę jego prowadzenia.
Już sama obecność książki dodawała nam jednak otuchy, że jak już wszystko się skończy, to po tym całym zamieszaniu przyjdzie w końcu czas, kiedy choćby nieznacznie, ale odetchniemy i będzie można upajać się zawartością książki (
"nadzieja umiera ostatnia", co?)
Jakoś tak się złożyło, że z tym zespołem upajać się zawartością tej książki już nie będę, ale książka została ze mną.
Tego samego dnia pojawiłem się w innym zespole programistycznym, w którym metodyki lekkie
agile brano poważniej pod uwagę i wytwarzanie "softu" jest u większości w DNA. Chce się go przez wszystkich, ale brakuje lidera
agilisty, który przeprowadziłby zespół przez zaułki wdrażania tego narzędzia zgodnie ze sztuką. Przyjdzie pewnie borykać się nam z antywzorcami wdrażania agile nie raz i nie dwa. Bywa (chociaż wierzę, że ten wpis wzbudzi litość u kilku agilistów, którzy odezwą się z propozycją komercyjnej pomocy we wdrożeniu procesu - będę zobowiązany!)
Książka w mojej dłoni powędrowała do wszystkich osób w zespole, które wprawdzie wyraziły zainteresowanie agile i książką, ale niekoniecznie samym sposobem pozyskania odpowiedniej wiedzy w temacie czyli czytaniem. To kolejny zespół, który jest przeładowany zadaniami i ni jak nie można znaleźć miejsca na czytanie książki. Bywa.
Jako, że doświadczenia ostatnich 2 lat pokazują, że czeka mnie "kariera" osoby zestawiającej zespoły informatyczne celem uruchomienia linii produkcyjnej do wytwarzania oprogramowania, to ta właśnie książka okazuje się być lekturą obowiązkową dla mnie. Trafiłem z nią w końcu do pokoju podatnego na moje sugestie i w którym zgodziliśmy się na...
podsumowania rozdziałów!
Okazuje się, że jakkolwiek samo czytanie książek nie jest pożądane przez kogokolwiek z zespołu programistycznego, to już wspomniane podsumowania w postaci listy najważniejszych rzeczy z kilkoma słowami wyjaśnienia, już tak. Można by potraktować to jako porażkę "systemu" edukacji informatycznej, ale dla mnie to była szansa zrobienia czegoś zamiast lamentowania i zrobienia niczego.
I tu zaczęło się moje zdumienie, bo owe podsumowywania zaproponowano umiejscowić na Wiki zespołu! Pomysł nabrał rumieńców projektowych i stał się dobrem zespołu. Odpalono zadanie w JIRA na potrzeby tego przedsięwzięcia i czytanie książki stało się sprawą ważną, bo zgodną z dyrektywą odgórną, która mocno podkreślała wdrożenie agile, a w zespole poszanowanie i stosowanie jego zasad.
W ten sposób czytanie książki
Learning Agile stało się zadaniem projektowym.
Zdumiony? Ja wciąż jestem. I nie mogę uwierzyć, jak niewiele trzeba, aby z często niechcianego obowiązku nauki po pracy, zrobić pełnoprawne zadanie projektowe ku szczęśliwości wszystkich zaangażowanych. Ostatecznie nie powinno być stratnych takiej decyzji - ja "zaliczę" książkę, wiedzę przekażę zespołowi w postaci podsumowań w stylu notatek na blogu, aby w ten sposób zainicjować proces przyswajania wiedzy metodyk lekkich prowadzenia projektów w zespole programistycznym. Ja jestem
in plus, zespół również, a szefostwo dostaje produkt wysokiej jakości i terminowo (przynajmniej teoretycznie). Cudo!
Docelowo pewnie czeka nas zaproszenie do zespołu praktyka, który przedstawi nam, co i jak się stosuje w praktyce, ale przyczółek zmian już wyczuwam. Idzie ku dobremu!
Matt, zlituj się, pomógłbyś nam trochę i pojawił na kilku spotkaniach u nas w biurze, co? Wskazałbyś innych ekspertów w temacie, a my oddamy się do Twojej/ich dyspozycji. Może Tomek i Mateusz mogliby również wesprzeć nasze starania?
Ogłoszenie parafialne: kolejne zespoły, które doświadczą mojej obecności w roli członka zespołu, mogą liczyć na permanentną indoktrynację agile'ową, którą na początku zdobędę lekturą książki
"Learning Agile" oraz z życia doświadczając praktycznie mechaniki prowadzenia zespołów programistycznych. Na chwilę obecną mam na swoim koncie 3 przypadki zmontowania zespołu i zestawienia linii produkcyjnej w roli lidera, co daje mi jedynie mgliste pojęcie o problemie. Nie poprzestaję jednak.
Pierwsze pomysły o zorganizowaniu czegoś na kształt całodniowej konferencji wokół języka Scala pojawiły się około konferencji Scalar w kwietniu 2014. Wtedy spotkałem się z Łukaszem Sową. Zeszło nam się na rozmowach aż do czerwca, kiedy w Krakowie odbyła się impreza podobnego kształtu.
