Relacja z Agile by Example light 2016

W sobotę, 11 czerwca odbyła się „lekka”, 5 godzinna odsłona jesiennej konferencji AgileByExample. Miałam przyjemność uczestniczyć w niej jako prelegent. Jak ujęłabym swoje wrażenia jednym zdaniem? Duża dawka doświadczeń pracy z wykorzystaniem agile’a, w przyjemnej, kameralnej atmosferze. Jeśli jesteście ciekawi szczegółów, zapraszam do lektury.

Interesująco wyglądała już sama niejednorodna agenda spotkania. Konferencja rozpoczęła się 45 minutowym wystąpieniem Pawła Rzymkiewicza o budowaniu zwinnego zespołu inżynierii; pozostałe prelekcje – Łukasza Aziukiewicza o skalowaniu Scruma w małej skali, Tomka Boińskiego  o Project Managerze w świecie agile, Jakuba Drzazgi o tym, w jaki sposób pomógł klientowi wyjść z sytuacji krytycznej i moja o doświadczeniach pracy leanem i kanbanem trwały 25 min i zostały przeplecione dłuższymi warsztatami, poświęconymi wartościom agile’owym, przeprowadzonymi przez Annę Zaręmbę. Efekt? Z mojej perspektywy 5 godzin minęło naprawdę niepostrzeżenie.

Paweł Rzymkiewicz: Budowanie zwinnego zespołu inżynierii



Paweł, Head of Engineering w Codility – firmie oferującej software umożliwiający szybką ocenę umiejętności programistycznych u kandydatów ubiegających się o pracę, rozpoczął swoje wystąpienie od dosyć obszernego nakreślenia historii firmy. Było to o tyle uzasadnione, że dalsza część jego prezentacji dotyczyła tego, w jaki sposób łączy on intensywne powiększanie swojego zespołu z dbaniem o kulturę firmy, która wyrosła jako start-up. Paweł omówił 2 obszary mające kluczowe znaczenie: Zatrudnienie i Tworzenie dobrego środowiska pracy. Opiszę dla Was tematy, które w kontekście tych obszarów szczególnie mnie zainteresowały.

  1.    Zatrudnianie

Pewnie nie zdziwi Was, że pierwszym etapem rekrutacji jest pozytywne przejście testu Codility; to, co dzieje się później, tworzy kulturę firmy. Do drugiego etapu (1 rozmowa) jest zapraszana jedna osoba –  liczy się kolejność zgłoszeń wg zdanego testu. Przy pozytywnym scenariuszu, czekają ją 2 rozmowy z 2 parami specjalistów (osoba techniczna i od kompetencji miękkich); przy negatywnym, przygoda kończy się już po 1 rozmowie. Po każdym ze spotkań osoby rekrutujące próbują przekonać się nawzajem, dlaczego chciałyby pracować z kandydatem. O zatrudnieniu decyduje cała 4, również w podobnej konwencji – dlaczego chcemy z nią/ nim pracować. Spory nakład pracy i czasu po stronie firmy, tym bardziej, że ok 60% zaproszonych osób nie zostaje zatrudniona. Skąd więc ten pomysł? Paweł podkreślał, że rozmowy toczone z tylko jedną osobą (czego jest ona świadoma) pozwalają zbudować z nią wyjątkową relację już na etapie rekrutacji. Cały proces jest natomiast urzeczywistnieniem wartości cenionych w firmie, takich jak: nie porównujemy ludzi ze sobą, czy podejmujemy decyzje przez konsensus, porozumienie (co Paweł powtarzał jak mantrę). Do mnie to przemawia i podziwiam tę drogę, jak ją odbieram, „pod prąd”, bo, zdaje się, że większość firm IT i nie tylko, stosuje nieco inne podejście.

  1.    Tworzenie dobrego środowiska pracy

Również przy tym temacie Paweł poświęcił sporo miejsca kulturze firmy tworzonej przez „konsensus”, wspólne podejmowanie decyzji. Opowiedział też m.in. o „Hack days”, korespondujących z Google’owską zasadą „20% time”, poświęconych na dowolnie ukierunkowaną kreatywność i innowacyjność pracowników. Co 2 tygodnie każdy może spędzić dzień pracy w dowolny sposób (research, kodowanie…). Mimo, że nie ma ograniczeń, właśnie podczas takich swobodnych piątków powstała trzecia noga i najnowsze „dziecko” Codility – CodeLive, umożliwiająca przeprowadzanie rozmowy on-line, czy integracja ze Slackiem i HipChatem, która okazała się hitem wśród klientów. Takich strzałów w 10 być może będzie więcej, bo firma stawia mocno na zasadę „customer exposure”, realizowaną np. poprzez obsługę maili od klientów przez developerów i ich udział w części rozmów sprzedażowych. Dzięki temu realne potrzeby klienta stają się częścią codziennej pracy całego zespołu. „Hack days” w Codility zostanie wkrótce rozszerzone o „Hack weeks”. Ciekawi mnie, jak temat innowacyjności będzie rozwijał się w tej firmie. Historia Google’a pokazuje, że może to ewoluować w różny sposób. Mam nadzieję, że Paweł opowie o tym za jakiś czas:)

Paweł podsumował swoje wystąpienie stwierdzeniem, że kiedyś najważniejsza była dla niego specjalizacja, teraz są ludzie. Przekonujące, biorąc pod uwagę choćby opisane przeze mnie przykłady.

Łukasz Aziukiewicz: Skalowanie Scruma w Małej Skali

Łukasz podzielił się swoim doświadczeniem pracy z grupą ok. 20 osób nad 1 produktem dla zewnętrznego klienta w STX Next. Mimo, że opowiedziana przez niego historia sięga czasów sprzed pojawienia się frameworków do skalowania Scruma typu Less czy Nexus, przy tak małej skali i tak trudno byłoby z nich skorzystać. Łukasz opowiedział o tym, jak metodą prób i błędów, wspólnymi siłami, udało się wypracować efektywną i satysfakcjonująca wszystkich formę współpracy 3 zespołów, rozwijających 1 produkt. Agile w najlepszym wydaniu – inspect & adapt. On sam dołączył do zespołów jako Scrum Master w momencie, kiedy próbowały synchronizować prace podczas globalnych daily (18 developerów na 1 daily). Z czasem okazało się, że żadna forma globalnej współpracy nie zdała egzaminu – zespoły miały silne poczucie tożsamości i przy próbach  zatarcia granic pomiędzy nimi jeszcze bardziej zamykały się w swoich silosach. Dobrym tropem okazało się wzmacnianie współpracy w ramach samych zespołów. Produkt został podzielony na 3 sub-produkty, a całością zarządzał 1 Product Owner za pomocą globalnego backloga, który następnie zasilał backlogi poszczególnych zespołów. Jedynym wspólnym zdarzeniem Scrumowym było review; zespoły miały oddzielne backlog refinementy, planowania, retrospektywy i daily. Łukasz podkreślił, że wypracowany model współpracy wymagał ogromnego zaangażowania ze strony Product Ownera; ze strony Scrum Mastera zapewne też:) Co ciekawe, mimo że finalna forma współpracy wzmacniała niezależność zespołów, developerzy wyszli z inicjatywą wymiany wiedzy i zaczęli przygotowywać dla siebie nawzajem dema techniczne. Podczas wystąpienia Łukasza pojawiło się sporo szczegółowych pytań np. o to, jak przebiegały backlog refinementy, w jaki sposób zespoły radziły sobie z zależnościami, czy naprawą błędów. Wciągająca, przyjemnie opowiedziana historia.

Tomasz Boiński: Agilowa wojna światów z Kierownikiem Projektu na froncie czyli produkt vs projekt

Tomasz Boiński
Tomasz Boiński

Tomek opowiedział na czym, jego zdaniem, polega rola Project Managera w świecie agile i dlaczego nie warto bezrefleksyjnie usuwać jej z agile’owej sceny. Temat jest ciekawy choćby w kontekście Snowdenowskiego Cynefina. O czym natomiast opowiedział Tomek? M.in. o wojnie światów na linii zarządzania projektem a rozwoju produktu, różnicach pomiędzy tradycyjnym project managementem i agile project managementem, przyczynach przez które PM jest usuwany w momencie wprowadzania Scruma; wreszcie, kiedy warto jednak tego Kierownika Projektu zatrzymać – wg Tomka wtedy, „gdy dodaje wartości poprzez unikalne kompetencje”. Na przykład: kiedy trzeba zarządzić wieloma zależnościami, dostawcami, czy złożonością merytoryczną. Trudno mi odnieść się do tego, o czym opowiadał z jednej przyczyny – zabrakło „example”, przykładów z życia, konkretnych przypadków obrazujących tematy poruszone podczas wystąpienia. Dodatkowo, słuchanie utrudniały mi slajdy – z dużą ilością treści, która mnie rozpraszała. Tomek podsumował swoje wystąpienie stwierdzeniem, że organizacja powinna mieć jasno określone zasady, kiedy pojawia się kierownik projektu; zapewnił, że w mBanku, gdzie pracuje, takie zasady powstały.

Anna Zaręba: Jakie faktyczne wartości przyświecają nam w pracy w Agile

Do warsztatów podeszłam, przyznam, sceptycznie. Mieliśmy rozmawiać nie o doświadczeniach, co wydawało mi się ciekawsze, a o wartościach. Anna podzieliła spotkanie na 3 etapy. W pierwszym z nich mieliśmy samodzielnie przemyśleć, jakie wartości są dla nas szczególnie ważne w kontekście naszej pracy. Zaproponowała do tego coachingową technikę perspektywy czasu – co chciałbyś, żeby ludzie powiedzieli o Tobie za 20 lat, jakie wartości wymieniliby, wystawiając fetę na twoją cześć? Kolejny etap to przepracowanie wartości w grupach, a ostatni zwizualizowanie ich za pomocą kolażu. Podsumowaniem warsztatów była prezentacja prac i głosowanie na najciekawszy projekt. Moje podejście do tematu warsztatów zmieniło się wraz z rozpoczęciem drugiego etapu – rozmowa w moim zespole okazała się dla mnie inspirująca. Intensywna, interaktywna forma ćwiczenia, kontrastująca z wcześniejszymi prelekcjami, ożywiła i ośmieliła uczestników spotkania. Była fajną okazją do poznania nowych osób, a zarazem ciekawym wstępem do rozmów kontynuowanych podczas after party. Moim zdaniem włączenie formy warsztatowej do tego typu konferencji to strzał w 10.

Warsztaty ABE light 2016
Warsztaty ABE light 2016

Jakub Drzazga: Ciężki żywot Agile Coacha – wyjście z sytuacji krytycznej

Kuba w dowcipny i wciągający sposób opowiedział historię, która nie miała prawa się wydarzyć. A jednak;) Swoją drogą, dla wielu z Was może momentami brzmieć znajomo:) Sytuacja krytyczna – klient z branży sportowej chce rozpocząć sezon dokładnie 15 kwietnia z serwisem w wersji webowej i mobilnej. Otrzymuje zamówienie terminowo i jest zachwycony. Chwilowo, bo już następnego dnia okazuje się, że część webowa produktu to kot w worku – nie spełnia podstawowych założeń, jak choćby działająca rejestracja użytkowników. Kuba rozpoczyna przygodę od współpracy z zespołem webowym i wychodzi od analizy sytuacji, z której wyłania się kilka ważnych wniosków – projekt jest ukończony w 85%, ale… brakuje mu działających wersji, nikt dokładnie nie wie, jak naprawdę wygląda sytuacja – nie ma dokumentacji, product backloga, w jira jest natomiast bałagan, a na pokładzie wycieńczony, uprzedmiotowiony i ręcznie sterowany team (micro management w najlepszym wydaniu) od tygodni pracujący grubo ponad normę. Dookoła panuje „blamestorming”, a management zamiast skupić się na tym, jak wyjść z trudnej sytuacji, coraz mocniej naciska na zespół i szuka kozła ofiarnego. Od czego zaczął Kuba? Od odsunięcia od projektu Project Managera i decyzji o pozostawieniu zespołu (innego wyboru, prawdę mówiąc, nie miał), któremu dał odpocząć po morderczym maratonie. Jaką przyjął strategię? Jak najszybciej dać klientowi poczucie bezpieczeństwa i stworzyć wersję beta serwisu dla friendly userów. Na czym oparł taktykę działania? Wartościach: transparencji i szczerości – mówimy, jak jest, zasadach: inspect & adapt oraz wzmocnieniu roli i samodzielności zespołu (ang. empower team). Zespół otrzymał jasny cel, powstał zrozumiały dla wszystkich stron sposób pracy – przynajmniej raz w tygodniu odbywają się demo dla klienta, umożliwiające mu regularny feedback. Zespół zaczął synchronizować prace podczas daily i wyciągać wnioski podczas retrospektywy, co dało mu przestrzeń do samoorganizacji i usprawnień. Za miarę efektywności przyjęto działający soft.

Kuba wciąż współpracuje przy tym projekcie. Trzymam kciuki i gratuluję okiełznania chaosu.

Jakub Drzazga
Jakub Drzazga

Na koniec duży ukłon w stronę Organizatorów konferencji, którzy zadbali o każdy szczegół. Spotkanie odbyło się w auli uniwersyteckiej z wyjściem na zewnątrz, co pozwoliło na spędzenie części warsztatów na świeżym powietrzu. Dosyć oficjalny charakter tego miejsca przełamały warsztaty, ale przede wszystkim prowadzący spotkanie, Łukasz Szóstek – szybko udało mu się wprowadzić przyjemną, kameralną atmosferę. Mimo, że konferencja była bezpłatna, uczestnicy mieli do dyspozycji wodę i przekąski, a w trakcie after party darmowe napitki. Z perspektywy prelegenta doceniam też dopięte na tip top tematy organizacyjne przed konferencją i zadbanie o technikalia na miejscu. Podsumowując, wielkie dzięki:)!

Łukasz Szóstek
Łukasz Szóstek pokazuje, jak dotrzeć na after party

O swoim wystąpieniu (Czego nauczyło mnie doświadczenie pracy leanem i kanbanem) pisać nie będę. Gdybyście jednak byli ciekawi prezentacji, znajdziecie ją tutaj. Za jakiś czas pojawią się w sieci nagrania wystąpień, więc stay tuned:)

I tak, z niecierpliwością czekam na jesienną edycję, pękatą od tematów.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x