Czego uczę się od purpurowych pasów w brazylijskim jiu-jitsu?

Biały i niebieski pas w BJJ

Biały i niebieski pas w BJJ

Kilka lat temu trafiłem na Facebooku na post znajomego, który pochwalił się, że właśnie stał się posiadaczem purpurowego pasa w brazylijskim jiu-jitsu.

Zaciekawiło mnie to na tyle, że poszukałem w internecie informacji o progresji pasów w BJJ i natrafiłem na ciekawy fragment [1], który mocno zadziałał na moją wyobraźnie:

„Mentalność purpurowego pasa jest bardzo różna od mentalności prezentowanej przez białe i niebieskie. Pasy białe i niebieskie myślą, że rozwiązaniem ich problemów jest poznanie większej ilości technik. Purpurowy pas widzi natomiast problem tak: „Muszę ulepszyć poznane techniki, a następnie nauczyć się odruchowo składać je w odpowiednie, płynne kombinacje.”

Minęło kilka lat #prokrastynacja i to jest dobry moment, aby podzielić się kilkoma przemyśleniami. Czytaj dalej

Wywiad na temat budowania zwinnej kultury organizacyjnej

Wywiad: Jacek Wieczorek o zwinnej kulturze organizacyjnej.

Wywiad: Jacek Wieczorek o zwinnej kulturze organizacyjnej.

Kilka tygodni temu byłem gościem podcastu Mariusza Chrapko o nazwie Menedżer Plus. Rozmawialiśmy o praktycznych aspektach pracy z kulturą organizacyjną.

Jako, że usłyszałem dużo dobrych słów na temat tego wywiadu od różnych osób, postanowiłem podzielić się tym wywiadem również na blogu.

Dużo się mówi i pisze na codzień o zwinności oraz Scrumie, natomiast mniej uwagi jest poświęcane takim zagadnieniom jak kultura czy wartości. Tym bardziej się cieszę, że nagraliśmy konkretną i ciekawą rozmowę, podczas której podzieliłem się swoimi doświadczeniami oraz przemyśleniami z ostatnich kilku lat pracy w mniej lub bardziej zwinnych środowiskach. Czytaj dalej

Kilka słów o przyszłości

Dzisiaj nieco bardziej osobiście.

Spotykam osoby, które myślą, że nadal pracuję w Grupie Allegro. Są też takie, które identyfikują mnie z STX Next. Inna grupa kojarzy mnie z marką agile247.pl. Mało kto natomiast z 202 Procent (co mnie zupełnie nie dziwi) i właśnie o tym będzie dzisiejszy wpis.

202 procent to zespół doświadczonych praktyków agile’a. Kiedy ponad dwa lata temu brałem udział w tworzeniu tej inicjatywy, wiedziałem, że początkowo będzie to praca po godzinach, w ramach urlopu oraz w weekendy. Wiedziałem też, że nadejdzie dzień na podjęcie decyzji: albo zatrudniam się jako pracownik w kolejnej firmie, albo decyduję się rozwijać własną spółkę. Czytaj dalej

Nie tylko technologia, czyli przemyślenia po Poznań Startup Hackathon 2014

Logo Startup POZnan*

Logo Startup POZnan*

Parę dni temu miałem okazję uczestniczyć jako mentor w poznańskim hackathonie. Zadaniem uczestników imprezy było stworzenie w 24h aplikacji, która korzystając z kilku dostępnych API (m.in. Miasto Poznań, Allegro, Wykop), ma rozwiązać dowolny problem, z którym borykają się mieszkańcy Poznania. Uczestniczyło w nim kilka zespołów, którym pomagali mentorzy, z jednej strony zadając trudne pytania, z drugiej dzieląc się swoją wiedzą i doświadczeniem.

Poniżej kilka moich przemyśleń i obserwacji, patrząc typowo z perspektywy szybkiego dostarczania wartości dla użytkownika:

  • pomimo sali wypełnionej ciekawymi ludźmi, zespoły nie decydowały się na zbieranie bieżącego feedbacku na temat swoich pomysłów. Pytanie “Ilu osobom pokazaliście dotychczas swój produkt?”, zazwyczaj kończyło się dłuższą ciszą. Wprawdzie mentorzy sami podchodzili do teamów i prosili o ogólne przedstawienie idei, to chodzi mi raczej o proaktywną postawę na zasadzie: “szybko poddajmy ocenie nasz pomysł”. Jest różnica pomiędzy zabieganiem o feedback, a otrzymaniem go przypadkowo.
  • idąc dalej, kolejne funkcje dodawane do aplikacji nie wynikały z rozmów z użytkownikami, a raczej z własnego przeczucia, co mogło by fajnie zadziałać. Podejrzewam, że fajnie przez chwilę poczuć się jak Steve Jobs i wymyślać funkcje aplikacji pod siebie, to jednak póki nie mamy doświadczenia jak szef Apple, warto zapytać użytkowników, jakich funkcji tak naprawdę potrzebują.
  • byłem świadkiem sytuacji, w której jeden z uczestników płynnie opowiadał i pokazywał, jak działa ich aplikacja; kiedy jeden z mentorów zaproponował, że może sam spróbuje skorzystać z aplikacji, płynność działania aplikacji spadła niemal do zera; próba użycia aplikacji generowała kolejne pytania: “gdzie mam kliknąć?”, “nie wiem co mam teraz zrobić”, “te filtry działają zupełnie odwrotnie niż myślałem”, “spodziewałem się czegoś innego po kliknięciu w ten przycisk” itd. Zderzenie z rzeczywistością potrafi być całkiem inspirujące.

Reasumując, kibicuję takim imprezom jak hackaton, gdzie wszyscy obecni mogą się nauczyć czegoś nowego i w krótkim czasie stworzyć działającą i użyteczną aplikację. Zebrane osoby nie miały problemów z użyciem świeżej technologi, nieco gorzej jednak wypadły w takich obszarach jak zarządzanie produktem, zarządzanie procesem czy umiejętności prezentacji (sprzedania) pomysłu. Wiedza we wspomnianych obszarach jest moim zdaniem równie kluczowa, co umiejętność napisania działającego kodu.

Nie zmienia to jednak faktu, że podobne wydarzenia umacniają mnie w przekonaniu o sensowności inicjatyw takich jak barcampy, hackatony czy skupionych wokół konkretnego tematu spotkania loklanych społeczności (np. PAUG). Tego typu spotkania są potrzebne, aby wiedza zebrana w głowach pojedynczych osob mogła swobodnie przepływać pomiędzy wszystkimi uczestnikami tego typu eventów.

Zdjęcie pochodzi z profilu City of Poznań na facebook.com

Jednodniowe Sprinty w Scrumie

1-dniowe sprinty w Scrumie

1-dniowe sprinty w Scrumie

Od zawsze byłem fanem krótkich sprintów. Dostrzegam dużą wartość w skracaniu pętli feedbacku przy jednoczesnym minimalizowaniu niepewności związanej z wytwarzaniem oprogramowania.

Myślałem ostatnio o prostym eksperymencie – przez tydzień lub dwa chciałbym pracować z zespołem używając 1-dniowych sprintów.

Zakładając 8h dzień pracy, na właściwą pracę – po odjęciu czasu potrzebnego na zdarzenia scrumowe – pozostaje 378 minut, tj. 6h 18 minut.

Oto jak wyglądał by szkielet zdarzeń scrumowych:

  • Planning – 24 minuty
  • Refinement – 42 minuty
  • Review – 12 minut
  • Retrospektywa – 9 minut
  • Daily – 15 min

Patrząc na powyższe liczby, pierwsze co przyszło mi do głowy, to stwierdzenie „wymagające te timeboxy”. Po dłuższym zastanowieniu jednak, kiedy ponownie uzmysłowiłem sobie, że mówimy po prostu o organizacji jednego dnia pracy, wartości te przestały mnie zadziwiać.

Zakładam, że pewne założenia muszą zostać spełnione, aby takie podejście miało szansę powodzenia, do głowy przychodzą mi następujące punkty:

  • zespół realizuje w sprincie 1-2 naprawdę małe funkcjonalności
  • członkowie zespołu bardzo dobrze potrafią ze sobą współpracować i dzielić się pracą (wykorzystują np. swarming)
  • elementy Product Backlogu są bardzo małe, nie zależą od siebie, a jednocześnie przynoszą wartość
  • wykorzystywane jest podejście walking skeleton, tak aby na koniec sprintu pokazać coś potencjalnie zbywalnego, operując mocno głębią odwzorowania szczegółów
  • brak znaczących zależności zewnętrznych (np. oczekiwanie kilka godzin na jakiekolwiek zasoby odpada)
  • sprawny Scrum Master potrafiący moderować tak ekstremalne podejście do dewelopmentu

Co sądzicie? A może ktoś z Was pracował już z 1-dniowymi sprintami?

Fotografia użyta na licencji Creative Commons od użytkownika andrechinn.