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

Agile na co dzień i po polsku, czyli agile247.pl

Agile247.pl - agile na co dzień

Logo agile247.pl

Dzisiaj będzie krótko, bardziej informacyjnie.

Ostatnio nieco mniej uwagi skupiałem na blogu agilecoaching.pl i chyba czas, aby wytłumaczyć, co było tego powodem. Na początku roku, wraz z kilkoma osobami stworzyliśmy agile247.plstronę o szeroko rozumianym agile’u, przygotowywaną całkowicie po polsku.

Brak wyraźnego miejsca w polskiej sieci, które byłoby źródłem informacji, technik, relacji z konferencji, a czasem po prostu dawki humoru branżowego, skłonił nas do zrobienia kroku w tym kierunku.

Więcej informacji o wizji oraz koncepcji możecie przeczytać w powitalnym artykule.

Co ważne, nadal będę prowadził agilecoaching.pl – będzie to miejsce, w którym konsekwentnie będę dzielił się swoimi przemyśleniami. Nieco inną treść będę przygotowywał na agile247.pl (m.in. newsy, wywiady, relacje z eventów), nieco inną będę publikował tutaj (przemyślenia związane z pracą w agile’owym środowisku).

Udział w tworzeniu agile247.pl jest dla mnie okazją do kontynuacji misji, która przyświecała mi, kiedy ponad 3 lata temu napisałem pierwszy artykuł na agilecoaching.pl – chęć podzielenia się swoim doświadczeniem oraz dostarczenia wiedzy dotyczącej agile osobom, które takowej poszukują. Cieszę się, że będzie tego jeszcze więcej.

Stay tuned!

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.

Nie mów JAK robić, powiedz CO chcesz i DLACZEGO to jest ważne

Product Owner z wizją

Product Owner z wizją

Klocki Lego świetnie nadają się do symulowania pracy zespołów scrumowych. Gdy korzystam z nich podczas szkoleń oraz warsztatów, zapraszam uczestników do zbudowania miasta. Zazwyczaj jestem hostem tego ćwiczenia, a osoba współprowadząca przyjmuje rolę Product Ownera.

Na początku sprzedaje ona uczestnikom wizję. Opowiada, dlaczego chciałaby wybudować miasto, jak je sobie wyobraża oraz podaje kilka wstępnych ograniczeń, np. „przez środek miasta przepływa rzeka„. Następnie przedstawia zarys Product Backlogu, który składa się m.in. z domów, biurowców czy obiektów użyteczności publicznej. Uczestnicy w kilku sprintach budują miasto, samodzielnie decydując, jak zrealizować za pomocą LEGO wizję Product Ownera.

Czasem zdarza się, że uda się im zbudować wszystko, co zaplanował Product Owner w swoim Product Backlogu. W takiej sytuacji mówi im: „OK, wszystko co miałem w planach już wykonaliście, ale mam budżet na dalszą pracę – budujcie więc to, co uważacie za słuszne„. W tym momencie dzieje się ciekawa rzecz – w bardzo krótkim czasie powstają najciekawsze, najbardziej innowacyjne oraz imponujące budowle, które świetnie wpisują się w pierwotną wizję miasta.

Ci sami ludzie, ten sam produkt. Zupełnie nowa jakość, zupełnie inna energia w zespole.

Jest to dla mnie jeden z dowodów na to, że najlepsze produkty powstają w środowisku, w którym zespół:

  • zna wizję produktu, rozumie po co i dla kogo tworzony jest produkt,
  • wie co ma zrobić i samodzielnie podejmuje decyzję jak to wykonać,
  • otrzymuje przestrzeń do samoorozwoju oraz doskonalenia się.

Co istotne, podejście polegające na mówieniu „co” zamiast „jak”, można stosować na różnych poziomach. 

Product Owner nie mówi zespołowi jak coś ma działać. Mówi, co chciałby uzyskać i dlaczego ma to dla niego znaczenie. Operuje na poziomie efektów, które chciałby osiągnąć (np. „zwiększenie konwersji z kont testowych do kont płatnych”), a nie na konkretnych rozwiązaniach (np. „wysyłajmy dodatkowy e-mail zachęcający do zakupu naszego produktu”).

Gdy skalujemy produkt na kilka zespołów, Chief Product Owner nie mówi Product Ownerom jak ma coś działać. Nie mówi też, w jaki sposób mają podzielić się pracą (np. „Janek zrób wyszukiwarkę, a Ty Krzysiek zrób listę przedmiotów”). Mówi, co chciałby uzyskać („użytkownicy mają mieć możliwość szybkiego dotarcia do naszych produktów”) i dlaczego to dla niego ważne.

CEO/zarząd/boss nie mówi, jakie konkretnie funkcjonalności ma dostarczyć dla niego Chief Product Owner wraz z zespołem Product Ownerów (np. „przygotuj możliwość integracji z Facebookiem„). Nie mówi też, jak mają się zoorganizować (np. „Jeden zespół integruje się z Facebookiem, a pozostałe modyfikują naszą aplikację„). Mówi jaki cel chce zrealizować („podwojenie liczby użytkowników do końca roku„) i dlaczego jest to istotne.

Nie prośmy zespołu, aby zbudował nam łódkę. Poprośmy, aby pomogli nam przedstać się na drugą stronę rzeki.

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

„Slack” – Tom DeMarco

Slack - Tom DeMarco

Slack – Tom DeMarco

Książka „Slack” Toma DeMarco, w wersji analogowej przeleżała na mojej półce dobre dwa lata, zanim zdecydowałem się ją przeczytać. Tą wydaną w 2002 roku pozycję kupiłem przypadkowo w czasie, gdy absolutnie zatopiłem się pozycjach czysto związanych z agile, mając jednak z tyłu głowy, że przyjdzie czas na Toma DeMarco.

Autor wychodzi od obserwacji, że ceną za osiąganie dużej wydajności w organizacjach jest utrata elastyczności oraz zdolności do reagowania na zmiany. Ciągłe „dokręcanie śruby”, aby być jeszcze bardziej wydajnym, podnosi poziom stresu u pracowników, co wpływa na szybsze wypalenie zawodowe oraz rosnące niezadowolenie. Jako główny argument, przedstawia powszechnie znane konsekwencje robienia kilku rzeczy na raz, realizowanych w imię 100% „utilizacji zasobów”.

Rozwiązaniem problemu jest tytułowy „slack”, czyli pewien luz czasowy, który w dłuższej perspektywie jest inwestycją, pozwalającą dokonywać innowacji oraz reagować na zmiany otoczenia. Takowy margines czasowy jest dla nas opcją, z której rezygnujemy, gdy za wszelką cenę chcemy się pozostać w stanie permanentnej zajętości, co w konsekwencji prowadzi do funkcjonowania w trybie przetrwania.

Tytułowy „slack” obrazowo wytłumaczył sam autor:

Slack is the way you invest in change. Slack represents operational capacity sacrificed in the interest  of long-term health.

oraz bardziej dosadnie:

Slack is when you are 0 percent busy.

Podczas czytania kolejnych stron znalazłem dużo inspirujących historii, obserwacji oraz praktycznych sugestii. Poruszane tematy to m.in. kultura organizacyjna, problem wzajemnego zaufania, rola managementu, przywództwo czy zarządzanie ryzykiem. Z jednej strony, już po kilku rozdziałach miałem pokreślony cały arkusz korporacyjnego Bulshit Bingo, z drugiej strony, Tom opisał wszystko bardzo trzeźwo i jak by nie patrzeć – ma to dla mnie sens.

Niektóre z pomysłów autora są kontrowersyjne, ale nie można mu odmówić umiejętności wywoływania ciekawych dyskusji. W jednym z rozdziałów proponuje na przykład, aby odpowiedzialność za deklarowane daty oddawania projektów brały nie osoby, które faktycznie wykonują pracę (zespół), tylko Ci, którzy te terminy obiecują (management). Pomimo, iż świadomie używany agile daje nam możliwość zakończenia rozwoju produktu w dowolnym momencie, to drobne przesunięcie odpowiedzialności jest moim zdaniem dobrym punktem startowym do rozpoczęcia dyskusji na temat odpowiedzialności.

Plusy:

+ dogłębne rozprawienie się z mitem 100% utilizacji
+ ciekawie przedstawiona rola średniego managementu
+ dużo miejsca poświęcone na omówienie wartości oraz postaw

Minusy:

– chwilami trochę niespójna, jakby złożona z różnych kawałków

Moja ocena: 4 / 5