[PL] Scrum Droid

Jakiś czas temu miałam okazję uczestniczyć w beta warsztatch Droid-Scrum organizowanych przez firmę Octigo przy współpracy GeekGirlsCarrots.

Warsztaty były reklamowane jako dopiero wchodzące na wrocławski rynek praktyczne poznanie scrum’a za pomocą klocków lego i były przeznaczone na 3 godziny (wersja standardowa zakłada dwa dni szkolenia).

Całe szkolenie można było podzielić na trzy części:
1. Teoria
2. Poznanie klocków (jak się już po warsztatach okazało był to “Sprint 0”
3. Scrum w praktyce

Wprowadzenie do Scrum’a i Agile trwało aż godzinę. Bardzo długo. Wydaje mi się, że podczas praktycznego poznania Scrum’a potrzebne jest minimum teorii, którą będzie można poznać właśnie praktycznie, a nie teoretycznie.
Tutaj moją uwagę przykuły slajdy, które były pomieszane językowo – część po polsku, część po angielsku. Dodatkowo prowadzący nie byli do końca przygotowani od strony technicznej. Wielkość zdjęć na slajdach nie była przystosowana dla uczestników z końca sali oraz nie potrafili zrobić pełnego ekranu z Adobe Reader’a. Ale może na Mac’u to nie działa (nie mam Mac’a, więc się nie znam). Na uwagi ze strony publiczności (tak, tak, właśnie dziewczyn) aby wcisnąć Ctrl+L stwierdzili, że to i tak nie zadziała i szkoda czasu..

Po teorii Scrum’a przyszła część na wyjaśnienie zasad.
Problem: W kopalni nastąpił zawał chodnika. Na szczęście nikt nie zginął, ani nie został ranny, jednak nie możliwości szybkiego uwolnienia górników. Okazało się jednak, że chodnikiem może przecisnąć się coś małego i sprawnego. Na przykład robot kroczący, który mógłby dostarczyć odizolowanym ludziom wodę, jedzenie, latarki oraz środki komunikacji. Zarząd kopalni szybko powołał zespół, którego celem jest skonstruowanie robota. Ze względu na presję na czas oraz dużą innowacyjność projektu postanowiono wybrać podejście Scrum do tego celu. Problemem jest nie tylko nieznana technologia, ale i nieprzewidywalne warunki pod ziemią. Celem zespołu jest zbudować robota, który dotrze do końca chodnika i zaniesie uwięzionym górnikom potrzebne artykuły.

Zasady:
20 min zapoznania się z zadaniami + scrum poker
10 min budowanie robota
30 min rozmowa o zadaniu, zespole i co należy poprawić.

Podczas praktycznej części zostały utworzone dwa zespoły. Do każdego został przydzielony mentor, który miał przeprowadzić nas przez świat scrum’a. Jednak podczas tłumaczenia zasad każdy zespół był nie  równo traktowany. Nasz stał i słuchał (ponieważ nasz mentor chciał tylko na sobie skupić naszą uwagę), zaś zespół przeciwny mógł się zapoznawać jakie klocki zostały przekazane do tej zabawy.

W końcu przyszedł czas na “Sprint 0”, gdzie krok po kroku nasz mentor miał nas przeprowadzić przez ten sprint. Dostaliśmy wytyczne, czyli robot powinien mieć:
– gumowe podeszwy,
– antenkę długości dwóch centymetrów,
– mieć szczelinę (między spodem a ziemią) jeden centymetr,
– stać stabilnie na czterech nogach,
– mieć niebieski kolor

Ponieważ było mało klocków koloru niebieskiego, przekonaliśmy “klienta” (czyli naszego mentora), aby sama antenka była koloru niebieskiego. Reszta zadań była prosta, więc  robota stworzyliśmy w  7  minut, który był zgodny ze specyfikacją.

Podczas introspekcji wyszły takie rzeczy jak:
– Brak komunikatywności – większość rzuciła się na klocki aby jak najszybciej wykonać zadanie
– Brak rozmów – w jaki sposób w ogóle powinniśmy podejść do zadania?
– Brak scrum master – a raczej brak osoby, która pilnowałaby, aby konkretne zadania nie powielały się i aby cały zespół był wykorzystany jak najefektywniej

Została więc podjęta decyzja, że zostanie wyłoniony scrum master, który rozdzieli te zadania i będzie dbał o to, aby każda część została wykonana.
I przyszedł czas na “Sprint 1”.
Tym razem robot powinien:
– posiadać sześć nóg
– posiadać gumowe koła
– posiadać gąsienice
– potrafić przejść przez przeszkody
– posiadać cztery nogi
– … (i kilka innych, których już nie pamiętam)

Ogólnie dużo wymagań na raz wrzuconych i mało czasu na zapoznanie się i dyskusje, co i jak powinno zostać wykonane oraz które elementy w której kolejności należało wykonać, tak aby ich nie wykluczać nawzajem.

Więc zostało postanowione, że oceniamy i bierzemy pod uwagę moduły wg priorytetu, który biznes określił. Nie było to najlepsze, ponieważ część rzeczy się wykluczało zgodnie ze specyfikacją. Po za tym wyszedł czynnik ludzki, czyli nasz nowy scrum master nie miał siły przebicia, gdyż zawsze znajdzie się osoba która wszystko wie najlepiej, chce innymi rządzić i rozstawiać ich po kątach, ale za nic nie chcę ponieść odpowiedzialności swoich decyzji.
W każdy razie, wszystko to co zostało zbudowane w “Sprint 0” zostało zburzone, aby od początku stworzyć coś zupełnie nowego w “Sprint 1”.
Nam nie udało się spełnić wymagań założonych dla tego sprinta.

I na tym zakończyły się warsztaty z praktycznego poznania scrum’a. Punkt 20.00 trzeba było wszystko odłożyć, bo miały być dokładnie 3 godziny (nie mniej i nie więcej).

Ogólnie warsztaty reklamowane są jako warszaty nie tyko dla informatyków. Ze swojej perspektywy nie widzę innej możliwości niż wyjście scrum’a od programistów.. Ale biznes też może tworzyć swoje rzeczy zgodnie ze scrum’em i naciskać na programistów, ale czy to będzie efektywne?

Miałam nadzieje, że podczas warsztatów będę miała okazję zobaczyć jak wygląda od strony praktycznej “idealny” scrum. Jedynie co poznałam podczas warsztatów, to:

– w każdym społeczeństwie istnieją osoby, które dominują, nie biorąc za swoje decyzje odpowiedzialności
– ważne jest dokładne zbadanie tematu, a nie rzucanie się na to co biznes zechciał
– komunikacja i aktywne słuchanie to jedyna opcja, aby projekt działał dobrze