Roundtables podczas Agile Management 2013 - Małgorzata Kusyk

 Roundtables podczas Agile Management 2013 - Małgorzata Kusyk
14-15 listopada 2013 odbyła się konferencja Agile Management 2013. 80 uczestników w nietypowej scenerii warszawskiego Space Club nie tylko mogło wysłuchać ciekawych prezentacji, ale również podzielić się swoimi doświadczeniami podczas czterech, 40 minutowych sesji okrągłych stołów - “roundtables”.

Chociaż idea “roundtables”, znana też czasami pod nazwą grupowy “speed” lub “flash” mentoring, jest już dość często stosowana poza granicami naszego kraju, to u nas jeszcze mało popularna. Większość uczestników konferencji deklarowała, że pierwszy raz spotkała się z taką formą i dla większości była ona bardzo ciekawym doświadczeniem. Zanim zdradzę jak przebiegały dyskusje przy moderowanych przeze mnie stołach kilka słów na temat samej formuły. W “roundtables”, ekspert z danego obszaru, w przypadku listopadowego wydarzenia były to osoby z doświadczeniem w metodykach zwinnych, spotyka się z małą grupą osób, maksymalnie 10, przy okrągłym stole. Uczestnicy wybierają interesujący ich temat i zaczynają debatę, przy czym każdemu przysługuje taki sam czas na wypowiedzenie się, a mentor pełni rolę moderatora dbając, aby każdy mógł wziąć w niej udział oraz naprowadzając, jeśli rozmowa zboczy z toru lub też jeśli wyczerpie się temat. W naszym przypadku lista propozycji tematów powstała wcześniej, a uczestnicy mogli zagłosować na najbardziej interesujące, które pojawiły się na konferencji. Zaproponowana tutaj formuła jest niezwykle skuteczna, gdyż czerpiemy wiedzę i doświadczenie nie tylko od jednego eksperta, jak to jest w przypadku prezentacji, ale również od siebie nawzajem, co dodatkowo może być niezwykle inspirujące. To tyle na temat formuły, a teraz zapraszam na krótkie podsumowanie tego co działo się podczas moderowanych przeze mnie sesji.

Rozpoczęliśmy od mojego ulubionego tematu “Agile w zespołach rozproszonych”. Już słyszę głosy: „Agile wirtualnie? Przecież sprawdza się tylko w zespołach zlokalizowanych w jednym miejscu”. Zgadzam się, to jest idealna sytuacja, jeśli zespół może siedzieć w jednym pokoju, ale świat nie jest idealny i możemy, albo stawić czoła tej rzeczywistości i wygrać, albo zginąć. Tego też zdania byli uczestnicy dwóch 40 minutowych debat. Temat okazał się tak popularny, że zaplanowano dwie sesje, które były też ciekawym doświadczeniem dla mnie, gdyż te dwie debaty były zupełnie inne, bo różne też były doświadczenia ich uczestników. Natomiast wszyscy jednogłośnie opowiedzieli się za rozpoczynaniem każdego projektu spotkaniem „face-to-face”, a jeśli nie jest to możliwe, stworzeniem warunków zbliżonych wykorzystując dzisiejszą technologię – „telepresence”, video konferencję, czy Skype. Także pozostałe spotkania powinny odbywać się w warunkach zbliżonych do „face-to-face”, a w szczególności spotkania planistyczne, demo, czy retrospektywy. Bardzo ważne dla współpracy jest zaufanie, a to jest tylko możliwe kiedy uda nam się zbudować głębokie relacje interpersonalne pomiędzy członkami zespołu, co w warunkach rozproszenia jest nie lada wyzwaniem i tu z pomocą mogą przyjść nam gry zespołowe, czy wspólne spotkania przy kawie – każdy w swojej lokalizacji, ale o tym samym czasie i z możliwością wizji i fonii.



Kolejnym tematem, który udało nam się poruszyć podczas sesji był „Zespół idealny w Agile”. I tu było sporo emocji związanych z pytaniami: kto powinien się w takim zespole znaleźć i jakie powinien posiadać kompetencje? Część uczestników uważała, że zgodnie z założeniami Scruma, w zespole powinny występować trzy role: Mistrz Młyna, Właściciel Produktu oraz członek Zespołu Deweloperskiego oraz, że Zespół Deweloperski powinien być interdyscyplinarny, czyli każdy z jego członków może charakteryzować się jakąś wybraną kompetencją, np. programowania, ale także powinien być w stanie podjąć się innych zadań, np. testowania, jeśli pojawia się taka konieczność w projekcie – model T (jedna dominująca kompetencja i jednoczesny rozwój innych pokrewnych). Pojawiły się też głosy, że płacąc słono za specjalistyczne umiejętności programistyczne byłoby marnotrawstwem wykorzystywanie ich do zadań związanych z testowaniem, chociaż była też opinia, że testowanie jest ukoronowaniem pracy zespołu i to testerzy powinni być lepiej wynagradzani. Na koniec większość opowiedziała się jednak za modelem T, argumentując to długofalową inwestycją w zespół.



Ostatnim tematem, który miałam przyjemność moderowania był „Agile w projektach infrastrukturalnych”. Jak połączyć dwa światy, ten zwinny, związany z tworzeniem oprogramowania, i ten bardziej tradycyjny, np. budowa nowej infrastruktury technologicznej? To pytanie zadaje sobie niejedna globalna organizacja, gdzie oprogramowanie to tylko niewielki fragment projektu. Z jednej strony sponsor oczekuje terminu i budżetu, z drugiej zwinny zespół programistyczny nie chce się podpisać pod żadnym zobowiązaniem. Ku mojemu zaskoczeniu, ale także wielkiej radości dość szybko zgodziliśmy się, że Agile to zmiana sposobu myślenia, a nie technologia. Dojrzałe zespoły zwinne znają swoją prędkość, dzięki czemu dość dobrze szacują czas potrzebny na wytworzenie nowej funkcjonalności. No cóż, nie będzie co do dnia, ale jakież to ma znaczenie? Czyż dziś nie bardziej liczy się dostarczona wartość, niż zrealizowany projekt na czas, zgodnie z budżetem i wymaganiami? Szczególnie, że tylko 9.8% projektów dostarcza to co zostało wcześniej zaplanowane.

Podsumowując jednym zdaniem, było interesująco i inspirująco, czyli serdecznie polecam!

Małgorzata Kusyk