Artykuły o Agile i nie tylko.
Największy w Polsce portal o zwinności

Ponieważ materiał w mojej głowie już się odpowiednio długo przegryzał, a organizatorzy AgileByExample umieścili całość materiałów w swoim kanale na youtube, nadszedł czas, żeby podzielić się z wami moimi przemyśleniami na temat tych prezentacji, które miałam możliwość zobaczyć. Dziś zatem dzień pierwszy.

Jeff Gothelf – Sense & Respond: Continuously learning our way to better outcomes

Już na sam początek dostaliśmy bardzo ciekawe wystąpienie i, moim zdaniem, jeden z lepszych keynote’ów w historii ABE. Bardzo mi się podoba, że konferencja nie zamyka się tylko na Scruma, Kanbana, czy tzw. Agile, ale śledzi, co się dzieje w świecie, jak zmienia się IT, wytwarzanie produktów, zorientowanie na klienta, cele i miary. I tutaj Jeff opowiedział o sprawie niezwykle istotnej, o której coraz głośniej się mówi, ale z której wagi jeszcze nie wszyscy sobie zdają sprawę. Jak to, co robimy dla klienta, wiąże się z etyką, zmianami w jego zachowaniu na lepsze lub gorsze, i jaki my mamy na to wpływ. Ale po kolei. 

Jeff rozpoczął od wspomnień, jak to kiedyś można było bardzo precyzyjnie wskazać, kiedy produkt był DONE i jakie to miało przełożenie dla klienta. Ot choćby nowe programy – trzeba było napisać/zmodernizować program, wypalić płyty i wysłać do klientów lub sklepów, a potem powtarzać całość w cyklach np. rocznych. Wysłanie płyt wieńczyło dzieło i każdy wiedział, że żeby mieć nowe funkcje, trzeba zakupić nowy model lub nową edycję.

Teraz natomiast żyjemy w czasach, gdy oprogramowanie może być aktualizowane na bieżąco, czyli mamy nieustanną pętlę feedbacku i w oparciu o działania użytkownika dostosowujemy swój produkt. Jeff jako przykład podał nadużywanie przez właścicieli Tesli miejsc parkingowych z możliwością ładowania auta. Samochód ładował się godzinę, a miejsce było wykorzystywane przez następne pięć, co uniemożliwiało innym korzystanie z ładowarki. Gdy klienci zaczęli się skarżyć na ten proceder, Tesla w krótkim czasie wydała update oprogramowania wgrany w czasie jednej nocy do wszystkich swoich samochodów, który informował o naładowaniu baterii i w związku z tym dalej zaczynał naliczać opłatę za postój jak na zwykłym miejscu parkingowym. Wniosek z tego wg Jeffa płynie jeden – Agile to umiejętność szybkiego zmieniania kierunku działania w oparciu o informacje o działaniach klienta. 

A za tym, oczywiście, idzie konieczność dobrania właściwych miar, by ocenić, czy osiągamy swoimi działaniami sukces. W tym miejscu w prezentacji pojawiła się drobna dygresja o rondzie, która prosto, acz dobitnie, przypomniała słuchaczom, jaka jest różnica pomiędzy pojęciami output i outcome. Dzięki niej Jeff przeszedł płynnie do podkreślenia wagi pomiaru outcome, czyli zmiany w zachowaniu klienta, i związanej z tym etycznej odpowiedzialności. Wywód ten poparł przykładami firm, które ślepo podążając za metrykami, straciły z oczu ten wyższy sens. Wśród nich wspomnę tylko

Jeff swój wywód podsumował bardzo trafnym cytatem Kim Goodwin, konsultantki właśnie z obszaru design i zarządzania produktem: “Goal-driven. Values guided. Measure both.”, wyjaśniając jednocześnie, że nie można na ślepo wierzyć osobom zarządzającym produktem, bo obecnie zbyt wiele można stracić. Działania nieetyczne to już nie tylko utrata dobrego PRu, ale również w przypadku pracowników utrata wolności, bo przecież kozła ofiarnego trzeba znaleźć, jak przekonał się chociażby inżynier VW, który jako jedyny trafił do więzienia za projekt kodu oszukującego pomiar emisji spalin w dieslach.

Jeff słuchaczy zostawił z pięcioma wskazówkami, które mają pomóc nam pracować nad produktem w sposób i etyczny, i przynoszący wartość klientowi:

  1. Zrozum swój model biznesowy.
  2. Zainteresuj się swoimi klientami.
  3. Użyj oprogramowania do nauki.
  4. Mierz wpływ swojej pracy.
  5. Przedyskutuj niebezpieczne przypadki brzegowe.

Andrea Provaglio – A Language for Change

Andrea w swoim wystąpieniu postanowił rozprawić się z pytaniem, jak zmienić organizacje, które bazują na XX wiecznym modelu wytwarzania produktów i nie widzą konieczności przystosowania się do wciąż zmieniającego się otoczenia, co powoduje, że może i są wydajne, ale niekoniecznie już skuteczne. Żeby pomóc takim organizacjom należy, jego zdaniem, rozprawić się z obfuskacją (ang. obfuscation), czyli stanem, w którym informacje, feedback i komunikacja są limitowane. Andrea wyróżnił i omówił 9 typów, które widoczne są w firmach zachowujących za wszelką cenę status quo:

  1. Segregacja (segregation) – czyli rozdzielanie ludzi i tworzenie silosów, które utrudniają bezpośrednią komunikację i wymuszają kontakty poprzez przełożonych.
  2. Sekciarstwo (sectarianism) – czyli ludzie dzielący się z własnej woli na mniejsze podgrupy, uważające się za lepsze od innych i z tych powodów niechętne komunikacji.
  3. Feudalizm (feudalism) – czyli stan, w którym przełożony mówi poddanym, jak pracować i co robić, oraz zaczynają się gry polityczne, utrudniające podejmowanie szybkich decyzji.
  4. Kozioł ofiarny (scapegoating) – czyli przekazywanie pracownikowi odpowiedzialności bez rzeczywistego wzmocnienia osoby i jej decyzji.
  5. Przerzucanie odpowiedzialności (buck passing) – czyli stan, w którym każdy pracuje tylko nad swoim kawałkiem, na ślepo, nie patrząc na całość obrazu.
  6. Zbytnie komplikowanie (overcomplicating) – czyli niepotrzebna biurokracja, przerost formy nad treścią, zbyt wiele narzędzi i reguł, które utrudniają wytwarzanie rzeczywistej wartości.
  7. Mętna komunikacja (muddled communication) – czyli wymiana setek maili, komunikatów i raportów, zamiast bezpośredniej rozmowy i wzajemnego zrozumienia.
  8. Podzielona uwaga (fragmented attention) – czyli stan, w którym jednocześnie zajmujesz się mailami, bierzesz udział w spotkaniu, odpowiadasz w trzech wątkach na komunikatorze i dodatkowo odbierasz telefon, a więc zajmujesz się wszystkim i niczym jednocześnie.
  9. Pocztówki z przeszłości (postcards from the past) – czyli zbyt późno dostajemy jakikolwiek feedback, zbyt długo czekamy na informacje zwrotne, co powoduje, że nie pomożemy połączyć przyczyny ze skutkiem i nie potrafimy wyciągnąć wniosków, aby zmodyfikować odpowiednio prace.

Andrea jak zwykle miał solidne, może nie porywające tak bardzo jak Jeffa, wystąpienie. Problemy, na których się skupił, nie są niczym nowym i większość słuchaczy potakiwała ze zrozumieniem w trakcie jego prezentacji, natomiast myślę, że nadal warto o tym głośno mówić, bo pomimo nagłaśniania nadal w wielu firmach te przeszkody mają się całkiem dobrze.

Martin Hinshelwood – An Enterprise transformation that shows that you can too

Z prezentacjami dotyczącymi Microsoftu mam problem  i podobnie było z tą. Temat prowadzony dość nierówno, były i bardzo ciekawe przykłady, i dłużyzny nie wnoszące nic do przekazu z prezentacji. Może zatem w punktach wymienię te jasne strony:

  • Bardzo mi się spodobała definicja devopsa Martina (vide zdjęcie poniżej), nie zamykająca się na połączenie duetu admin i developer, ale rozszerzająca znaczenie tego hasła na połączenie wszystkich potrzebnych ludzi, procesów i produktów, by w sposób ciągły dostarczać wartość klientowi. 
  • MVP jako skrót Most Valuable Proffesional – chętnie kradnę i gdzieś z pewnością użyję 🙂
  • Jestem pełna szacunku dla ich rozbudowanej społeczności developerów, umożliwiającej zbieranie feedbacku od użytkowników na setki sposobów i dodawanie komentarzy.
  • Podobało mi się ich DoD: “[produkt] Jest na produkcji i zbierana jest [do niego] telemetria potwierdzająca lub zaprzeczająca początkowej hipotezie.”
  • Warto spojrzeć na prezentację, żeby zainspirować się slajdami z przykładami metryk.
  • A oprócz tego Martin omówił 7 mniej lub bardziej oczywistych nawyków (np obsesja na punkcie klienta czy infrastruktura jako elastyczny zasób), które wyrobili sobie pracownicy w Microsoft, żeby dostarczać zwinnie produkt do użytkownika.

Andy Brandt – The overlooked aspects of “Agile transformations” 4 aspects of Businness Agility

Słuchacze zostali poinformowani na początku przez Andy’iego, że zmienił tytuł wystąpienia. Co za tym idzie jego prezentacja, choć niby mówiła o tym samym co pierwotna, to jednak patrzyła na te aspekty pod innym kątem. I w moim przypadku to była dość poważna zmiana. Otrzymałam prezentację omawiającą 4 płaszczyzny transformacji, czyli organizację, kulturę, technologię i produkty z konkluzją, że jedynie pierwsza z nich, czyli organizacja, jest odpowiednio traktowana, bo firmy przeprowadzają zmiany struktur, wprowadzają metodyki jak Scrum czy Kanban, ustalają nowe role i ścieżki kariery, pozostałe trzy są natomiast ledwo dotykane, a żeby mówić o transformacji i zwinności biznesowej musimy zachować balans pomiędzy całą czwórką. Tymczasem przyszłam na prezentację, która wg zapowiedzi miała pogłębić problem z zaniedbanymi trzema aspektami i zwrócić na nie szczególną uwagę i bardzo żałuję, że tego się nie doczekałam.

Denis Vanpoucke – We are SAFe, but are we Agile?

Na prezentację Denisa poszłam, bo myślałam, że pomoże mi przełamać niechęć do SAFe i odczaruje trochę ten framework i skalowanie. I znów (bo to nie pierwsza prezentacja o SAFe, na którą z nadzieją szłam) się zawiodłam. Denis opowiedział szczegółowo, jak zaimplementowali w Skandinaviska Enskilda Banken SAFe, tworząc tribe’y, zespoły agile, iteracje, PI Planning, Review, Backlogi, czy portfolio Kanban. Do tego dołożył “ale”, jako że w organizacji nadal nie znają priorytetów, wymagań i swoich ról, i zakończył wnioskami, że trzeba odnaleźć swoją zwinność i zdefiniować KPI, bo w skalowaniu agile nie chodzi o framework. A ja wyszłam z notatką nawiązującą do tytułu wystąpienia, że nadal nie wiem, czy są Agile. A zatem polecam tym, którzy chcą posłuchać, na czym polega implementacja SAFe w praktyce, do tego nie do końca udana.

Malcolm Campbell – Transforming an Organisational Culture

Ta prezentacja była dla mnie odkryciem. Raz, że w bardzo ciekawy sposób Malcolm opowiedział o zmianach kulturowych w organizacji i to na przestrzeni dobrych kilku lat; dwa że wyszłam z przykładem dość rozbudowanego narzędzia firmy Human Synergistics, które chciałabym zgłębić i które może być przyczynkiem do wielu rozważań o kulturze w firmie. Malcolm rozpoczął od historii firmy Canon Medical w Edynburgu, która działała na całym świecie, ale brak było wśród zespołów spojrzenia na całość produktu, brak dbałości o klienta i brak dopasowania ról i struktury do rzeczywistych prac. Zamiast przeprowadzać transformację Agile firma zdecydowała się w 2015 przy wsparciu szkockiego rządu zmierzyć swoją organizacyjną kulturę. Do tego użyli właśnie narzędzia firmy powyżej, które pokazuje, na ile mamy w firmie do czynienia z kulturą

  • agresywną, gdzie ludzie skupiają się tylko na swoich potrzebach kosztem innych 
  • pasywną, gdzie ludzie chowają głowy w piasek i zdają się na decyzje przełożonych
  • konstruktywną, gdzie ludzie współpracują na rzecz wspólnych celów firmy 

Po badaniu firma Malcolma dostała raport, nie tylko jak wygląda sytuacja w organizacji, ale i w poszczególnych zespołach, jak również rozbudowane wskazówki, na czym i jak należy się skupić, żeby poprawić kulturę (vide zdjęcie). Oczywiście, całości towarzyszyły warsztaty dla przełożonych i duża akcja komunikacyjna do całej organizacji, aby każdy zrozumiał, na czym mają polegać zmiany i dlaczego organizacja ich chce. Na zakończenie Malcolm przytoczył historię menedżerów dwóch zespołów, z których jeden wspierał zmiany i zachęcał ludzi do ich wprowadzania, natomiast drugi raczej stosował bierny opór wobec nowinek. Na podstawie kolejnych raportów z badania można było prześledzić, jak zmienia się kultura w pierwszym zespole, jak staje się mniej pasywna, a bardziej konstruktywna, i jaki feedback zbiera zespół od sponsora i koordynatora. Widząc namacalne efekty, również drugi menedżer zaczął wspierać zmiany.

Leonardo Bittencourt – Understanding How Work Works to Improve Flow

Tą prezentacją byłam chyba najbardziej zawiedziona. Tytuł obiecywał mięso, a dostałam zawoalowany opis zasad Kanbanu bez nazywania tego Kanbanem. Części osób, jak słyszałam, bardzo się to spodobało, natomiast ja poczułam się oszukana, bo jednak oczekiwałam innych, być może bardziej nowatorskich treści, a tymczasem usłyszałam o wizualizacji, limitowaniu pracy, pullu w miejsce pusha, metrykach i walce z marnotrawstwem. Gdybym wiedziała, pewnie ten czas spędziłabym w drugiej sali słuchając Ewy i Łukasza, jak stawiają transformacje Agile przed sądem. 

Radosław Orszewski – Upstream Kanban—what’s in there for Product people?

Kompletnym przeciwieństwem powyższego wystąpienia była natomiast prezentacja Radka. Nie dość, że było mięso, to jeszcze ładnie przybrane wizualizacją tablicy i podane w lekkostrawnych słowach. Radek zajął się często pojawiającym się pytaniem, skąd w Kanbanie zespołu wytwórczego biorą się zadania w kolumnie To do, opowiedział o procesie odkrywania opcji, z których dalej kształtuje się backlog zespołu, i pokazał, jakie możemy mieć kolumny w zależności od sposobów pracy zespołu (refinement, analiza wpływu na użytkownika, pisanie historyjek, wywiady z użytkownikami itp.). Ponieważ ostatnio sama miałam do czynienia z zespołami scrumowymi, które bardzo chciały mieć w jakiś sposób uwidoczniony w pracach w sprincie właśnie refinement i pisanie historyjek (a Scrum Guide jedynie mówi o poświęceniu na to do 10 % czasu bez wskazania konkretnych praktyk i procesu), czuję, że prezentacja Radka może pomóc zrozumieć ten proces wielu osobom. Oczywiście, do Upstream Kanbanu również stosujemy zasady limitowania prac, dodatkowo wskazując liczbę minimalną zadań, żeby jednak regularnie coś do wykonania spływało do zespołu. Dodatkowo pomiędzy Up i Downstreamem może pojawić się znane nam dobrze Definition of Ready i uwaga, dopiero w tym miejscu pojawia się również zobowiązanie dla zespołu. Zobowiązanie, czyli obietnica, podobna jak w sprincie, że skoro już coś trafia do Downstreamu, to zostanie zrobione, więc warto żeby to była faktycznie najbardziej wartościowa rzecz. Radek odpowiedział również w bardzo prosty sposób na pojawiające się pewnie u wielu pytanie, czy to, o czym mówi, to nie jest jakaś odmiana waterfalla. Po pierwsze Kanban pokazuje proces, więc jeśli proces tak wygląda, to zastanawiaj się nad procesem, a nie Kanbanem, a po drugie, jeśli przy takiej dwutorowej tablicy dostarczasz wcześnie i często, to nie, nie mamy do czynienia z waterfallem. 

April K. Mills – The Answer is in the First Line of the Manifesto

Bardzo ciekawa prezentacja o tym, jak bardzo źle podchodzimy do wprowadzania Agile. Dla przypomnienia, pierwszy wiersz, czy raczej pierwsze zdanie Manifestu, do którego odnosi się April, to “We are uncovering better ways of developing software by doing it and helping others do it.” A zatem: Najczęściej w momencie transformacji wszyscy skupiają się na ludziach i w najróżniejszy sposób (poprzez zachętę, zastraszanie, rozkazy itp.) mówią im, jak teraz mają pracować. Innymi słowy, organizacja zastanawia się, jak zmienić pracowników, jak ich przepchnąć przez zmianę, jak zmusić ich do zmiany, jak ich popędzić w kierunku upragnionego Agile’a, że użyję kilku czasowników, które April zawarła w jednym, bardzo pojemnym słowie drive. I jak długo będziemy się skupiali na “drive people”, a nie “drive change”, tak długo ludzie będą nienawidzić tego, co się z nimi dzieje, co im robimy i do czego ich zmuszamy. Bo w rzeczywistości, co April podkreśliła nawiązując do tego, że kiedyś również próbowała wpływać na ludzi, pracownicy nie mają nic do Agile’a, natomiast bardzo są niezadowoleni, że każe im się zmieniać. Drive change polega na tym, że to my decydujemy się zmienić i pomagamy innym podjąć taką decyzję, usuwając im z drogi przeszkody, podsuwając odpowiednie narzędzia i wspierając. Dzięki temu mamy szybszą transformację, bo ludzie się angażują, mniej ludzi opuszcza organizację, budujemy wewnątrz firmy zaufanie i służymy przykładem, a co najważniejsze pomagamy innym ludziom się rozwinąć, zamiast ich wykorzystywać. Wracając zatem do słów Manifestu, skoro mowa tam jest o “doing it” i “helping others do it”, April zaprezentowała bardzo zgrabne motto agenta zmiany (widoczne na foto) – Będę robić to, co mogę, z tym, co mam, tam, gdzie jestem.” Bo, podsumowując, to ludzie muszą sami wstać, zgłosić się do zmiany, chcieć coś zrobić, a my (przełożeni, Scrum Masterzy, Agile Coachowie i inni liderzy) możemy tylko dawać dobry przykład i pomagać.

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
X