Kto jest Twoim mentorem?

W czasie dyskusji przy wystąpieniu na Zwinnej Łodzi pojawił się też fajny wątek związany z mentorem. Zachęcam do tego, by w ramach rozwoju osobistego w ścieżce agile mieć mentora, szukać go na każdym etapie – zarówno przy pierwszych krokach w roli Scrum Mastera ale też gdy jest się już całkiem zaawansowanym. Sam przy okazji rekrutacji często pytam o to, kto jest Twoim mentorem,  posiadanie takiej osoby i współpraca z nią jest dla mnie ważnym sygnałem na temat danego kandydata. Niedawno miałem też rozmowę Bartkiem Janowskim z mojego zespołu, który zauważył, że udaje się mi zorganizować dla niego bardzo wartościowe sesje z naszym wspólnym mentorem i powodują w nim szereg rozmyślań, które procentują zmianami w postępowaniu jako Agile Coach, czy są inspiracją do głębszego szukania jakichś wątków zaznaczonych przez mentora.

Coś co fajnie Bartek wyłapał i sam potwierdziłem, jak ważną kwestią jest to, żeby pomyśleć o tym, żeby tego konkretnego mentora nie traktować jako jedynej studni, z której czerpie się wodę. Nawet, jeśli nasz mentor jest człowiekiem, który powoduje, że każda interakcja z nim powoduje, że wychodzimy lepsi, mamy lepsze przemyślenia, szukamy dalszych kwestii, które nam wskazał. I tak szukajmy dywersyfikacji takich przemyśleń, szukajmy dodatkowych studni, z których możemy czerpać.

Pytanie do każdego z Was: kto jest Waszym mentorem, ale też pytanie czy macie więcej niż jednego mentora? Czy macie więcej niż jedną osobę, która daje Wam do myślenia, z którą rozmowa jest być może czasem niewygodna. Niewygoda ta może wynikać z tego, że sposób widzenia tej osoby pewnych rzeczy jest trochę inny niż Twój i twojego pierwszego mentora, od którego nauczyłeś się czym jest agile i Scrum. Pomyślcie, czy czasem największy uzysk, największe okazje rozwojowe nie znajdują się właśnie w tym świecie zupełnie nowego mentora. Dosłownie poszukajmy tego alternatywnego guru, może gościa od zupełnie innej metody, niż tą, którą stosujemy na co dzień: może lepiej Was rozwinie w temacie Scruma, jak naczęstszy kontakt z ludźmi od kanbana, posłuchanie ich perspektywy, ich punktu widzenia, ich praktyk i ich metod, ich aktualnych trendów, ich najświeższych perspektyw. W ciemno zakładam, że taka głęboka relacja będzie bardziej rozwijająca niż jeszcze jeden kontakt, z jeszcze jednym trenerem scrumowym, który będzie Wam prawdopodobnie powtarzał te same historie, które już Wy znacie. Powiem więcej – być może więcej rozwiniecie się rozmawiając z ekspertem, który jest bardzo fajnym project managerem, ma naturalne prozespołowe podejście.  Warto czerpać z doświadczeń osób, które przeżyły prace projektowe przy naprawdę gigantycznych przedsięwzięciach, warto posłuchać jak takie rzeczy są zorganizowane, jakie przemyślenia ma taka osoba. My z perspektywy agile jesteśmy w stanie też zadać bardzo fajne i bardzo głębokie pytania takim osobom, o tematy relacji międzyludzkich, o inicjatywę członków zespołu, o ich samodzielność, o kulturę organizacji czy zespołu. Dla osób, które mają bardzo duże doświadczenia te rzeczy też będą istotne i jestem pewien, że chętnie o tym porozmawiają.  W długofalowym rozwoju w ścieżce agilowej świetnym kandydatem do inspiracji i poszerzania horyzontów może być doświadczony i odnoszący sukcesy menedżer wyższego szczebla.

Szukajcie okazji do tego, żeby mieć wiele studni, z których czerpiecie inspiracje. Dajcie sobie szansę do bycia popchniętym w jakieś obszary, w których sami na razie nie myśleliście, że będziecie chcieli się znajdować.

Warsztaty z agile dla menedżerów

Niedawno pisałem o sposobie na szkolenie z podstaw Scruma, jaki stosuję w mBanku. Warto wspomnieć, że jest jeszcze temat innego typu działań, które były realizowane w ramach rozwoju kompetencji zwinnych w organizacji. Najważniejsze dwie rzeczy które zrealizowaliśmy to warsztat dla managerów wyższego szczebla IT i warsztat dla biznesu. Była to odpowiedź na problem tego, że znajomość agile była niedoskonała. Warsztaty zorganizowaliśmy zaraz na samym początku transformacji, ze zrozumienia Scruma i agile, zwłaszcza z perspektywy managerskiej. Poprosiliśmy o to, by taki warsztat poprowadził Tomek Włodarek.

Na pierwszym z warsztatów (tych dla ścisłego grona kierownictwa IT) mieliśmy okazję do tego, żeby w gronie samych managerów IT przestudiować temat tego czym jest Scrum, jak wygląda zwinna organizacja, jakie kwestie są niezbędne do tego, żeby naszą firmę uzwinnić. Była to też świetna okazja do tego, żeby rozwiać szereg nieporozumień, jakie narosły wokół zwinności z racji dotychczasowych nieskoordynowanych działań szkoleniowych.

Oprócz tego wiedzieliśmy, że podobnego typu warsztat, ale bardziej dostosowane do potrzeb biznesowych, potrzebujemy dla grona wspólnego z biznesem. Zebraliśmy na nim top managerów po stronie biznesowej, to nie były osoby z Zarządu, ale szczebel niżej lub dwa szczeble niżej pod Zarządem. Kryterium doboru było takie, że szukaliśmy w miarę możliwości menedżerów najbardziej zaangażowanych w realizację projektów, które potem wdrażane są w IT. Struktura banku odbiega od typowej organizacji produktowej i nie ma jednego miejsca, w którym generowane są pomysły na rozwój system, więc wybór był trudny – tutaj bardzo nam pomogła wiedza o organizacji najdłuższych stażem managerów IT. Ja czy szef IT wtedy nie byliśmy jeszcze aż tak bardzo zorientowani, nie byliśmy dostatecznie długo w firmie. Dobraliśmy tą grupę (różne osoby z biznesu i kilku menedżerów z IT), zorganizowaliśmy warsztat ponownie z Tomkiem Włodarkiem. Przy realizacji tego warsztatu pojawiło się trochę kontrowersji i nie ma co kryć, temat mógł wypaść lepiej. Przede wszystkim takie grono managerskie wyższego szczebla biznesowego potrzebowało (w porównaniu do naszych założeń) znacznie więcej dyskusji o konkretnych rozwiązaniach, jakie są zawarte w podejściu zwinnym, a mniej skorzy byli do dyskusji o wartościach, jakie są związane z agilem czy Scrumem. Chcieliśmy przekazać im sporo rzeczy z poziomu wartości, ale zostały one odebrane jako filozofowanie. Dla nich to podejście zwinne wtedy było na tyle nowe, że potrzebowali więcej wyjaśnień, jeśli chodzi o warstwę praktyk. Warsztaty i tak i tak były inspirujące dla wielu, ale pozostał pewien niedosyt. Nie ma tego złego, co by na dobre nie wyszło – przynajmniej ten niedosyt był bazą do tego, żeby realizować kolejne rundy przekazywania wiedzy i z poszczególnymi osobami można było się dodatkowo spotkać, by jakieś brakujące elementy układanki przekazać bezpośrednio. Część z tych osób potem dotarła na szkolenie z podstaw Scruma, co fajnie dopełniło program (najpierw poziom menedżerski, potem szczegóły Scruma wraz z konkretnymi zespołami).

Samo to wydarzenie akurat jest dla mnie przestrogą, że taki szczebel wyższego managementu może potrzebować bardzo dopasowane do siebie szkolenia z agile i przyznam szczerze, że takiego szkolenia jeszcze nie widziałem. Szkolenie z podstaw Scruma lubi skupiać się na szczegółach mechaniki scrumowej, co dla poziomu menedżerskiego nie jest tak istotne. Z drugiej strony szkolenie o wartościach łatwo odebrać właśnie jako filozofowanie, jako coś takiego już odpływającego od pragmatyki biznesowej. Jest na pewno miejsce na rynku na szkolenie ze zwinnej organizacji, ale dokładnie z perspektywy konkretnej praktyki menedżerskiej. Sam chętnie bym takie szkolenie z jednej strony przeżył, a z drugiej strony poprowadził, gdyby tylko była taka okazja. Gdybym na dzisiaj miał złożyć taki program, zawarłbym podstawy manifestu, ale z naciskiem na 12 zasad w praktyce dla managera. Kolejny temat to wsparcie dla zespołu scrumowego, zwłaszcza perspektywa potrzeb Scrum Mastera i takie zrozumienie jego roli, by umieć mu efektywnie pomóc. W takim szkoleniu menedżerskim też miejsce na jakąś cząstkę Managementu 3.0, ale nie przesadzałbym z tym aspektem, bo widzę, że coraz mocniej kojarzy się on z zestawem sztuczek menedżerskich (mapy, boardy, itp.), a nie szerszej koncepcji tego, że zasady zarządzania się zmieniają. Ostatni element, który zawarłbym w takim szkoleniu, a który w Polsce na razie jest mało popularny, to koncepcja Beyond Budgeting, filozofii zarządzania całą organizacją zainicjowaną w świecie finansów i opartą na założeniach bardzo przypominających agile.

Wracając do konkretnej historii mBankowej, warsztat z biznesem, mimo, że było kilka rzeczy, które można było zrobić lepiej, odniósł najważniejszy efekt – celem warsztatów było zbudowanie świadomości, że pewne zmiany w organizacji są potrzebne, że wsparcie biznesowe jest niezbędne i tu akurat bez problemów udało się na koniec warsztatów uzyskać zaangażowanie i deklarację do tego, że pierwsze próby Scrumowe będą wsparte.

Dlaczego Scrum Master nie powinien być pośrednikiem

W czasie ostatniego spotkania na Zwinnej Łodzi, na której prezentowałem swoją opowieść o ścieżce kariery agilowej, dostałem bardzo dobre pytanie: „a tak w zasadzie, to co jest złego w tym, że Scrum Master bywa pośrednikiem między firmą a zespołem” . Chodziło o mój przykład życia, gdy odradzam z własnego doświadczenia by SM brał na siebie odpowiedzialność za na przykład raportowanie statusu projektu, koordynowanie prac pomiędzy zespołami czy przynoszenie do zespołu jakichś nowych wytycznych z organizacji i wdrażanie ich.

Pytanie jest o tyle dobre, że sięgało do istoty problemu, obaj z pytającym zgodziliśmy się, że samo stwierdzenie „Scrum Guide tak każe” nie jest dla nas wystarczające.

W temacie przychodzą mi do głowy trzy kwestie merytoryczne:

  1. Usuwanie pośredników – usuwanie głuchego telefonu którego istnienie jest często nieświadome, a każde kolejny szczebel przekazywania informacji bezwiednie zmienia niuanse komunikatu. Stąd SM powinien dążyć do tego, żeby różnego rodzaju komunikaty do i z zespołu przechodziło bezpośrednio między nadawcą a odbiorcą. Chcesz się dowiedzieć jaki jest status prac – przyjdź na review. Albo zajrzyj w backlog poprzednich sprintów. Chcesz żeby zespół coś dla Ciebie zrobił – przyjdź do nas na planning, pozwól się zaprosić na retro.
  2. Budowanie odpowiedzialności w zespole – taka inspiracja „Scrum Mastery” żeby być SMem, który rozwija cały zespół w odpowiedzialności za całość produktu, nawet jeśli oznacza to „kłopotanie” zespołu rzeczami innymi niż development. Moim zdaniem ślepą uliczką jest odciążanie zespołu od tych innych rzeczy (raporty, komunikacja, itd.) – w długim okresie czasu takie rzeczy należy optymalizować (nie powiem usuwać, bo to może być zbytnie uproszczenie), w krótkim nie chować, nie plastrować.
  3. Nie branie na siebie nie swojej odpowiedzialności – SM (zwłaszcza z korzeniami menedżerskimi albo PMowymi) może mieć ochotę wykazać się w zespole i przejąć tematy koordynacyjne. Niektóre z nich bardziej pasują do zestawu odpowiedzialności Product Ownera (praca z interesariuszami, odpowiedzialność za decyzje w produkcie), inne powinny być w całym zespole (dbałość o jakość, znalezienie sposobu na współpracę pomiędzy zespołami). SM zabierający na siebie te odpowiedzialności, zwłaszcza robiąc to niejawnie, osłabia role innych członków zespołu, jednocześnie zaburzając czystość swojej odpowiedzialności w Scrumie. To zaburzenie czystości swojej roli może być szczególnie spotęgowane, jeśli otoczenie zespołu (management, inne zespoły) zacznie traktować Scrum Mastera jako przedstawiciela zespołu w różnych sprawach, które do niego nie należą i wzmacniać nieoptymalny układ. W skrajnym przypadku prowadzić to może do zupełnie złego wykształcenia roli i odpowiedzialności Scrum Mastera w firmie.

I jak o tym piszę, to ostatnia refleksja – każdy z tych punktów jest nadal równie prawdziwy a może jeszcze prawdziwszy dla roli Agile Coacha…

Mów do mnie jak do labradora

Wczoraj miałem ciekawą rozmowę na temat szykującego się wydarzenia związanego z AgileHR. I o samym wydarzeniu już nic więcej nie powiem 🙂

W rozmowie uczestniczyła pewna mądra osoba, która przepięknie rozprawiła się z rozbudowanymi planami na wydarzenie, w ramach których organizator chciał uczestników zapoznać z koncepcjami złożoności, adaptujących się organizacji itd. Poradziła, aby skupić się na prostych sprawach, bardzo podstawowych, żebyśmy przypomnieli sobie czego potrzebowaliśmy, gdy byliśmy na początku swojej drogi agilowej (ja 8 lat temu potrzebowałem wiedzieć jak zrobić dobrze te storypointy…).

Złożyło mi się to z przeżyciem z warsztatów z agile dla HR które organizowałem w mBanku. Miałem (wraz z zespołem) podobny pomysł – koniecznie muszę przekazać Cynefin, on tak ładnie rozwiązuje wszystkie problemy tego, jak należy postępować. Uczestnicy(-czki) warsztatu wolały porozmawiać o tym, co konkretnie trzeba robić żeby być agile, jak to w praktyce wpływa na osoby, zespoły i całą firmę. Bez tych wszystkich skomplikowanych wymyślnych pojęć, teorii, nazwisk, cytatów.

W ostatnim tygodniu miałem też świetną interakcję z przedstawicielami zespołu, który właśnie puka do drzwi wyższych stanów zaawansowania swojej współpracy i rozmowa szła gładko, metafory, rady i pytania miękko siadały aż do momentu, gdy użyłem pojęcia „Scrum Studio” i uzyskałem komentarz „Wy coache zawsze macie swoje nazwy na różne rzeczy”.

Cały czas się uczę. I jeśli gdzieś jest jeden z moich obszarów do rozwoju, to właśnie w tym – mimo całej tej wiedzy o Cynefinie, zaawansowanych agile’ach, Nexusach, Flowach, Kanbanach – jak to zrobić, by dotrzeć do odbiorcy na jego poziomie, nie odstraszyć go trudnymi pojęciami. Jak dobrać prostą metaforę, jak ubrać jakieś zaawansowane koncepcje w proste ćwiczenie. Jak zachować cierpliwość do tego, że na pewne sprawy jest jeszcze za wcześnie na tym etapie rozwoju na którym jest mój rozmówca.

PS. Tytuł wpisu wzięty z polskiego tłumaczenia pewnej kwestii z filmu „Chciwość”. Czyli po angielsku „Margin Call”, gdzie w oryginale mowa o golden retrieverze 😉

Jak robię warsztat z podstaw Scruma

W ramach pracy nad kompetencjami mBanku przygotowałem autorski program szkolenia z podstaw Scruma i w ramach tego artykułu chcę się podzielić filozofią, jaka mi przyświecała przy jego tworzeniu. Gdy niedawno przygotowywaliśmy się razem do współprowadzenia “Podstaw Scruma” jedna ze Scrum Masterek zadała mi pytanie: “na podstawie czego ten program powstał”. Dla mnie to pytanie dotyka dość ważnej kwestii, czyli tego jaka jest konstrukcja szkieletu warsztatu, a może z jakiego innego szkolenia to szkolenie jest kopią ;).

Program jakiego używam w mBanku jest mocno autorski w tym sensie, że założyłem zasadę pustej kartki, więc to nie są slajdy przetłumaczone, skopiowane, przeniesione, czy nawet inspirowane przez jakieś konkretne szkolenie. A byłem na wielu, na samych szkoleniach z podstaw Scruma byłem na szkoleniu Certified Scrum Master w 2009 roku u Angeli Druckman, pół roku później u Dana Rawsthorne’a. W 2011 roku w czasie transformacji zwinnej w Allegro wziąłem udział w Professional Scrum Product Owner u Tomka Włodarka, a w kolejnym roku uczestniczyłem w szkoleniu Professional Scrum Foundations Tomka jako pomocnik w moderowaniu ćwiczeń i gość, który mógł z boku trochę pokomentować, gdy pojawiały się jakieś pytania o transformację Allegro. Scrumowo najmocniejszym przeżyciem było szkolenie Certified Scrum Master u Jeffa Sutherlanda, który sam Jeff nazywał raczej zaawansowanym Scrumem, niż podstawami Scruma. Nie wymieniam tego, żeby się chwalić, ale żeby pokazać, że szkoleń o Scrumie widziałem parę jako uczestnik i każde dało mi okazję z jednej strony zobaczyć warsztat trenerski, a z drugiej każde kolejne było okazją do przemyślenia, odświeżenia, wypolerowania sobie wiedzy o Scrumie jako takim.

Ale moje szkolenie nie jest kopią, ani jakimś miksem żadnego z tych kursów. Filozofia tego warsztatu wraca do pewnego krótkiego szkolenia w Allegro, gdzie zaeksperymentowałem z koncepcją opowiedzenia Scruma przez pryzmat problemów, jakie Scrum rozwiązuje – w metodzie zaszyte są pewne praktyki, które rozwiązują typowe problemy podejścia tradycyjnego. Na warsztacie miałem nietypowy zespół, który chciał się dowiedzieć czym jest Scrum i zamiast im tłumaczyć jak zwykle, zacząłem od wypytania z jakimi problemami stykają się przy realizacji projektów. Tak się jakoś dziwnie samo złożyło, że wszystkie problemy przez nich wymienione stały się szkieletem zdefiniowania Scruma. Dosłownie to się działo na whiteboardzie, na którym dopisywałem kolejne elementy frameworka jako odpowiedź na ich problemy z codziennego życia projektowego. Oni wymieniali m.in. problemy komunikacyjne, problemy z priorytetami, problemy ze sformułowaniem wymagań, a ja im pokazałem po kolei Product Backlog i Przyrost, Planowanie Sprintu, a z drugiej strony ewentualne odkrycie na Review, że się nie dogadaliśmy itd. No i koncepcja bardzo zażarła, w tym sensie, że zarówno ja jak i uczestnicy byliśmy zadowoleni z jasnego wytłumaczenia i łatwości z jaką przebiegł ten warsztat.

Gdy dołączyłem do mBanku postanowiłem zaeksperymentować z tą formułą jako kompletnym sposobem na szkielet warsztatu. Całkowicie zrezygnowałem z podejścia “klasycznego”, że tak to nazwę Scrum “po kolei”: zacznijmy od ról, no to role: pierwsza, druga, trzecia rola; no to teraz zdarzenia: pierwsze, drugie, trzecie, czwarte zdarzenie; no to teraz artefakty: pierwszy, drugi, trzeci artefakt; teraz jakiś temat zaawansowany, dyplom, ankieta, koniec! W takim podejściu moim zdaniem strasznie ciężko jest zdefiniować poszczególne elementy Scruma bez definiowania “nieznane przez nieznane”. Scrum Master to jest ten, kto pracuje z Product Ownerem, a kto to jest Product Owner? Coś, co ja zastosowałem, to takie rozsupłanie Scruma nie rola po roli, zdarzenie po zdarzeniu, tylko problem po problemie, jaki mamy w projektach. Stąd zaczynam od sformułowania tematów zarządzania produktem, potem wprowadzam temat pracy zespołowej, potem jest temat ciągłego usprawniania, potem jest temat realizacji projektów no i na końcu jest miejsce na tematy zaawansowane np. skalowanie, ale to już często bardzo wynika z konkretnej potrzeby szkolonego zespołu.

Szkoleń po dołączeniu do mBanku robiłem bardzo dużo, pewnie doliczył bym się kilkudziesięciu szkoleń poprowadzonych, co pozwoliło w krótkim czasie pokombinować z różnymi ćwiczeniami, z różnymi formułami instrukcji i dopracowywać slajdy, zwrócić uwagę na rozłożenie akcentów, rozłożenie kolejności przekazywanej wiedzy. Pozwoliło to też reagować na to co wyglądało, że zostało przekazane niejasno albo pojawiało się w feedbackach jako słabszy fragment. Najmocniejszym feedbackiem było zjawisko zbierania swoich własnych owoców poszkoleniowych. Gdy najpierw szkoliłem, a potem osobiście coachowałem (po prostu byłem jedynym coachem w całej organizacji), bardzo łatwo mogłem dostrzec to, jak niedoskonałości moich pierwszych szkoleń później było widać w zespole. Na przykład temat retrospektywy, żeby ukonkretnić opowieść. Dla mnie samego retrospektywa była dosyć oczywista, stąd jak przyszedł czas na ten temat na szkoleniu, no to w zasadzie w skrócie opowiedziałem, że trzeba to robić i dzięki temu się ciągle usprawniamy. Porównywalnie o wiele więcej czasu i uwagi skupiałem na tematy backlogów, Ownera, roli Scrum Mastera, prognozowanie realizacji projektu. Potem docieram do pierwszego zespołu, który przeszkoliłem, który dzięki mojemu szkoleniu spróbował wykorzystać Scruma i spotykam ścianę. Nie wiedzą jak zrobić retrospektywę, więc najprostsza reakcja, jak nie wiemy, jak coś zrobić to tego nie robimy. Gdy szkoliłem kolejny zespół, już wzmocniłem w swoim programie temat propozycji konkretnych technik retrospektyw, podpowiedź starfish diagram i timeline, tak żeby umieli zastosować to na początku swojej pracy, na początku swojej drogi ze Scrumem. Kolejna kwestia, która najwyraźniej nie wybrzmiewała na moich szkoleniach to retrospektywa jako element obowiązkowy w każdym sprincie. Pierwsze zespoły miały ochotę robić retrospektywę wtedy gdy trzeba, a nie co sprint. Zwłaszcza startującemu zespołowi naprawdę nie uwierzę, że nie potrzebuje robić retrospektywy co sprint, ale w kolejnych warsztatach zwracałem uwagę na jakieś wzmocnienie tematu jak bardzo retrospektywa jest potrzebna co sprint.

Oczywiście nadużyciem byłoby stwierdzenie, że dzięki wypolerowanym warsztatom ludzie przeze mnie przeszkoleni idealnie od pierwszego sprintu będą realizować Scruma, ale wiem, że warsztat ma dobry szkielet, który uzupełniam ciągłymi usprawnieniami, dzięki temu, że mogę też zbierać feedback z prawdziwego zastosowania w praktyce tego, co uczę.

 

Garść przeżyć z konferencji Zarządzanie Zespołami IT

W poniedziałek wystąpiłem na konferencji Zarządzanie Zespołami IT z tematem „Zwinne środowisko pracy przy wsparciu menedżerów” i podzielę się w miarę na gorąco garścią przeżyć, kompletnie różnorodnych i specjalnie nieuporządkowanych:

  • Na konferencji o zarządzaniu zespołami IT było więcej agile niż na niejednej konferencji agilowej (na których często sporo historii o ludzkim mózgu, sztuce rysowania kresek mazakiem i pseudocoachingu). Ręce składały się do oklasków gdy się słuchało Country Managera Motoroli mówiącego o tym, że agile to lata pracy, zmiana całej firmy, gigantyczna inwestycja itd.
  • Agile w Polsce przeżywa boom. Przynajmniej według szybkiej ankiety zrobionej w trakcie jednego z wystąpień, gdzie mało kto na sali nie podniósł ręki na pytanie o to, czy wdrażają albo wdrożyli agile do swojej pracy. Co o tym boomie sądzę, powiedziałem już na ABE16 w czasie lightning talka, więc tu się nie będę powtarzał, trzymam kciuki za kompetencje osób, które pomagają tym wszystkim firmom w wykorzystaniu agile.
  • Turkusowe organizacje i holokracja aspirują do bycia „the new black”. Ktoś coś tam czytał, mało kto widział, ale mówią wszyscy.
  • Pewnie nie będę w tym obiektywny (no trudno), ale niezły mix występujących. Allegro, GSK, panel z reprezentacją Krakowa (Moto, kontakt.io), wsparte Panem Sedlakiem z toną statystyk nt. rynku, zgrabnymi prezentacjami w tracku HR.
  • A propos raportu Sedlak&Sedlak – zarobki Scrum Masterów wg badania za poprzedni rok plasują się typowo w przedziale 7/8?-13k zł. Na tle innych zawodów w IT szczególnie duża dystrybucja i dość wysokie umiejscowienie w rankingu zarobków
  • Fajnie, że zrobiono ze mną wywiad po wystąpieniu, jak będzie dostępny to wyszeruję. I zupełnie bez sensu że się zgodziłem tak od razu, ludzie chcieli pogadać, zadać pytania na świeżo, a ja właśnie zaglądałem w oko kamery przez ponad pół przerwy 🙁 Między innymi straciłem okazję na świetną rozmowę o spłaszczaniu struktury
  • Bardzo miłe uczucie, gdy występuje się dość wcześnie na konferencji, a potem w kolejnych wystąpieniach kolejni prelegenci się do Ciebie odwołują (m.in. przywołując najważniejsze punkty, które chciałem przekazać)
  • Last but not least: nie denerwowałem się przed wystąpieniem, serio. Czyli jest progress nawet w porównaniu do LT na ABE, bo tam byłem jak galareta… Ala (i Ola, organizatorka) mi świadkiem, że slajdy miałem na ostatnią chwilę, dużo w prezentacji było „na żywiole”. Przy czym nie mogę powiedzieć, że nie było przygotowania, bo poszedł pełen pakiet – persony, warstwa treści, warstwa metafor, konstrukcja historii, gwoździe, strona wizualna dopieszczona – jeszcze opowiem jak się przygotowuję. Pewnie jak zwykle mogło być jeszcze lepiej, dzięki za dotychczasowy feedback. Do samego siebie mam największy żal, że zepsułem aluzję o „agile w korporacji jako lipstick on a pig”, pomieszało mi się i wyszło jakieś dziwactwo. Oddzielna sprawa jak to wyszło na nagraniu, na który się udało namówić organizatorów, pewnie znowu będę się bał obejrzeć samego siebie przez kilka tygodni (dużo łazikowałem po scenie, pewnie wyłapię u samego siebie każdą zawiechę wypowiedzi i jakieś skróty mogące wywołać niezrozumienie).

Kolejny exp wystąpieniowy na koncie, kolejnych kilka obiecujących kontaktów, on to the next one.