O Jacek Wieczorek

Jestem Agile Coachem i praktykiem podejścia agile. Kończę pisać książkę "Labirynty Scruma" o sprawdzonych sposobach na najczęstsze pułapki w Scrumie. Przekształcam organizacje w miejsca, w których efektywnie tworzone są wartościowe produkty. Prowadzę bloga agilecoaching.pl oraz współtworzę portal agile247.pl. Na co dzień pomagam klientom działając jako konsultant w firmie 202 Procent.

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

„No Estimates” – Vasco Duarte

Okładka książki "No Estimates" - Vasco Duarte

Okładka książki „No Estimates” – Vasco Duarte

Do przeczytania książki „No Estimates” dojrzewałem od dłuższego czasu. Złożyło się na to kilka okoliczności:

1. Prowokacyjny hashtag #noestimates, przez wiele osób traktowany zbyt dosłownie, wyświetlał się na moim twitterze od dłuższego czasu i rozbudzał moją ciekawość tematu.

2. Słucham od czasu do czasu podcast Scrum Master Toolbox Podcast, którego jednym z autorów jest Vasco Duarte, więc miałem okazję zapoznać się z jego poglądami przy okazji rozmów z gośćmi, których zapraszał do audycji (nie tylko zadaje pytania, ale potrafi celne podsumować wypowiedź lub dodać coś od siebie). Czytaj dalej

„Scrum Shortcuts without Cutting Corners” – Ilan Goldstein

Okładka książki "Scrum Shortcuts without Cutting Corners" – Ilan Goldstein

Okładka książki „Scrum Shortcuts without Cutting Corners” – Ilan Goldstein

Dosyć długo nie czytałem żadnej książki o Scrumie. Ostatnie pozycje, które przeczytałem lub odsłuchałem od wakacji dotyczyły m.in przywództwa („Turn the Ship Around!”), zarządzania („Jednominutowy menedżer i przywództwo”), motywacji („Drive”) czy zarządzania samym sobą („Jesteś start-upem”, „7 nawyków skutecznego działania”). Po przeczytaniu powyższych pozycji stwierdziłem, że tym razem czas sprawdzić jedną z wielu ostatnio napisanych książek o Scrumie.

Po przeglądnięciu kilku pozycji na Amazonie wybrałem „Scrum Shortcuts without Cutting Corners”, a  zadecydowały o tym dwa fakty – to pierwsze: książka została bardzo wysoko oceniona przez czytelników (średnia 4.9 na podstawie 57 ocen), po drugie: napisał ją człowiek, który zanim stał się trenerem scruma i autorem wspomnianej książki, dobre kilka lat pracował na różnych stanowiskach w IT, więc założyłem, że wie, o czym mówi – w przeciwieństwie do trenerów, którzy po prostu nauczyli się zasad frameworka na potrzeby prowadzenia szkoleń.

Wstęp do książki napisał Mike Cohn (który jak okazuje się na kolejnych stronach książki, jest mistrzem w wyciskaniu sztangi na ławce poziomej z rekordem 254 kg) i chyba nie jest to przypadkowe, ponieważ odniesienia do książek Mike’a pojawiają się podczas lektury wielokrotnie. Reasumując – czuć jego szkołę.

Autor – Ilan Goldstein – podzielił książkę na 10 rozdziałów, z czego każdy opisuje po trzy „skróty” (ang. shortcut), czyli w miarę gotowe rozwiązania, opisujące wybrane zagadnienia scrumowe. Podczas czytania kolejnych rozdziałów dostrzegłem analogię do książki Henrika Kniberga „Scrum & XP from the Trenches” – Ilan, podobnie jak Kniberg opisuje „Scruma w praktyce” – czyli to, co zadziałało w jego zespołach oraz organizacjach w których pracował.

Warto jednak pamiętać, że nie każda technika czy podejście, które zadziałało autorowi książki, zadziała w naszym zespole czy organizacji. Jak powiedział mi kiedyś Alistair Cockburn – „every technique is working and is not working at the same time„.

Przykładowo: autor proponuje, aby za spóźnienia na Daily Scrum pobierać od spóźnialskich opłatę do słoika na cele charytatywne. W czasie, kiedy pracowałem w Allegro, w jednym zespołów w których byłem Scrum Masterem, zdecydowaliśmy na taki krok, aby „zmotywować” osoby spóźniające się do bycia na czas. Rozwiązanie to nie przyniosło spodziewanych rezultatów – osoby, które spóźniały się, robiły to nadal (ciekawostka: gdybym wcześniej przeczytałbym „Drive” Dana Pinka, wiedziałbym, że taki sposób motywacji z reguły nie działa – niektórzy ludzie po prostu „wykupują sobie” możliwość spóźnienia się)

Najciekawsze z mojej pespektywy rozdziały dotyczyły wymagań („Requirement Refinement”), jakości („Questioning Quality”) oraz metryk („Monitoring and Metrics”). Pełne konkretów, trafnych analogii oraz praktycznych wskazówek powodowały podczas czytania chwile zadumy, co uważam za wartościowy i pożądany efekt w trakcie czytania książek.

Jest to książka, którą gdybym mógł cofnąć czas, przeczytałbym zaraz po pierwszej lekturze Scrum Guide – oczywiście nie była wtedy jeszcze dostępna (została wydana w 2013), ale to właśnie ten typ książki. Poleciłbym ją Scrum Masterom zaczynającym przygodę ze Scrumem jako swego rodzaju przewodnik, natomiast osobom z dłużym stażem jako cenne źródło referencji oraz inspiracji.

Plusy:

+ dużo praktycznych wskazówek, pomysłów oraz rozwiązań dotyczących codziennej pracy w Scrumie

+ można z niej  korzystać jak z książki kucharskiej, poszukując odpowiedniego „przepisu”

Minusy:

– odniosłem wrażanie, że książka pisana jest z perspektywy dużej organizacji, rozwijającej wewnętrznie swoje produkty, zabrakło mi perspektywy pracy z klientem zewnętrznym

Moja ocena: 4,5/5

Scrum & agile: zestaw startowy dla początkujących

Agile & scrum: jak zacząć?

Wielokrotnie spotkałem się z pytaniem Scrum Masterów lub Product Ownerów – którzy dopiero rozpoczynają swoją przygodę z agile oraz Scrumem – co robić, aby rozbudować swoją wiedzę. Kiedy kilka dni temu, po przeprowadzeniu rozmowy rekrutacyjnej w poszukiwaniu doświadczonego Scrum Mastera, osoba biorąca w niej udział poprosiła mnie o feedback i sugestie co do dalszego rozwoju, stwierdziłem, że czas na napisanie poniższego wpisu.

Obszary, którymi warto się zainteresować, można podzielić na kilka grup:

1. Lokalne społeczności agile – w kilku dużych miastach w Polsce funkcjonują inicjatywy, które skupiają entuzjastów agile, chętnych do dzielenia się wiedzą oraz doświadczeniami. Najczęściej formuła takich spotkań to prezentacja prelegenta (zazwyczaj ok. 1h), która przeobraża się następnie w dyskusję w mniejszych grupach. Jeżeli szukasz inspirujących dyskusji, zdecydowanie zainteresuj się, czy w pobliżu Ciebie funkcjonuje już taka grupa. Jeśli nie, to może warto założyć takową?

2. Książki

3. Publikacje

  • Scrum Guide – kilkanaście stron o tym, czym jest Scrum, napisane przez Jeffa Sutherlanda oraz Kena Schwabera – twórców Scruma. Warto czytać ten dokument co jakiś czas, bo wraz z upływającym czasem (oraz zdobytym doświadczeniem) zaczyna się coraz więcej z niego wyciągać. Do dzisiaj potrafi mnie coś zaskoczyć czy zainspirować.
  • Product Owners Manual – krótka, lecz treściwa pozycja, zawierająca zbiór podstawowych informacji związanych z rolą Product Ownera

4. Materiały video

Powyższe materiały to tylko przykład punktu, z którego można wystartować. Dalszy rozwój to połączenie własnych doświadczeń, dyskusji z praktykami agile oraz kolejnych lektur – dobieranych według własnego uznania. Powodzenia!

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

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