Zaproszenie na Agilię17 i zaległa relacja z 2016

Konferencja Agilia'17Wzorem lat poprzednich zapraszamy Was na konferencję Agilia. Tegoroczna edycja odbędzie się w Ołomuńcu między 27 a 31 marca. Wtorek i środa będą dniami typowo konferencyjnymi, natomiast poniedziałek oraz czwartek i piątek to dni warsztatowe. Tradycyjnie już Michal Vallo zadbał bardzo mocno o wysoką merytorykę prelegentów i moderatorów warsztatów. W mojej osobistej klasyfikacji absolutną gwiazdą tej edycji jest Donald G. Reinertsen, który zaprezentuje closing keynote oraz poprowadzi dwudniowe warsztaty z Lean Product Development.  Donald jest autorem jednej z polecanych książek przez naszych polskich trenerów agile, a David Anderson wymienia jego koncepcje jako składowe inspiracji, jakie wpłynęły na niego w trakcie opracowania tego, co znamy jako System Kanban. Z kilku źródeł wiem, że nie jest łatwo ściągnąć Donalda do ściągnięcia na konferencję, więc tym bardziej będzie to unikalna okazja do zaczerpnięcia świetnej inspiracji na temat rozwoju produktu.

Oprócz Reinertsena w ujawnionym już programie widać sporo innych prelegentów godnych wymienienia: uznani autorzy nurtów w agile tacy jak Arie van Bennekum (specjalizuje się w Agile Project Management), Gunther Verheyen czy Dominik Maximini, ale także chociażby szef produktu prezi.com, który opowie o swoich doświadczeniach w tworzeniu tej platformy. Ponownie będziemy też mieli polską reprezentację wśród występujących – swoje przemyślenia przekaże Kuba Uniejewski z olx.pl.

Unikalną próbą jest też realizacja pomysłu na “tour” po firmach – dodatkową opcją dla uczestników dzień po części konferencyjnej jest wizyta w kilku firmach na terenie Ostrawy i Brna. Koncepcja brzmi ciekawie, chętnie zobaczyłbym realizację takiego pomysłu na jakiejś polskiej konferencji.

Dla wszystkich czytelników Agile247 mamy unikalny kod, który daje 5% zniżki od ceny wejściówki na dni konferencyjne. W polu komentarzy przy zamawianiu bilety wystarczy wpisać kod AGILE247PL.

A żeby sam wpis nie był tylko zdawkową zapowiedzią, w ramach zachęty do Agilii przytoczę podsumowanie czterech najlepszych wystąpień z zeszłorocznego wydarzenia, które nieszczęśliwym splotem okoliczności (mój multitasking oraz mój syndrom studenta 😉 nie ukazały się po wizycie w Ołomuńcu.

Agilia'17 - Tom Gilb

Tom Gilb w trakcie swojego wystąpienia

Zeszłoroczną konferencję otworzył Tom Gilb z wystąpieniem “Value Delivery Planning”. Tom w bardzo mocnym wystąpieniu (z hasłami typu “no more management bullshit”) zaatakował powierzchowne zrozumienie zwinności i realizacji projektów bez pomyślenia o celu i wartościach. Tom zachęca do tego, by na początku dobrze przemyśleć, po co realizujemy dane przedsięwzięcie. Jego zdaniem w mniej niż 1 dzień zespół projektowy jest w stanie zidentyfikować najważniejszych wartości, jakie muszą być „poprawione” w danym produkcie. Bezwzględnie ważne też, by w ramach tej identyfikacji ustalić miary, jakimi będziemy je mierzyć, tak by jednoznacznie ocenić, czy prace z iteracji na iterację posuwają się w dobrym kierunku i czy zbliżamy się do celu. W projektach nie ma jednej dobrej miary zbierającej wszystkie potrzebne kwestie, dlatego potrzebne będą równolegle funkcjonujące metryki. Tom zachęcił też do szerszego spojrzenia na Agile, jego zdaniem często funkcjonuje uproszczone jego zrozumienie – dostarczamy dobre oprogramowanie, bez błędów, dzięki czemu świat jest lepszy. Dla Gilba prawdziwy agile to dostarczanie wartości dla klientów i interesariuszy, przy elastycznym zmienianiu designu naszych systemów. I ta wartość powinna być dostarczana co tydzień, aż osiągnięte zostaną cele ustalone w ramach warsztatu na początku projektu, albo odkryjemy, że te cele nie są już aktualne. Zachęca też stronę biznesową projektów IT do nieakceptowania automatycznych odpowiedzi „tego się nie da zrobić w 1 tydzień” – zawsze się znajdzie rozwiązanie. Tom ironizuje, że IT jest powszechnie znane z niedostarczania wartości i promuje w projektach swoją regułę 6 „jedynek”, pomagającą w dekompozycji zakresu prac do wykonania:

  • 1% poprawy,
  • 1 interesariusz
  • 1 wartość/cecha,
  • 1 tydzień,
  • 1 funkcja,
  • 1 design

Ujmując powyższą regułę jednym zdaniem: skup się na poprawie jednej kwestii dla jednego klienta, po tygodniu sprawdź, czy się udało poprawić mierniki, i przejdź do kolejnej pojedynczej poprawy.

Kolejną zapadającą w pamięć prelekcją było “Connecting requirements and solutions in your agile world” Jamesa Archera. Prezentacja ta miała dwie warstwy – jeden temat to wprost rady na temat tego, jak pracować z wymaganiami i potrzebami w produkcie. Drugą warstwą, równie interesującą, było odniesienie tych koncepcji do rzeczywistego przypadku, ze świata bardzo oddalonego od typowych projektów IT. Problem, który trzeba pokonać na początku każdego projektu IT to fakt, że członkowie zespołu i interesariusze zakładają, że znają rozwiązanie. Łatwo zespołowi wskoczyć w dyskusję o szczegółach rozwiązania, bez próby zakwestionowania pierwszych pomysłów i odkrycia prawdziwych potrzeb klienta. James przypomniał rozróżnienie dwóch faz przy każdym projekcie – Discovery (odkrywanie prawdziwych potrzeb, w fazie tej nie należy próbować zgadywać rozwiązania) i Delivery (budowanie produktu w oparciu o zidentyfikowane potrzeby). Zacytował też przestrogę sformułowaną przez Russela Ackhoffa: “przyczyną niepowodzeń jest częściej to, że rozwiązujemy zły problem, a nie dlatego, że znajdujemy złe rozwiązanie na właściwy problem”. Jako przykład właściwego zrozumienia problemu prelegent przytoczył historię firmy Buurtzorg. Firma ta zajmuje się organizowaniem wsparcia pielęgniarek środowiskowych, zaczęła funkcjonować w 2006 roku w Holandii. Na początku firmę tworzył jeden zespół, składający się z 4 pielęgniarek. W tej teoretycznie ustabilizowanej branży firma Buurtzorg znalazła unikalny sposób rozwiązywania prawdziwych potrzeb swoich klientów i do 2016 roku urosła do 10.000 pielęgniarek, stanowiących 850 samodzielnych zespołów. Sercem unikalnego modelu jest osoba potrzebująca pomocy, to wokół niej poukładane są wszystkie inne kwestie organizacyjne. Cała konstrukcja systemu dąży do najwyższej oceny satysfakcji klienta, nie skupia się na szukaniu jak najtańszego rozwiązania czy standaryzacji pracy wykonywanej przez wyspecjalizowane, oddzielne osoby. Z perspektywy kosztu jednostkowego za godzinę pracy takiej pielęgniarki, ten model jest droższy (wszystkie prace, nawet najprostsze, wykonywane są przez wysoko wykwalifikowane osoby). Okazuje się jednak, że skupienie się na prawdziwych potrzebach klientów i opieka całościowa nad nim doprowadza do wyraźnie szybszej poprawy zdrowia, więc całościowo koszty zapewnienia ochrony zdrowia radykalnie spadają (holenderski odpowiednik NFZu zaoszczędził na tych usługach 40% budżetu). Unikalna jest też koncepcja zarządzania tą organizacją – podstawą funkcjonowania Buurtzorga jest samoorganizujący się zespół pielęgniarek, które razem współodpowiadają za zapewnienie swoich usług na danym terenie. Zespół taki może mieć maksimum 12 osób, a jeśli urośnie bardziej, wymagane jest, by pielęgniarki podzieliły się na mniejsze zespoły i zaczęły funkcjonować oddzielnie. Tym sposobem model się bardzo łatwo i bardzo wydajnie skaluje, w żadnym zespole nie ma menedżera i poza samymi zespołami funkcjonuje jeszcze tylko bardzo małe grono osób w Centrali firmy, której wyłącznym celem jest wsparcie pracy pielęgniarek, realizowanie ich potrzeb. Warto poszukać więcej informacji na temat tej unikalnej organizacji, wierzę też, że w niejednej prezentacji przykłady z tej firmy będą przytaczane.

Scott Ambler wyjaśnia Disciplined Agile Delivery

Scott Ambler na Agilii’17

Następną udaną prezentacją było wystąpienie Scotta Amblera, który zaprezentował swój framework “Disciplined Agile Delivery”. DAD jest frameworkiem podejmowania decyzji na temat tego, jakiego procesu używać. Scott wymienił kilka podstaw, jakimi się kierował tworząc ten framework. Pierwszą zasadą jest podkreślenie istoty empiryzmu, ważniejszego od jakiejkolwiek teorii. Z tego powodu DAD jest podejściem hybrydowym – składa się z pomysłów z wielu różnych innych metod, zarówno ze świata zwinnego jak i z tradycyjnych podejść.Kolejną zasadą jest podkreślenie wagi kontekstu przy wyborze metod i technik pracy zespołów IT. Każda organizacja jest wyjątkową kombinacją wielkości zespołów, położenia geograficznego zespołów względem siebie, ilości rynków na których firma funkcjonuje, złożoności domeny, w jakiej oferuje produkty, różnorodności technologicznej, w jakiej funkcjonuje. Z powodu wszystkich tych (i wielu innych) różnicujących aspektów, Ambler zniechęca do ślepego realizowania jednego jedynego słusznego podejścia, w szczególności do kopiowania rozwiązań pomiędzy firmami. Trzecią zasadą, na której oparty jest framework DAD jest fakt, że powtarzalne rezultaty są ważniejsze niż powtarzalny proces. Autor zachęca do wiary w ludzi, w to, że gdy da się im prawo decydowania o wydawaniu pieniędzy/zasobów firmy, wybiorą inwestowanie tych środków w mądry sposób (dostarczenie rozwiązania spełniającego potrzeby w rozsądnym czasie) a nie zrealizowanie zadania zgodnie z harmonogramem, zakresem i budżetem. Kolejną zasadą, na której opiera się DAD jest podejmowanie decyzji na podstawie posiadanych informacji. W zależności od zróżnicowania organizacji i potrzeb biznesowych, Disciplined Agile zachęca do wyboru jednego z czterech cykli dostarczania – Agile Delivery (coś co w skrócie wygląda jak typowy Scrum), Lean Delivery (przypomina to Kanban z dość długim cycle timem), Exploratory Delivery (Lean Startup) i Continuous Delivery (bardzo częste, płynne dostarczanie produktu w małych przyrostach). Podobne “chińskie menu” możliwych wyborów Scott proponuje na wszystkie możliwe tematy związane z wyborem sposobu pracy czy technik wykorzystywanych przez zespół. Na przykład sposób specyfikowania wymagań – jednym ze sposobów może być backlog historyjek użytkownika, ale w innych kontekstach lepszy będzie szkic na białej tablicy, w jeszcze innych klasyczny dokument specyfikacji czy lista hipotez do sprawdzenia w projekcie. Każda metoda specyfikowania ma zalety i wady, nie ma jedynej słusznej, pasującej wszędzie. Coś co Scott podkreśla, to to, by takie decyzje nie odbywały się w sposób losowy, ale by opcje wyboru były jednoznacznie określone, a sam proces wyboru były jasny i jawny. Każdy zespół realizujący prace jest właścicielem swojego procesu i będzie podejmował swoje wybory. W podobny sposób, szerszy i otwarty na większą ilość narzędzi, Scott podchodzi też do ciągłego usprawniania. Zachęca w kolejnej ze swoich zasad, by usprawniać organizację w sposób ciągły i jako całość, z wykorzystaniem różnych narzędzi, nie tylko retrospektyw sprintu, ale też ankiet czy sprawdzania miar. Zespoły powinny dzielić się swoimi pomysłami na usprawnienia na poziomie całej organizacji, by wszyscy mogli się z tego uczyć.

Ostatnią prezentacją, którą chcę tu przytoczyć, była historia o zastosowaniu Scruma w zespole biznesowym w branży muzycznej. Anthony Montgomery rozpoczął od sprowokowania publiczności stwierdzeniem, że Scrum nie jest tylko narzędziem do pracy z niepewnością, bo jego zdaniem, równie ważnym aspektem Scruma jest jego siła usprawniania interakcji, co przekłada się na korzyści biznesowe w branżach innych niż IT. Opowiedział historię zespołu biznesowego (7 osób), który zajmował się procesowaniem umów w przemyśle muzycznym. Zespół był podzielony, składał się z osób o różnych stylach pracy, trzymających się indywidualnie swoich własnych metod. Prelegent dołączył do tego zespołu jako agile coach, ponieważ mieli problemy – nie dotrzymywali swojego umówionego czasu procesowania umów (zapisanego w kontraktach z artystami), rosła im lista nieskończonych umów, a wszystko to przekładało się też na złe relacje wewnątrz organizacji (konflikty z innymi działami, które były przyblokowane przez ich opóźnienia) oraz duże ilości nadgodzin u członków zespołu. Menedżer tego zespołu poprosił Montgomerego o wsparcie przy wykorzystaniu Scruma. Zaadaptowali zdarzenia scrumowe, aby lepiej odzwierciedlały specyfikę tej pracy – ustalili tygodniowe sprinty i 30 minutowe planowanie na początku tygodnia, przygotowali fizyczną tablicę scrumową, pod którą odbywał się Daily Scrum. Modyfikacją frameworka było to, że cały zespół robił sobie codziennie Review na koniec dnia pracy, trwające 15 minut. Dopełnieniem cyklu była Retrospektywa na koniec sprintu. Dzięki zastosowaniu rytmu scrumowego zespół błyskawicznie się odblokował, w kolejnych sprintach zaczął przyspieszać swoją pracę, wymieniać się kompetencjami i usprawniać swoje metody działania tak, że po kilku miesiącach uzyskali 89% wzrostu produktywności, 71% spadku czasu procesowania umowy i 45% redukcji nadgodzin (pewna ilość nadgodzin pozostała naturalna z racji cyklicznych okresowych wzrostów ilości umów do przeprocesowania). Uzyskano trwały rezultat, usunięty został backlog zaległości, a wszystko to zaskutkowało też efektami ludzkimi – lepsze morale zespołu, obniżony stres i znacznie lepszy komfort współpracy.

Zapraszamy na tegoroczną edycję Agilii, z pewnością w tym roku również nie zabraknie wartościowych prezentacji oraz warsztatów i okazji do międzynarodowego networkingu.

Źródła zdjęć: organizatorzy konferencji Agilia

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