Agile by Example 2014 – dzień pierwszy

abe-agilebyexample-2014Po wyczerpujących, ale niezwykle stymulujących umysłowo trzech dniach na Agile by Example 2014 w Warszawie wreszcie przyszła pora, by podzielić się z wami prezentacjami, które miałam możliwość zobaczyć. Zanim jednak zacznę, muszę chwilę ponarzekać na pomysł organizatorów, by wprowadzić dwa tracki: pierwszego dnia dla początkujących, a drugiego dla Product Ownerów. Konieczność wyborów bywała trudna, bo niejednokrotnie okazywało się, że w tym samym czasie mają miejsce dwie interesujące mnie prelekcje i siedziałam z rozdwojoną jaźnią, słuchając jednej i czytając o drugiej na twitterze. Bolesne doświadczenie. Wracając jednak do prezentacji…

Developing Great Scrum Masters

slideshare_200x50

 

Absolutnym mistrzem sceny był Angel Medinilla, który wystąpił dwukrotnie (o drugiej prezentacji przeczytacie w następnym artykule autorstwa Jacka Wieczorka). Pierwszego dnia opowiedział o rozwoju Scrum Mastera, wychodząc od historii, jak szukał wskazówek na temat tej roli w literaturze z początków ruchu Agile i jak niewiele znalazł poza Scrum Guide’em. Wg niego ten niedostatek informacji powoduje, że z jednej strony niezwykle ciężko znaleźć dobrego Scrum Mastera, a z drugiej wciąż jest to rola niedoceniania i lekceważona w organizacjach, które zamiast tego skupiają się na szkodliwym micie samoorganizujących się zespołów. Medinilla uważa, że nie ma czegoś takiego i zespół bez mądrego wsparcia podryfuje w złą stronę, nie biorąc pod uwagę niezbędnych w swojej pracy ograniczeń dla dobra klienta (w oryginale mowa była o alignment, boundaries oraz constrains).

Ángel Medinilla - Developing Great Scrum Masters

Ángel Medinilla – Developing Great Scrum Masters

I stąd właśnie próba sklasyfikowania przez Medinillę kolejnych etapów rozwoju Scrum Mastera, których występowanie w dużej mierze uzależnione jest od samoświadomości SMa i sytuacji, w jakiej znajduje się zespół. Na samym początku mamy zatem Scrum Dude (tak, to świadome nawiązanie do Big Lebovskiego), czyli osobę, która z jakichś względów została desygnowana na SMa i, przeczytawszy Scrum Guide’a, lecz wciąż nie bardzo wiedząc, o co w tym wszystkim chodzi, próbuje zgodnie z wytycznymi prowadzić ceremonie, zadawać na daily 3 pytania i spisywać gdzieś przeszkody. Opanowanie mechaniki Scruma wystarczy, by Scrum Dude popadł w samozadowolenie i bez refleksji twierdził, że zespół robi świetną robotę. Na szczęście większość SMów po pewnym czasie wraz z rozwojem zespołu ma szansę zmienić się w Scrum Mamę. Jest to osoba, która aż do przesady dba o potrzeby zespołu, broni go, usuwa mu z drogi przeszkody, zarządza procesem i spotkaniami, troszczy się o prędkość i daty wdrożeń, unika konfliktów i rozstrzyga spory pomiędzy developerami. Co poniektóre Scrum Mamy z czasem ewoluują w kierunku Prawdziwego Scrum Mastera, czyli Yody, który pomaga zespołowi nabierać samodzielności, uczy współpracować, wskazywać problemy i rozwiązywać konflikty. Prawdziwy SM dba o motywację współpracowników, jest dla nich mentorem i coachem, myśli o rozwoju zespołu w perspektywie roku czy dwóch, a jednocześnie jest agentem zmiany i gorącym orędownikiem Agile na wszystkich szczeblach organizacji. I tylko niewielu Prawdziwych Scrum Masterów potrafi wzbić się na ostatni, najwyższy poziom, nazywany przez Medinillę Agile Nirvaną. SM na tym poziomie słucha zespołu i jak lustro odbija jego kondycję i problemy, natomiast zespół jest w stanie przy tym lustrze samodzielnie sobie z nimi poradzić.

Ángel Medinilla

Ángel Medinilla – Scrum Master as a Unicorn

Na koniec Angel wspomniał jeszcze o cechach wyróżniających prawdziwie dobrego Scrum Mastera: wiedzy technicznej, podejściu do ludzi oraz zrozumieniu agile. Jeśli brakuje którejś z tych trzech albo będziemy mieć bezdusznego robota, nieoglądającego się na potrzeby ludzi, albo empatycznego entuzjastę Agile, który nie rozumie strony technicznej pracy zespołu, albo managera, który tylko zajmuj się tym, kto i co ma zrobić. Połączenie tych trzech cech to nasz mityczny jednorożec, idealny Scrum Master, dlatego dla dobra zespołu i organizacji tak ważne jest, by wspierać Scrum Mastera również w jego rozwoju.

5 reasons to use V2MOMs at your company

slideshare_200x50

 

Karol Traczykowski, CEO Goldenline zaprezentował w krótkiej prezentacji zalety podejścia V2MOM używanego w jego firmie już od 4 lat. Ten tajemniczy skrót to idea Marka Benioffa na sprecyzowanie strategii dla firmy na jednej kartce:

  • Vision – big picture dla firmy na następne 12 miesięcy
  • Values – 3 do 5 głównych wartości, które są ważne dla firmy
  • Methods – taktyki, by osiągnąć zakładane cele
  • Obstacles – rzeczy, które mogą utrudniać nam osiągniecie celów
  • Metrics – czyli innymi słowy KPI dla naszych celów
Karol Traczykowski - 5 reasons to use v2mom at your company

Karol Traczykowski – 5 reasons to use v2mom at your company

Aby V2MOM miało szansę się sprawdzić, musimy jednak pamiętać o paru warunkach – tutaj Karol odniósł się już do przykładów z własnego podwórka i opowiedział o praktykach Goldenline. Przede wszystkim V2MOM tworzone jest kwartalnie i podlega ciągłym aktualizacjom, w zależności od tego, jak zmienia się firma, jej otoczenie, rynek i wymagania klientów. Co ważne, strategia obejmuje wszystkie działy i zespoły – jest wspólna dla całej firmy, co pozwala zachować jasne cele i zgodę co do kierunku rozwoju. Jednocześnie zaś umożliwia każdemu odnalezienie się i określenie swojej roli w aktualnym V2MOM. Muszę przyznać, że prezentacja zostawiła we mnie niedosyt, czasu było zbyt mało, żeby bardziej szczegółowo zgłębić temat, ale chętnie posłuchałabym o konkretnych przykładach i ewentualnych problemach z implementacją tej idei w Goldenline.

Yes, we kanban

slideshare_200x50

 

Tomasz Łasica i Mateusz Srebrny - Yes we Kanban

Tomasz Łasica i Mateusz Srebrny – Yes we Kanban

Po dwóch prezentacjach dla bardziej zaawansowanych uczestników przeniosłam się do sali z trackiem dla początkujących, bo bardzo chciałam posłuchać jedynej prezentacji o Kanbanie i zweryfikować jej przydatność w świetle moich doświadczeń z Andersonem. Tomasz Łasica i Mateusz Srebrny postanowili pokazać, jak pracują Kanbanem, opowiadając historię przykładowego zespołu i odwołując się do jego tablicy. Mamy więc zawalonego pracą testera, a gdy podobnie rzecz się zaczyna mieć z developerami, zespół postanawia wspólnie narzucić sobie limity WIP (Work in Progress) oraz wprowadzić kolumnę dla rzeczy gotowych do przetestowania. Podejście działa, co więcej okazuje się, że developerzy mogą testerowi pomóc w testowaniu i jeszcze mają slack time, żeby zająć się refactoringiem i pracami technicznymi, które byłyby potrzebne za jakiś czas. Wtem pojawia się błąd, który trzeba naprawić natychmiast, ale limity są wysycone, więc zespół wprowadza dodatkowy pas (highway) do obsługi jednego, palącego zadania ponad limity. Wg Tomka nie jest to praktyka kanbanowa, ale ładne obejście na potrzeby zespołu. Po jakimś czasie do zespołu przychodzi PM z pretensjami, że najważniejsze zadania nie są wykonywane, więc pojawia się potrzeba stworzenia kolumny Next, do której będą trafiać trzy pierwsze zadania do wykonania. Podsumowując, Mateusz stwierdził, że ich prezentacja ma pokazać ludziom, że warto skorzystać z Kanbana, bo jest fajniejszy i łatwiejszy od Scruma.

Ja, podsumowując, stwierdzam, że ich prezentacja mogła przynieść osobom, które spróbują Kanbana, więcej szkód niż pożytku. Było to coś na kształt przedstawiania mechaniki Scruma bez słowa o Agile Manifeście. Przede wszystkim Kanban nie jest łatwiejszy od Scruma – wymaga mnóstwa samodyscypliny, choćby ze względu na brak konkretnego frameworka, w którym się poruszamy, i brak dedykowanego Scrum Mastera, który pomagałby zespołowi się rozwijać i nie zbaczać z właściwej drogi. Przedstawione w prezentacji limity, wizualizacja pracy, zarządzanie procesem pracy to zaledwie czubek góry lodowej, o którą łatwo się rozbić, choćby zbyt lekkomyślnie podchodząc właśnie do limitów WIP (a jak może to być skomplikowane, mieliście możliwość przeczytać u nas już wcześniej). Przytoczone przeze mnie wyżej słowa Tomka o dodatkowym pasie na tablicy nijak się mają do sedna Kanbana. Nie ma czegoś takiego, jak praktyka czy proces kanbanowy (o czym dobitnie pisze sam Anderson). Kanban to idea lepszego zarządzania i dostarczania. W jaki sposób to osiągniemy, zależy od zespołu. Dodatkowy pas na tablicy to właśnie kaizen (ciągłe usprawnianie) danego zespołu, który idealnie wpisuje się w wizualizowanie pracy i ciągłe usprawnianie. Dlaczego miałoby to być obejście, jeśli służy zespołowi i dzięki niemu klient zostaje szybciej i lepiej obsłużony?

Why agile is not good for your company…

Krzysztof Daniel - Why agile is not good for your company

Krzysztof Daniel – Why agile is not good for your company

Krzysztof Daniel postanowił na przykładzie firmy, w której odpowiadał za QA, pokazać, kiedy agile sprawdza się w organizacji, a kiedy jest niewskazany. Największym problemem tej firmy był duży klient, który skutecznie negocjował ambitne SLA i forsował kontrakty z ustalonymi zakresami, ceną i terminem, uniemożliwiające pracę w zwinny sposób. Historia tej firmy skończyła się w ten sposób, że klient chcąc niemożliwego, wykupił ich w końcu, by móc w pełni „u siebie” prowadzić projekty. Wg Krzyśka tej sytuacji dałoby się uniknąć, jeśli w firmie byłaby jakaś strategia, świadomość sytuacji, w jakiej się znajdują, i mapa Wardley’a. Owa mapa miała być narzędziem, które pozwoliłoby na ocenę i wybranie skutecznej taktyki wobec klienta. Przyznam szczerze, że jej koncept wydał mi się zbyt skomplikowany i trudny do zrozumienia, a krótki czas prezentacji nie ułatwił tego zadania. Jednocześnie wywodzenie konkluzji pod tytułem „agile sprawdza się tam, gdzie wiele wątków jest nieznanych, a nie ma sensu tam, gdzie wszystko jest wiadome” ze skomplikowanej mapy chyba jest trochę przerostem formy nad treścią, bo prosty wykres złożoności czy ćwiartki Cynefina mówią dokładnie o tym samym.

How to build MVP with Walking Skeleton and Story Mapping

Prezentacja Andrzeja Winnickiego spodobała mi się z jednego, podstawowego powodu – faktycznie była „by example”. Pojęcia MVP, Walking Skeleton czy Story Mappingu dla większości osób pracujących przy produkcie są już dobrze znane, o ile jednak dużo słyszy się teorii na ich temat, tutaj mieliśmy możliwość zobaczyć, jak te konkretne techniki przyczyniły się w konkretnym zespole do świadomego rozwoju produktu. Pozwólcie więc, że wprost zacytuję ze slajdów Andrzeja kolejne wskazówki:

  1. Zbierz razem wszystkich zaangażowanych w rozwój produktu

    Andrzej Winnicki - How to build MVP with Walking Skeleton and Story Mapping

    Andrzej Winnicki – How to build MVP with Walking Skeleton and Story Mapping

  2. Zidentyfikuj główne czynności w produkcie
  3. Podziel czynności na etapy
  4. Dla każdego etapu stwórz listę historyjek
  5. Spriorytetyzuj historyjki w zależności od ich spodziewanych rezultatów
  6. Zdefiniuj zakres MVP
  7. Wyestymuj wielkość MVP
  8. Stwórz roadmapę produktu

Na koniec prezentacji Andrzej wymienił również powszechnie spotykane przy wymienionych technikach błędy, czyli wykonanie planu minimum jako cel sam w sobie, brak kontroli nad historyjkami, które mają być zrobione później czy brak wystarczającej pieczy nad testami wykonanej pracy. Patrząc z pozycji Product Ownera czy developera, dostałam gotowe rozwiązanie, które mogę przećwiczyć krok po kroku w swoim zespole. Kawał dobrze wykonanej roboty!

Staying On Track

Paweł Wrzeszcz - Staying On Track

Paweł Wrzeszcz – Staying On Track

O prezentacji Pawła Wrzeszcza nie mogę wiele napisać, bo dotyczyła tak naprawdę jednej prostej prawdy. Jednej, ale za to naprawdę ważnej. Jak sprawić, by zespół zawsze szedł w dobrym kierunku? Co zrobić, by zespół był naprawdę skuteczny i dostarczał najbardziej wartościowe rzeczy? Jak skrócić spotkanie do absolutnego minimum i wyjść z maximum informacji? Które elementy produktu są niezbędne, a których możemy się pozbyć? Na każde z tych pytań wg Pawła jest tak naprawdę jedna, trochę przewrotna odpowiedź: zapytaj o cel. Trafność tej odpowiedzi została poparta w prezentacji wieloma przykładami z życia, w których brak pytania o cel spowodował straty, zejście z właściwej drogi, wyprodukowanie niewłaściwych produktów, nietrafienie w potrzeby użytkownika i wiele innych problemów. Jako że i mi czasami zdarza się w ferworze dyskusji zapomnieć o tym, jaki przyświecał jej cel, kudosy Pawłowi za odświeżenie tej prostej prawdy. Postaram się pamiętać, by z tyłu głowy zawsze mieć przygotowane pytanie o cel.

Rewiring humans. Neurosurgery experiments for you and your (un agile) colleagues.

Robin Dymond, Tomasz Wykowski - Rewiring humans

Robin Dymond, Tomasz Wykowski – Rewiring humans

Przyznam szczerze, że nie zdzierżyłam tej prezentacji. Przede wszystkim zaczęła się z opóźnieniem tuż przed 18, gdy po podróży i całym dniu prezentacji mój mózg zaczął już odmawiać współpracy. Po drugie pierwsze pół godziny można podsumować jako problemy z wyświetlaniem prezentacji (dużo, dużo tekstu na slajdach) i próbę opisania zachowania ludzkiego mózgu – co o nim sądzono, a co się okazało po wielu latach badań. Stanowczo brakowało mi tu jakiegokolwiek odwołania do Kahnemana i tego Robinowi Dymondowi i towarzyszącemu mu Tomaszowi Wykowskiemu nie mogę darować, jako że gros tego, o czym mówili, zawdzięczamy właśnie jego badaniom. A potem usłyszałam o modelu SCARF, którego można użyć w służbie Agile i za jego pomocą przeprogramować Project Managera w Scrum Mastera, i stwierdziłam, że wystarczy.

Żałuję niestety, że nie udało mi się dotrzeć na otwierającą konferencję Mary Poppendieck, dlatego gorąco zachęcam tych, którzy mieli tę okazję, do podzielenia się w komentarzach własnymi przemyśleniami na temat jej prezentacji. Chętnie przeczytam, by dowiedzieć się, co ciekawego mnie ominęło.

Komentarze do wpisu: “Agile by Example 2014 – dzień pierwszy

  1. Bartek Janowski

    Mi się pomysł osobnymi trackami podobał. Main track był miejscami dość ogólny, a mało agile’owy (scrumowy, kanbanowy). Na dodatkowych ścieżkach (dla początkujących oraz dla PO) były bardziej „konkretne” prezentacje. Szczególnie, że niektórzy na ABE byli pierwszy raz, agile jest nowinką albo ktoś chciał poszerzyć wiedze na temat PO.

    Wiele innych konferencji jest również „wielościeżkowych”.

    Trochę druga sala była za mało (i strasznie w niej wiało).

    Pozdrawiam,
    Bartek

    • Hej Bartek. Jasne, że wiele konferencji jest wielościeżkowych, ale jak sam piszesz, main track czasami był dość ogólny. Może gdyby był jeden track, to mielibyśmy tylko konkretne, wartościowe prezentacje i wszyscy mogliby z nich skorzystać, bez konieczności wyboru i przypadkowego trafienia akurat na tę słabszą z dwóch.


Dodaj komentarz

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

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x