Agile By Example 2014 – dzień drugi oraz podsumowanie

Moja przygoda z ABE 2014 rozpoczęła się od zaakceptowania 75-minutowego spóźnienia pociągu relacji Poznań-Warszaw, co spowodowało, że nie udało mi się dotrzeć na keynote Bob’a Marshalla. Opinie, które zebrałem podczas przerwy pomiędzy wykładami, nie pomogły mi uzyskać jednoznaczej oceny tego wystąpienia – jedni byli zachwyceni, inni czuli niedosyt. Zainteresowanych przemyśleniami Boba odsyłam do jego bloga, a osoby obecne na prezentacji do podzielenia się wrażeniami w komentarzach pod artykułem.

Cztery prezentacje, które moim zdaniem warto wyróżnić drugiego dnia konferencji, to:

Ángel Medinilla – “Lean Startup for Agile Product Management”

Angel zrobił sobie dobry PR podczas pierwszego dnia ABE, prezentując swoje przemyślenia dotyczące ścieżki rozwoju Scrum Mastera. W konsekwencji, drugiego dnia, jego prezentacja dotycząca zarządzania produktem zebrała absolutnie pełną salę. Po pierwszych kilku minutach zrozumiałem, że nie dzieje się to bez przyczyny – pochodzący z Hiszpanii prelegent od pierwszej minuty udowadniał, że jest chodzącym wulkanem południowej energii, wypluwając z siebie anegdoty oraz żarty w tempie, które było absolutnie poza zasięgiem lokalnych prelegentów. Co ważne, w parze ze świetnym obyciem jako prelegenta szła sensowna porcja wiedzy dotycząca szeroko rozumianego Product Ownershipu.

Ángel Medinilla - Lean Startup for Agile Product Management

Ángel Medinilla – Lean Startup for Agile Product Management

Nasz bohater wyszedł od trafnej obserwacji: produkujemy zbyt dużo oprogramowania, a co gorsze, zbyt często wytworzone produkty te nie rozwiązują prawdziwych problemów, lub rozwiązują je w niewłaściwy sposób. W skrócie, jako rozwiązanie proponuje podejście promowane przez Erica Risea w książce “Lean Startup”, która dla wielu jest biblią opisującą, jak wypuszczać nowe produkty na rynek.

Podczas prezentacji Angel przedstawił bardzo dużo materiału, by na koniec podsumować to w 10 punktach, które – parafrazując – brzmią następująco:

1. Przygotuj wizję produktu i regularnie nad nią pracuj

2. Skupiaj się na problemie, nie na rozwiązaniu

3. Zastanów się, w jaki sposób będziesz zarabiał (Business Model)

4. Testuj swoje założenia produktowe budując MVP (link agilecoaching)

5. Rozmawiaj (na żywo) ze swoimi klientami, nawet jeśli jest to poza Twoją strefą komfortu

6. Rozwijaj produkt iteracyjnie & inkrementalnie

7. Definiuj wizję produktu wraz z całym zespołem

8. Zdefiniuj lejek (ang. funnel) konwersji oraz metryki sukcesu

9. Definiując założenia produktowe używaj celów produktowych oraz odpowiednich metryk (jedna metryka w danym momencie)

10. Buduj proste produkty – unikaj niepotrzebnych funkcji

Oprócz tego, warte wspomnienia są następujące idee:

  • buy a feature” – technika, która pomaga określić, które elementy Product Backlogu są naprawdę ważne, została bardzo dobrze opisana na stronie innovationgames.com
  • kill a feature day” – zbyt często aplikacje przeładowane są zbędnymi, mało używanym funkcjonalnościami – pomysł polega na wybraniu jednego dnia w tygodniu, podczas którego usuwamy jedną funkcjonalność z aplikacji (najmniej używaną)

Na koniec trafne, humorystyczne porównanie Angel’a, wspomniane przy okazji fragmentu o cięciu wymagań na mniejsze kawałki – „mówienie do Alistaira Cockburna, że jakiejś historyjki nie da się pociąć na mniejsze części, to jak mówienie do Stephena Hawkinga, że ten nie zna się na fizyce” (Alistair jest autorem ćwiczenia Elephant Carpaccio, które uczy cięcia wymagań na b.małe kawałki w kilkuminutowych iteracjach – przyp. red.)

Henri Karhatsu – “#NoEstimates – Alternatives to Estimates”

Henri Karhatsu - “#NoEstimates - Alternatives to Estimates”

Henri Karhatsu – “#NoEstimates – Alternatives to Estimates”

O idei #NoEstimates pisałem jakiś czas temu na łamach agile247.pl – tym bardziej zainteresowała mnie prezentacja Henri’ego i byłem ciekawy, od jakiej strony podejdzie do tematu. Musze przyznać, że prezentacja była kompleksowa i nie zawiodłem się – od wytłumaczenia czym jest hashtag #NoEstimates, przez rozwianie mitów z nim związanym, do praktycznych przykładów wykorzystania wspomnianej ideii.

Prelegent bardzo umiejętnie pokazał, jak rozmowa o estymatach może stać się pretekstem do przeprowadzenia głębokich, merytorycznych dyskusji na temat samego produktu oraz jak może pomóc w budowaniu zaufania na linii zespół – klient poprzez częste, systematyczne dostarczanie działającego oprogramowania.

Henri słusznie również zauważył, iż to, że ktoś oczekuje od nas estymaty, nie musi oznaczać, że faktycznie jej potrzebuje. Zamiast podania estymaty zachęca do podjęcia wysiłku w celu zrozumienia, jakie decyzje podejmowane są na podstawie tych danych.

Innym trafnym spostrzeżeniem dotyczącym estymowania jest obserwacja, że fakt podania przez dwie osoby tej samej estymaty (np. 5 Story Points) wcale nie musi oznaczać, że powody podania takiej wartości dla obu osób są takie same. Zwykle zespoły dyskutują wyłącznie o skrajnych wartościach, które podają podczas sesji estymowania, rzadziej pogłębiane są jednomyślne wyniki. Skojrzyło mi się to z prezentacją J. B. Rainsberger’a „7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development” w której przedstawia tezę, że dowolne oszacowanie funkcjonalności jest funkcją składającą się z dwóch wartości: zasadniczej (ang. essential complication) oraz nieumyślnej (ang. accidental complication), co dodatkowo obniża zaufanie związane z trafnością estymaty.

Autor umieścił bardzo dużo tekstu na swojej prezentacji, co z jednej strony powodowało u mnie wyraźne rozdwojenie (słuchać preleganta czy czytać slajdy?), jednak z drugiej strony slajdy stanowią wartościowy materiał nawet dla osób, które nie mogłby uczestniczyć w prezentacji osobiście. Zdecydowanie zachęcam do zapoznania się z nimi.

Kate Terlecka – “What went wrong (and what can we learn form it)?”

Kate Terlecka - What went wrong (and what can we learn form it)?

Kate Terlecka – What went wrong (and what can we learn form it)?

Interesującą prezentację w stylu lightning talka przedstawiła Kate Terlecka, przewrotnie wskazując, że skupienie się na wartości niekoniecznie musi oznaczać od razu sukces. Na poparcie swojej tezy opowiedziała o przypadku Dreamlinera i Phaetona.

Władze Boeinga skupiły się na maksymalizowaniu wartości dla swoich akcjonariuszy i w tym celu większość prac zleciły podwykonawcom, zakładając, że te działania zapewnią im oszczędności w produkcji oraz skrócą czas dostawy pierwszych samolotów. Niestety efektem tego eksperymentu były problemy z dopasowaniem części pochodzących od różnych wykonawców, a co za tym idzie opóźnienia sięgające 5 lat oraz przekroczenie zakładanego budżetu o 500%. Dodatkowo Boeing musiał ostatecznie przejąć dwóch podwykonawców, by zapewnić sobie odpowiedni poziom jakości.

Z kolei Volkswagen postanowił skoncentrować się na wartości dla klienta i mając to na uwadze wyprodukował Phaetona – samochód, który wchodząc na rynek przewyższał technologią, wyposażeniem, możliwościami silnika i myślą inżynierską wszystkie inne, dostępne limuzyny. Jednak choć samochód ten był niezwykle luksusowy i spełniał wszystkie, najbardziej wyszukane wymagania klientów, z zakładanych 20 tys. Volkswagen wyprodukował tylko 6 tys. i zakończył produkcję. Przyczyną było niezrozumienie potrzeb klienta – ten, którego było stać na Phaetona, nie zamierzał go kupować, bo nadal był to tylko Volkswagen, czyli samochód dla ludu, natomiast dla większości dotychczasowych klientów było to auto poza ich możliwościami finansowymi.

Na deser Kate zostawiła krótką opowieść o Polaroidzie i Nokii, dwóch firmach, które skoncentrowały się na wyprodukowaniu najlepszego hardware’u i również zostały zmiecione przez konkurencję. Konkluzję prezentacji stanowi myśl, iż wartość dla klientów jest tak naprawdę drugorzędna, natomiast najważniejsza jest zdolność do adaptowania się do zmieniających się wartości na rynku.

David Hussman – “Lessons in Gravity: Helping Good Ideas Reach Escape Velocity”

David Hussman - Lessons in Gravity: Helping Good Ideas Reach Escape Velocity

David Hussman – Lessons in Gravity: Helping Good Ideas Reach Escape Velocity

Rozważania z zamykającego Agile By Example 2014 keynote’a Davida Hussmana można podsumować jednym zdaniem – nadmierne skupienie na procesie, rolach, strukturze zespołu czy architekturze może spowolnić nasz proces uczenia się oraz zwiększać “grawitację”, która uniemożliwia nam “wystrzelenie na orbitę”.

Prelegent zachęcał do przejścia w tryb “Continous Product Learning”, czyli m.in. przejścia od priorytetyzowania wymagań w Product Backlogu do traktowania go jako listy opcji, które należy walidować czy przeniesienia punktu ciężkości z dostarczania oprogramowania na chęć zdobywania wiedzy o produkcie. Pomimo, iż podejścia te nie są niczym nowym, to trzeba przyznać, że zostały całkiem zgrabnie zebrane w jedną prezentację i jako takie zmuszały do głębszej refleksji na temat szeroko rozumianego procesu rozwoju produktu.

Dave przy okazji opowiedział o inicjatywie “NonBan”, która zachęca do poszukiwania procesu, który przy minimalnej ciężkości nadal dostarcza nam możliwość dostarczania wartościowej i mierzalnej wartości. W trakcie prezentacji rozdał promocyjne wlepki oraz nadmienił, że NonBan jest tak lekki, że nie posiada treści na swojej stronie www 😉

Duża część prezentacji opisywała jeden z koników Davida, czyli Story Mapping. Wygląda na to, że podejście to zyskuje coraz bardziej na wartości – być może impulsem jest wydana po wielu latach, długo oczekiwania książka Jeffa Pattona “User Story Mapping – Discover the Whole Story, Build the Right Product”. Tak czy inaczej, rysuje się wyraźny trend w świecie agile, który przesuwa skupienie z dostarczania oprogramowania na dostarczanie (wartościowych) produktów, trend widoczny zarówno w sieciach społecznościowych, jak i na konferencjach, takich jak ABE 2014.

Podsumowanie

ABE 2014 to już historia. Do zdecydowanych plusów konferencji należy zaliczyć inspirujące prezentacje, całkiem długie przerwy pomiędzy sesjami (które stwarzały możliwość networkingu) oraz duży wybór sesji, rozdzielonych eksperymentalnie na dwie ścieżki.

Z drugiej jednak strony, wyobrażam sobie sytuację, w której można było przygotować tylko jedną ścieżkę, jednak ostrzej wyselekcjonowaną, jeśli chodzi o tematykę oraz prelegentów. W niektórych prezentacjach nacisk na część “by example” był zbyt mało wyraźny. Ponadto, tak jak pisała Ewa w relacji z dnia pierwszego, często wybór sesji był trudny i trzeba było mocno się zastanowić, na którą ścieżkę się wybrać. Na szczęście, z tego co udało mi się ustalić, wystąpienia były nagrywane, tak więc będzie szansa zapoznać się z prezentacjami, których z jakichś powodów (opóźniony pociąg, przesadnie udane afterparty, trudność wyboru) nie udało się nam obejrzeć na żywo.

Do zobaczenia na kolejnej edycji Agile By Example za rok!

Komentarze do wpisu: “Agile By Example 2014 – dzień drugi oraz podsumowanie

  1. Bartek Janowski

    Mi w dwóch ścieżka przeszkadzało, że nie były zsynchronizowane ze sobą, tzn jak kończyła się prezentacja na jednej to w tym czasie trwała inna w drugiej sali. Co skutkowało przewijaniem się ludzi podczas prezentacji, bo ta w tracku obok właśnie się skończyła/zaczęła.

    A jak Wam się podobały warsztaty..? tzn dojo 😉

    • Jacek Wieczorek

      Bartek, dzięki za Twój komentarz. Zgadza się – można było wprowadzić stałą długość prezentacji niezależnie od ścieżki, rozwiązało by to problem, o którym piszesz.

      Jeśli chodzi o dojo, to od rana prowadziliśmy z Ewą warsztat „Learn the benefits of Cynefin while building a castle” – nam się podobało, uczestnikom zdaje się również 😉 https://twitter.com/ktraczykowski/status/528179920837836800

      Natomiast w drugiej części dnia miałem okazję być na części warsztatu Pawła Wrzeszcza – „The Leadership Game” (więcej info o tej grze: https://leanpub.com/TheLeadershipGame, przebieg ćwiczenia wyglądał obiecująco, w szczególności podczas części, w której ćwiczyliśmy samoorganizację. Esencja tego ćwiczenia to finalna dyskusja uczestników, na której jednak nie mogłem zostać – wracałem wcześniej do Poznania.

  2. Bartek Janowski

    Na Cynefina się wybierałem, ale niestety się nie dostałem i miałem retrospekcję z Crazy Spanish. Całkiem ciekawa.

    Drugie dojo miałem z MGT3.0. Podobało mi się. I wydaje mi się, że reszcie uczestników również.

    Dla mnie trzeci dzień był najbardziej wartościowy. Nie tylko ze względu na tematy warsztatów, ale również ciekawe dyskusje z uczestnikami (szczególnie z Pawłem i Weroniką).


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

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