Agile by Example - dzień 2

AbE15Z trudem, ale w końcu przelałam myśli na papier i to przed wami recenzja drugiego dnia konferencji. Muszę przyznać, że prezentacje z tego dnia w niczym nie ustępowały wcześniejszym, a może nawet je przewyższały, biorąc pod uwagę nazwiska ze świata biznesu i wieloletnich praktyków leanowych. Zapraszam zatem do lektury i do załączonych prezentacji (w przypadku Vasco Duarte i Karla Scotlanda nie ma jeszcze dostępnych prezentacji z abe15, ale znalazłam inne na ten sam temat, więc możecie z nich skorzystać).

Andrzej Blikle

Dylemat lidera Andrzej Blikle

Podział potrzeb wg BlikleDrugi dzień rozpoczął się od prezentacji nietypowego gościa, bo osoby niezwiązanej bezpośrednio z ruchem agile. Prof. Blikle ze swoim wystąpieniem doskonale jednak wpisał się w zagadnienia zarządzania ludźmi w duchu Manifestu Agile. Rozpoczął od porównania dwóch modeli zarządzania – pierwszego, opartego na władzy, oraz drugiego, opartego na partnerstwie i przypomniał badania Gallupa wskazujące na bezpośredni związek wyników finansowych firmy z zadowoleniem pracowników w niej pracujących. Następnie rozwinął ideę, że cokolwiek ludzie robią, robią to, by zaspokoić swoje potrzeby, albo wynikające z chęci jakiegoś zysku, albo stojące za naszym systemem wartości i godnością, i przeszedł do omówienia bezcelowości głęboko zakorzenionego u managerów systemu marchewki i kija i sformułowania teorii, że każda marchewka służy jedynie do tego, aby zrobić z niej kij. Bardzo mi się podobały wtrącane w trakcie prezentacji przykłady z życia, czy to o agencie ubezpieczeniowym, który jest nagradzany za konkretny plan sprzedażowy, więc pod koniec roku nie chce już sprzedawać ubezpieczeń (sic!), bo mu się nie kalkuluje i woli poczekać do stycznia, czy to o Morning Star, które zrezygnowało z przełożonych i w którym wszyscy pracownicy są równi i są dla siebie klientami (oczywiście obok klientów zewnętrznych), co przełożyło się na wzrost motywacji, inwencji i zaangażowania w pracę. Oprócz prezentacji możecie również zajrzeć do artykułu, który stanowi, moim zdaniem, dobre uzupełnienie myśli przekazanych przez prof. Blikle.

Jim Benson

Limit WIP or DIE

Jedna z lepszych prezentacji, moim zdaniem, w tegorocznej edycji konferencji. Jim Benson w przystępny sposób wyjaśnił, dlaczego tak ważne w Kanbanie jest wizualizowanie i limitowanie wykonywanej pracy we właściwy sposób. Wg niego, jeśli jesteśmy przeładowani pracą, nigdy nie zadamy sobie właściwych pytań. A co stoi za tą tezą? Fakt, iż mamy więcej na głowie, a mniej zauważamy, niż nam się wydaje. Od tego wstępu Jim płynnie przeszedł do omówienia typów Work in Progress, o których istnieniu możemy nawet nie wiedzieć, a zajmują nam czas i również wymagają wizualizowania i uwzględniania w limitach, jeśli naprawdę chcemy zacząć efektywnie wykorzystywać swój czas. Jakie to typy?

  • Normal WIP – zadania, nad którymi faktycznie siedzimy i wykonujemy je
  • Ambient WIP – praca zespołu nad innymi projektami, w które chcąc nie chcąc jakoś jesteśmy zaangażowani
  • Hidden WIP – praca na rzecz całej firmy związana z reklamami, raportami itp.
  • Induced WIP – uwielbiane przez wszystkich spotkania na temat tego, jak pracować nad zadaniami, które właśnie wykonujemy
  • Guerilla WIP – drobne zadania, które wykonujemy dla ludzi z firmy, których lubimy, małe przysługi, które fajnie zrobić, bo to zajmie 10 min. i mamy poczucie dobrze wykonanej roboty
  • Existential WIP – zadania, które tak naprawdę chcielibyśmy wykonywać, więc gadamy o tym i gadamy

Rozwiązuj prawdziwe problemy wg Jima BensonaDo niemalże wszystkich typów WIP Jim daje remedia, proste wskazówki, które mogą pomóc nam wydobyć się z multitaskingu i uporządkować swój ogródek. Dla Normal WIP to po prostu zaplanowanie pracy w zespole, jej podział ze względu na typy zadań i oddanie osobom, które najlepiej się do danych zadań nadają oraz, co niezmiernie ważne, zgoda na usprawnianie się i zdobywanie wiedzy. Ambient WIP, który dotyczy wielu zespołów wymaga po prostu rzetelnej wizualizacji, żeby pokazać, ile osób, z ilu zespołów jest zaangażowanych w ile projektów. Natomiast Hidden WIP to coś, czego prawdopodobnie nie jesteśmy w stanie uniknąć, więc musimy przyjąć z całym dobrodziejstwem inwentarza, zrozumieć i włączyć w swoją tablicę kanbanową, żeby każdy miał jasność, co za jeszcze jest odpowiedzialny. Induced WIP wymagają uporządkowania, opracowania planu działania, podkreślenia patologii, ujawnienia kosztów i opóźnień, jakie powodują, tak by ograniczyć ilość i czas trwania spotkań do niezbędnego minimum. A Guerilla WIP  to już nasza wewnętrzna walka, by ograniczyć ilość tego typu zadań, zdezaktywować ich wpływ na naszą faktyczną pracę i zachować zdrowy rozsądek. Całość prezentacji Jim podsumował dodatkowym ważnym komunikatem, że samo wprowadzenie limitów, bez zrozumienia, z czego wypływają, spotka się z oburzeniem i torpedowaniem pomysłu – musimy zwracać uwagę na ukryte zadania i potrzeby ludzi, by ograniczanie WIP faktycznie im pomogło, a nie rodziło dodatkową frustrację.

Niels Malotaux

Examples how to move towards Zero Defects

DesignLog wg Nielsa MalotauxNiels wyszedł od ambitnego założenia, że zero wad czy błędów powinno być celem każdego zespołu, bo inaczej zatrzymujemy się na akceptowalnym poziomie, który wbrew pozorom może być daleki od naszego upragnionego zera. Co jednak ważne, jak podkreślał, samo dążenie do zera błędów i powstałe w jego wyniku oprogramowanie nie stworzy wartości, a jedynie warunki do tego, aby to nasz użytkownik, czy klient tę wartość zaczęli tworzyć. Z tego względu powinniśmy również nie skupiać się tylko na idei zera błędów, ale szukać tych podstawowych, pierwszych przyczyn wad, aby nie poprawiać tylko błędy, ale wyeliminować ich przyczyny. Wówczas dopiero możemy zacząć mówić o kompleksowym podejściu do idei zera błędów. Innym przykładem na walkę z błędami jest wg Nielsa DesignLog, czyli konstruowana przed rozpoczęciem prac lista wymagań wraz z pomysłami, w jaki sposób chcemy osiągnąć zamierzony cel (założenia, pytania, odpowiedzi, możliwe rozwiązania, kryteria umożliwiające podjęcie decyzji itd.). Na początku miałam lekkie wrażenie, że mówimy o podejściu kaskadowym do wytwarzania oprogramowania, ale okazało się, że wymagania z DesignLogu wg Nielsa mogą dotyczyć nie tylko ostatecznego kształtu produktu, ale również kwestii takich, by za rok każda osoba wprowadzająca zmiany w produkcie była w stanie uczynić to w 1-2 dni. Nic nie stoi również na przeszkodzie, aby wpleść taki DesginLog do prac w ramach jednej iteracji i po prostu przed rozpoczęciem prac doprecyzować sobie efekty, jakich oczekujemy od realizowanych zadań. Więcej na temat pomysłów, jak na wczesnym etapie prac zapewnić sobie zminimalizowanie lub zero błędów w gotowym produkcie może przeczytać w dołączonym pdfie – zawiera on slajdy wraz z opisem przemowy Nielsa.

Karl Scotland

Strategy Deployment: The Secret Sauce for Enterprise Agility

Przesłanie Karla ScotlandaKarl od wielu lat zajmuje się Kanbanem, jest twórcą gry w piłki w przystępny sposób wyjaśniającej koncept Kanbana, do której z resztą w swojej prezentacji nawiązał. Już na samym początku podkreślił, jak bardzo nie ma sensu i jak źle może się skończyć bezkrytyczne kopiowanie pomysłów innych. W związku z tym ukuł nawet termin ambidextrous methodologist odnoszący się do osoby, która właśnie patrzy na zalety i wady rozwiązań i zastanawia się, co z tego może zadziałać w nowym środowisku.Za tym idzie również sposób kierowania firmą, umożliwiający rozwój oraz teza, że Agility to nasza strategia, podczas gdy agile, Scrum, czy Kanban to tylko taktyka dojścia do celu. Jak zatem zapewnić sobie sukces? Tutaj do gry wkracza X-Matrix (więcej o nim możecie przeczytać na stronie Karla) wzorowany na metodzie Hosin Kanri. W wersji Karla matriks ma 4 składowe: strategię, taktykę, wskaźniki i rezultaty. Wszystkie propozycje zapisywane w przylegających do siebie składowych są oznaczone ze zwględu na zależności, tak by jasne było, które elementy strategii znajdują pełne odzwierciedlenie w taktyce, które częściowe, które kawałki taktyki, jakimi wskaźnikami możemy zweryfikować, i w końcu, jak nasze wskaźniki mają przełożenie na strategię. Co ważne, nie można po prostu zapisać kartki A3 z X-Matrixem, bo to nie przełoży się na sukces przedsiębiorstwa. Konieczne jest omówienie wszystkich składowych, zadanie sobie pytań o ich zasadność, zweryfikowanie tez za nimi stojących – to budzi zaangażowanie pracowników, powoduje, że rozumieją i chcą brać udział w pracach nad realizowaniem strategii. A całość prac powinna być wspierana przez jasno ogłoszone przyzwolenie na eksperymenty realizowane w duchu PDCA. Jeśli się nie odważymy zaryzykować, nigdy nie ruszymy z miejsca. Jak to świetnie podsumował Karl: Fail = First Attempt In Learning.

Mat Barrow

Introducing agility to an inflexible Health Service

Mat Barrow o efektach scrumaMam bardzo mieszane uczucia w przypadku tej prezentacji. Opowiedziana była świetnie, z dużą dozą dramatyzmu, jako że mieliśmy do czynienia z wielkim projektem, w którym pierwsze wdrożenie było dopiero po 3 latach, a wsparcie techniczne dla użytkowników zatrudniało 150 osób 24 godziny na dobę przez 7 dni w tygodniu. Wprowadzenie agile’a spowodowało drastyczną zmianę in plus, począwszy od wdrożeń co kilka miesięcy, zredukowanie znaczne ilości potrzebnych serwerów i specjalistów do obsługi i oszczędzenie w jeden rok magicznej sumy 21 milionów funtów. Problem polega na tym, że zabrakło konkretów, przykładów z życia, jak doszli do tak spektakularnych efektów. Była mowa o automatyzacji testów, usprawnianiu procesów, zmniejszeniu liczebności zespołów, spłaszczeniu struktury w firmie, współpracy i wzajemnym poszanowaniu, ale wszystko w tak dużych uproszczeniach i uogólnieniach, że nie byłam w stanie złapać choć jednego pomysłu na przyszłość, żeby wyjść z poczuciem dobrze zainwestowanego czasu. Moim zdaniem, prezentacja była świetna, ale jednocześnie o jakieś 5 lat przeterminowana. Wówczas to były potrzebne historie o sukcesie, o tym że agile może działać.  Teraz wolałabym posłuchać o ciekawych konceptach, przekraczaniu granic, prezentacji o tym, jak i gdzie przewrotnie można agile’e zastosować i jak sięgnąć jeszcze dalej z jego wykorzystaniem.

Vasco Duarte

No estimates: how you can predict the release date of your project without estimating

O Vasco wspominał już na naszych łamach Jacek, więc chętnie posłuchałam na żywo jego przemyśleń w temacie nieestymowania zadań. Jako że Vasco uważa estymowanie za stratę czasu, a dodatkowo wg niego nie przynosi to większych efektów, jeśli chodzi o precyzję przewidywania czasu zakończenia prac (co poparł wieloma przykładami), zaprezentował słuchaczom alternatywę. Dziesięć zasad, których przestrzeganie wyeliminuje potrzebę estymowania.

7 kroków do #noestimates

  1. Zaufaj swojemu procesowi, albo go zmień – procesy mają wspierać szybkie, ciągłe  dowożenie gotowej pracy. Jeśli procesy opóźniają prace, należy je zmodyfikować.
  2. Skróć proces feedbacku – nie czekaj do ostatniej chwili przed wdrożeniem na feedback od użytkowników. Im później, tym więcej narośnie komplikacji, z którymi dłużej będziemy musieli sobie radzić.
  3. Wierz danym, nie estymatom – estymata to tylko estymata, czasami twarde dane są bliższe prawdy i dostarczają rzetelniejszych informacji.
  4. Poszukaj alternatywy dla decyzji podejmowanych na podstawie estymat – pomyśl nad celem, wartością, którą chcesz dostarczyć i na tym opieraj swoje decyzje, a nie na terminach wynikających ze story pointów.
  5. Najpierw zastanów się nad wartością, potem nad funkcjonalnością – jeśli skupisz się na tym, na pewno zaoszczędzisz czasu i estymaty nie będą ci potrzebne.
  6. Estymaty to marnotrawstwo, zredukuj ich wpływ na twoją firmę.
  7. Postęp mierz tylko za pomocą potwierdzonego, działającego oprogramowania – spalenie nawet tysiąca punktów nic nie znaczy, jeśli nie idzie za tym namacalny produkt dla klienta.
  8. System, w którym pracujesz, ma przewidywalną wydajność. Naucz się go rozumieć – użyj Kanbana, WIP, obserwuj, mierz, bo to ułatwi ci podejmowanie decyzji. Może wystarczy po prostu liczyć historyjki, a nie story pointy?
  9. Nie ryzykuj swoją firmą w oparciu o słabo udokumentowane metody, używaj metod sprawdzonych a.k.a. Nadzieja jest złą strategią zarządzania (na foto 7 kroków, by dojść  do efektów).
  10. Transformacja zaczyna się od ciebie.

Obok prezentacji drugiego dnia miały miejsce również dwa panele dyskusyjne na temat Product Ownerów oraz tego, co tak naprawdę oznacza bycie agile, a także liczne kuluarowe rozmowy bardziej i mniej formalne. Niestety, nie udało mi się dotrzeć na końcową prezentację Tima Ottingera, która zebrała bardzo dobre recenzje od widzów na twitterze, ale i tak uznaję te dwa dni za inspirujące i niezmiernie przydatne. Po zeszłym, słabszym roku, gdy miałam uczucie, że liczba ścieżek wpłynęła na jakość prezentacji, Agile by Example wróciło w wielkim stylu. Aż ciężko mi sobie wyobrazić, kogo musiałby sprowadzić Piotr w 2016, by przebić tegoroczną edycję.

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